- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Canon EOS DSLR topic
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Forrmell.enn
- Vélemény: nem úgy tűnik, de Lip-Bu Tan most menti meg az Intelt
- AMD Navi Radeon™ RX 5xxx sorozat
- HiFi műszaki szemmel - sztereó hangrendszerek
- Hobby elektronika
- Milyen joysticket vegyek?
-
PROHARDVER!
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
letix
senior tag
válasz
Dißnäëß
#26978
üzenetére
Szia,
Egész jól összeírtad az igényeidet, azt hiszem ebből már lehet építkezni..
Nem vagyok a témában nagy spíler, de tudomásom szerint az LVM tud RAID-et kezelni anélkül, hogy te mdadm-al is építkeznél rá. Tehát szerintem a kettő együtt fölösleges lehet.
[link]
Egyébiránt pedig én lehet hogy kicsit játszadoznék a témával virtuális környezetben. Egy Debian telepítő expert módban szépen össze tudja tenni titkosítva és LVM-el a dolgokat különösebb hozzáértés megléte nélkül, ezt követően pedig már tudod tesztelgetni, bővíteni, stb..udv
letix -
#26973
letix
senior tag
MasterMark
#26971
letix
senior tag
válasz
MasterMark
#26971
üzenetére
Szerintem forwarder nélkül a 1x db root szervet kérdezgeti a bind-od.
Azt nem nagyon értem mit jelent hogy a root-nak saját magát adtad meg. A root alatt szerintem te mást értesz mint ami.udv
letix -
#26969
letix
senior tag
MasterMark
#26968
letix
senior tag
válasz
MasterMark
#26968
üzenetére
Nem értek a lovakhoz, de nem lehet hogy a root szervereket azért megkérdezi?
udv
letix -
letix
senior tag
Udv a szakiknak!
mdadm vs LVM, hardware RAID fölött témában szeretnék érdeklődni, tanácsot kérni.Leleldzik itthon kis játszós NAS jellegű gép, egy elég őskövület Areca 1210-es vezérlővel, 2*2TB-os 7200rpm-es + 2*1.5TB-os 5400rpm-es HDD-vel. A gépben a CPU egy Celeron 1037U.
Szeretném a lehető legjobb sebességet elérni úgy, hogy az ne menjen a rendelkezésre állás rovására.
Több dolgot kipróbáltam, a vezérlő viszonylag jól képes kezelni RAID5-ben vagy RAID10-ben is a különböző diszkeket, de a neten olvasgatva ezt a felállást elvetettem. A 2db RAID1 tömböt is elvetettem, ott nagyon sok kapacitást vesztenék, és sebességben sem szimpatikus a dolog.A kérdés, amely a jelenlegi helyzettel kapcsolatos:
2db fizikai RAID1 tömb fölé mit érdemes inkább alkalmazni?-mdadm RAID0 a két fizikai RAID1 tömb fölé, így 3TB hasznos tár marad viszonylag gyors eléréssel, plusz a maradék hasznosítható.
-LVM Stripe a két fizikai RAID1 fölé, így a hasznos tár könnyen formázható, és sebességben is elfogadható, kicsivel talán gyorsabb is az előbbinél.
Szokás-e egyáltalán ilyen felállásban szétosztani a lemezeket?
Ha van esetleg más ötlet, szívesen fogadom. A felhasználás átlagos otthoni mentések, backup tár, esetleg iSCSI MPIO-val 2db Gbit kártyán, VM storage-nak, ilyesmi.Köszönöm!
udv
letix -
letix
senior tag
Üdv a szakiknak!
iptables-el kapcsolatban lenne egy érdekes kérdésem.
Adott egy publikus oldalról is elérhető szolgáltatás, ezen szolgáltatáshoz az ISP DNS szerverében fel lesz véve egy rekord (xyz.valami.hu), melyet az internetről meghívva egy adott belső hálózati szerverhez fog eljutni a kérés. A port forward ezen szerver felé nem probléma, legalábbis a net felől, ez eddig tiszta.
Az lenne a kérdésem, hogy megoldható-e, hogy a belső hálózatból is elérhető legyen a szolgáltatás xyz.valami.hu néven? Helyi DNS jelen helyzetben nem használható.
Annyival bonyolódik még a helyzet, hogy az átjárót megvalósító Debian tűzfal előtt van egy NAT-oló szolgáltatói eszköz is, tehát dupla NAT van. Az ISP eszközén DMZ-ben van a szóban forgó Debian tűzfal.
Jelen helyzetben megoldható lehet?
Első körben NAT loopback-hairpin kifejezésekre találtam hasznos infókat, elvileg megoldható, viszont a dupla NAT miatt problémás lehet.Köszönöm!
udv
letix -
letix
senior tag
válasz
sh4d0w
#26612
üzenetére
Köszi a válaszod sh4d0w, így már sokkal világosabb a dolog mint ezelőtt
Olvasgattam a feladat előtt ugyan, de most már tényleg tisztább.Közben megszületett a végleges megoldás, kíváncsi volnék a szakik véleményére.
Minden Debian8-on az openssl.cnf-ben a digest-hez felvettem az sha256-ot is az md5,sha1 mellé.
A titkosítást Debian verziótól függetlenül mindenhol -md sha256 kapcsolóval teszem meg, ami a 128 karakter hosszú "kulccsal" történő titkosítást illeti.
Ugyanilyen kapcsolóval titkosítom ki fogadó oldalon (Debian8-on) az imént leteszteltem, és szépen megy Debian8 és Debian9 küldőtől is.Remélem így már a biztonságosabbnak mondható!
Köszönöm!
letix -
letix
senior tag
Találtam egy md5-nél remélhetőleg jobb megoldást. Debian8-on az openssl.cnf-ben a digest md5, sha1.
Tehát küldő oldalon (Debian9) ha így titkosítok:
-md sha1és fogadó oldalon (Debian8) így titkosítok ki, abban az esetben működik szépen.
Így jobb lehet a dolog?
Köszönömletix
-
letix
senior tag
válasz
sh4d0w
#26608
üzenetére
Az asszimetrikus titkosítás még elég új dolog számomra, így el tudom ugyan olvasni amit írsz, de nem tudok vele mit kezdeni.
. Van -md sha256 kapcsoló is, azzal sajnos nem működik. Mit tudok ezzel kezdeni, merre induljak?
Vagy lehet hogy nincs is a két különböző verziójú openssl között átjárhatóság?Köszi
letix -
letix
senior tag
Némi google után a megoldást (nem biztonságos!) megtaláltam
[link]-md md5 kapcsoló a key.bin-el történő encrypt sor mögé.
Ahogy a fenti link is taglalja ez a digest nem biztonságos, ámbár működik. Kérdés hogy mekkora kockázatot rejt magában? Nem feltétlen szenzitív adatokat utaztatnék de még is jobb ha nem plaintext-ben menne/jönne.Ötlet esetleg?
Köszi!udv
letix -
letix
senior tag
Üdv a szakiknak.
Több Debian8-ról és 1db Debian9-ről szeretnék egy távoli Debian8 gépre 1db titkosított állományt átvinni automatikusan. A titkosításra asszimetrikuskulcsokat használnék, openssl-el. (openssl új téma még számomra..) Az scp, vagy ssh kulcsos auth, stb most nem járható sajnos. Átviteli közeg csak FTP lehet.
Debian8 openssl 1.0.1t-1+deb8u7
Debian9 openssl 1.1.0f-3+deb9u1A script: legyárt egy random 128 karakter hosszú kulcsot, valamint ezzel titkosítja a hasznos adatot, majd a másik oldal (fogadó) publikus kulcsával titkosítja a 128 karakteres kulcsot, és ezeket utaztatom..
/usr/bin/openssl rand -base64 128 -out key.bin
/usr/bin/openssl enc -aes-256-cbc -salt -in $DATA -out $DATA.enc -pass file:key.bin
/usr/bin/openssl rsautl -encrypt -inkey $PUBKEY -pubin -in key.bin -out key.bin.encItt jegyezném meg, hogy ez a script szépen lefut Debian8 gépeken, Debian9-en viszont csak akkor megy, ha az első sorban az -out $KEY a rand után következik..
Szóval megvan a titkosított "kulcs" és a titkosított adat.
Fogadó oldalon így nyitom ki őket:
/usr/bin/openssl rsautl -decrypt -inkey $PUBKEY -in key.bin.enc -out key.bin
/usr/bin/openssl enc -d -aes-256-cbc -in $DATA.enc -out $DATA -pass file:key.binDebian8 alatt létrehozott adat szépen kinyílik, Debian9 alatt létrehozott adat kititkosítása ezzel a hibával száll el:
bad decrypt
3074016956:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:516:Az openssl különbözősége az ok? Mit lehet tenni ilyenkor?
Köszönöm!
letix -
letix
senior tag
Szia,
A route valóban elkerülte a figyelmem.
Amennyiben biztos vagy abban, hogy a tűzfal fogja meg, érdemes lenne LOG-ot készíteni róla.
Gyanítom hogy átmenő forgalmazás, szóval a FORWARD lánc utolsó REJECT szabálya elé én betennék egy -j LOG-ot valami prefix-el. Ebből szerintem már ki lehetne indulni.ps.: Én azért a biztonság kedvéért ellenőrizném, hogy a VPN-hálózatba csatlakozott kliensnek az-e a publikus IP-je amit beengedtél a harmadik állomásra. Bár ha azt mondod egy tűzfal nélküli VPN-be becsatlakozott kliens ki tud menni A.B.C.D felé akkor gondolom az.
udv
letix -
letix
senior tag
Üdv,
Van egy érdekes jelenség melynek okára egyelőre nem jöttem rá.
Leledzik egy több ethernet kártyával megáldott Debian gép, a kártyái közül az egyiken (és csak azon) mint dhcp szerver funkcionál.
Fut rajta egy smokeping nevű alkalmazás, mely egy másik kártyán megy ki a net felé és ott is várja vissza a válaszokat.A syslog-ban ilyenek láthatóak,
Oct 3 15:51:12 host01 dhcpd: unexpected ICMP Echo Reply from X.Y.Z.V
Oct 3 15:51:12 host01 dhcpd: unexpected ICMP Echo Reply from V.X.Z.Y
Oct 3 15:51:12 host01 dhcpd: unexpected ICMP Echo Reply from X.V.Z.ZAz ipk ismerősek, a smokeping "végei", az viszont nem értem, hogy hogyan kerülnek kapcsolatba ezen IP-k a dhcpd daemonnal? Miért gondolja hogy az neki szól?
A smokeping egyfolytában pingel, a syslog-ba viszont óránként kerülnek ilyen sorok.Köszönöm előre is.
udv
letix -
letix
senior tag
Szia n00n,
Nem vagyok nagy szakértője a témának, de hátha nem teljesen hülyeség:
Ha jól értem, van egy harmadik állomás (A.B.C.D) amit el szeretnél érni a VPN hálózatból, ahova becsatlakoztál.
Érdemes lenne megtudni, hogy ha a VPN hálózatban lógsz, akkor ki az átjáród az internet felé.A: a saját kliensed előtti gw. (vélhetően ez az)
B: a VPN szerver, amennyiben ez a beállítás a VPN configban szerepel. (szerintem nem szerepel)Amennyiben az A, akkor szerintem úgy tudod elérni az A.B.C.D-t ha azt az IP-t engeded be rá, bár ez gondolom dinamikus.
Azt gondolom ha a VPN szerver címét engedted A.B.C.D felé, akkor a B variánst kellene elérni úgy, hogy a VPN kliensek teljes forgalma menjen át a VPN szerveren.Valami ilyesmivel:
push "redirect-gateway def1 bypass-dhcpudv
letix -
letix
senior tag
válasz
bambano
#26016
üzenetére
Köszi a válaszod.
Igazad lehet, az hogy nem áll le az egyértelműen probléma. Megnézem ezt a két LCP paramétert, köszi.Tovább gondolva, ha mondjuk nap közben a modem le van lőve (nincs otthon senki) a kisgép pedig megunta a ppp kapcsolat kiépítésére tett próbákat (gondolom elér egy küszöbértéket), akkor abbahagyja a további próbálkozást (ha jól gondolom). Namost ha felkapcsolásra kerül a modem, vajon a kisgép azért mert érzékel linket, újra elkezd kapcsolatot létesíteni és betárcsázni? Ha igen, és ha az előző pppd le lett lőve akkor talán jó is lehet a helyzet.
Köszi,
letix -
letix
senior tag
Udv a szakiknak,
Tök ciki, elakadtam egy alap dologgal, kérnék szépen kis útbaigazítást, segítséget.
Eddig sosem volt szükségem PPPoE beállítására, most viszont úgy alakult , hogy otthon a router helyett egy kis debian intézi (né) a bejövő lan és wlan kapcsolatok kiszolgálását.Tűzfal, maszkolás, routing minden stimmel, de a pppoe valamiért szívat.
pppoeconf és pppd csomagot feltettem, pppoeconf paranccsal automatikusan felkonfigurált mindent amit kell, a provider név/jelszava beadva neki, örülünk, van kapcsolat. pon és poff is szépen megy kézzel. (Ennek 2 napja)
Azóta többször panaszkodott párom nap közben hogy nincs net, tegnap este meglestem, és mintha két pppd daemon és két kapcsolódási kísérlet menne a gépről, amit az ISP el is dob Too many connections-el.
Ennek az okára rájöttem, van, hogy estére áramtalanítva van a modem, a kisgép viszont nem. Reggel modem bekapcs, ugye a tegnapi pppd nem áll le, hanem indít mellé mégegyet.Arra gondoltam, hogy az interfaces file-ba érdemes lenne felvenni, hogy ha a (WAN) fizikai csatolón van link, akkor húzza fel a ppp interface-t is és pon-al csatlakozzon, ha viszont nincs link, akkor poff-al kapcsolódjon le és a ppp interface down legyen. (esetleg killall pppd)
-Jól gondolom?
-Ha igen, ilyenkor a ppp interface-t kell lökdösni (up-down) vagy a fizikait? pre-up és post-down-al kellene?Köszönöm szépen!
udv
letix -
letix
senior tag
Közben kicsit faragtam a dolgokon, hátha hasznos valakinek.
Amennyiben a backup gépről egy dedikált felhasználó futtatja a backup scriptet (rsync -a opcióval), úgy a jogosultságok ugyan átjönnek, de a user/group tulajdonságok nem.
Ezt úgy tudtam kivédeni, hogy legyártottam a backup gépen a root publikus kulcsát, ezt hozzáadtam a távoli gép dedikált user authorized_keys-hez , aki egyébként így sudoer az adott távoli gépen:username ALL= NOPASSWD: /usr/bin/rsync --server --sender -logDtpre.iLsfx . /
Így a user/group tulajdonság is átjön, és talán az rsync-el sem lehet a sudo miatt okoskodni nagyon.
Persze az első sudo rsync futásnál belefut a "Great power comes with great responsibility" felszólításba és meg is akad (no tty..), szóval ezt helyileg egyszer kezelni kell.Ötlet valakinek?
Köszi,
letix -
letix
senior tag
Igen, így használnám az rsync-et.
A --password-file jó lehetne, elvégre ez a file a backup gépen lenne, amihez rajtam kívül csak 1 fő ér hozzá, ráadásul netről nem érhető el, viszont ezen opció csak az rsync daemon módjában használható. Ezt viszont én nem tervezném beüzemelni a remote szervereken érthető okokból.Ha megfordítanám a daemon módot és a backup szerver lenne az rsync daemon, ahhoz szükséges lenne a távoli gépekről elérést biztosítani a backup felé. Ezt viszont már korábban kizártam
Köszi a segítséged.
udv
letix -
letix
senior tag
Arra gondoltam, hogy mind a backup szerveren, mind pedig a távoli gépeken dedikált userek lesznek, így talán tisztább.
Amit még egyelőre nem értek:
Ha az előbbi javaslatod használnám: hogyan tud jelszóval belépni, ha ütemezett script-ből rsync -e 'ssh -p port' formát használok?
Ha az utóbbit, akkor az ssh belépés tisztázott, viszont az --rsync-path="sudo rsync" még mindig jelszót kér a nopasswd nélkül. (és ez a gond fennáll az elsőnél is.)Én látok valamit nagyon rosszul?
Köszönöm!
udv
letix -
letix
senior tag
Igen, közben én is beláttam, hogy ez is egy lehetséges alternatíva.
A kérdés, hogy melyik rejt több biztonsági kockázatot:
-távoli szervereken a root publikus kulcsának használata a backup-on belépéshez és rsync-hez?
-távoli szervereken a dedikált backup userek sudoers ALL=NOPASSWD /usr/nin/rsync beállítása?Köszi!
udv
letix -
letix
senior tag
Köszi a válaszokat.
Igazából mindkettőt szükséges adott időközönként. Más mentőeszköz egyelőre nem játszik, nem az én rendszereim..
Egyelőre azt nem tudom, hogy a remote szervereken hogyan tudom elérni a mentendő mappákat root nélkül.
sudo-val megy, de ott ugye jelszót kér.. Ami kiküszöbölhető a sudoers-be NOPASSWD -vel csak a sudo rsync-re, csak kérdés hogy ez mekkora biztonsági kockázast.
Köszi,udv
letix -
letix
senior tag
Üdv a szakinak,
Segítséget illetve tanácsot kérnék az alábbi feladat megoldásában:Adott egy Natolt hálózatban ülő dedikált backup szerver (Debian), továbbá 4-5 a neten fellelhető szintén Debian szerver, melyekről automatikus mentést kellene készítenem. Eszköznek az rsync használható.
A gépek egyikére sem lehet root-ként bejelentkezni közvetlenül (jelszót sem tudom), a userem viszont mindenhova sudoer.Három lehetőséget látok egyelőre:
1: a backup szerverre írom meg a scriptjeimet, rsync ssh-n (kulccsal) szépen magára húzná szerverenként a mentéseket. Ehhez terveznék minden szerverre dedikált backup usert létrehozni, akinek viszont minden mentendő mappához ugye nincs/nem lesz joga (/root, /etc...). Ezért is a mentendő szerverekre a dedikált backup user(eke)-t szükséges felvennem sudoer-ként NOPASSWD-vel a /usr/binrsync futtatására, egyelőre más megoldást nem találtam, hogy sudo rsync-ként tudjon ügyködni a remote gépeken. Ez nem annyira tetszik, már csak ezért sem:
[link]
Előny, (ha jól látom) hogy kevesebb esély van a backup szerver törésére ha a remote szerverek kompromittálódnak.2: a backup szerveren rsync daemon futna, és a scripteket a remote szervereken futtatnám, ssh-n keresztül becsatlakozva. Itt ugye többletmunka (és rizikó) a szerverekről a portok kinyitogatása, továbbá a forgalom egyenkénti beforgatása a backup szerver felé. Továbbá itt kevésbé érezném, hogy a backup szerver biztonságban van.
3: a backup szerverre tolnák fel a szerverek a mentéseket, kihagyva a backup-on az rsync daemon módját. Bár őszintén szólva egyelőre még a daemon módnak az előnyét sem látom. Előnyök hátrányok nagyrésze -gondolom- megegyezik 2-es ponttal, annyi különbséggel, hogy ssh elérések adottak.
Minden ötletet, javaslatot, kritikát szívesen fogadok. A csináltassam meg hozzáértővel most nem opció..
Köszönöm!
udv
letix -
letix
senior tag
válasz
VladimirR
#6403
üzenetére
Nagyon köszönöm a segítséged VladimirR, az /etc/resolv.conf -ban még a régi internet-szolgáltatóm dns ip-i voltak megadva, erre nem is gondoltam.
Inkább a kliensekben írom át a bejegyzéseket, talán úgy biztonságosabb a dolog. (?)
Mindenesetre a probléma megoldódott, köszönöm a segítséget.
udv
letix -
letix
senior tag
válasz
VladimirR
#6399
üzenetére
Jelenleg még csak 1 laptoppal tesztelem a dolgot, annak az Interfaces álománya a következő.:
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.123
netmask 255.255.255.0
gatewway 192.168.1.100auto eth0.
dns-t nem állítottam be, mit kellene (ha kellene)?
udv
letix -
letix
senior tag
Üdv az Uraknak!
Egy problémám lenne amiben a segítségeteket kérném.
Adott egy kisgép, Debian etch, két eth-val, 2.6.18-6-os kernellel, kábelnet dhcp-vel, iptables v1.3.6-al.
Megosztanám eme géppel a netet, a kernelbe beleforgattam a megfelelő modulokat.
A kliens gépeken bizonyos oldalak bejönnek, mások nem.
PL.: A PH! gond nélkül megy csak http, https-t nem próbáltam, de mondjuk a ásik fórum apróhirdetés oldalára 404 et dob, hasonlóan a debian.org ra és még sok más oldalra is.A script idevágó részei.
EXTIF="eth0"
INTIF="eth1"---
$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD DROP
$IPTABLES -F FORWARD
$IPTABLES -t nat -F$IPTABLES -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
$IPTABLES -A FORWARD -j LOG$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
Interfaces.:
allow-hotplug eth0
iface eth0 inet dhcpauto eth0
iface eth1 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway xxx.xxx.xxx.xxxauto eth1
A hozzáértésemmel még vannak gondok ezen a téren, de ma egész nap az ezzel kapcsolatos írásokat bújtam, elméletileg nincs semmilyen szabály amely befolyásolhatná 1-1 oldal elérését.
A kábelek, a switch és a hálókártyák jók.Kérném a hozzáértők segítségét.
udv
letix
Új hozzászólás Aktív témák
Hirdetés
- Formula-1
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Canon EOS DSLR topic
- DOOM - The Dark Ages
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Motoros topic
- Luck Dragon: Asszociációs játék. :)
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Viccrovat
- One otthoni szolgáltatások (TV, internet, telefon)
- További aktív témák...
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Samsung Galaxy A40 64GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 4070Ti Super GAMER PC termékbeszámítással
- Eredeti Windows 10 / 11 Pro aktiválókulcs AZONNALI SZÁLLÍTÁSSAL!
- LG 45GS95QE - 45" Ívelt OLED / 2K WQHD / 240Hz 0.03ms / NVIDIA G-Sync / FreeSync Premium / HDMI 2.1
- BESZÁMÍTÁS! Dell Latitude 5550 üzleti -Intel Ultra 7 165U16GB DDR5 RAM 1TB SSD Intel Graphics WIN11
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest