- Magga: PLEX: multimédia az egész lakásban
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Meggyi001: Egy olcsó vállfás megoldás a pólóimnak...
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- gban: Ingyen kellene, de tegnapra
- bambano: Bambanő háza tája
- erkxt: A Roidmi becsődölt – és senki nem szól egy szót sem?
- sh4d0w: Palpatine - A Terv
-
LOGOUT
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
-
bambano
titán
válasz
Jester01 #2823 üzenetére
Ha a torent fő kapcsolatára nem pakolsz egy protokollértelmezőt, olyat, mint az irc vagy ftp értelmezője, akkor nem találtunk módot arra, hogy minden kapcsolat egyértelműen azonosítható legyen. Ha egy torent file-t sok feedertől kapod, akkor az sok kapcsolat, egyedi portokkal, nem megjósolható értékekkel, nincs semmi megragadható specifikuma. vagyis nem találtunk.
-
bambano
titán
válasz
Jester01 #2826 üzenetére
Mert kifejezetten az volt a kérés, hogy a torent forgalmat és csak azt userenként szeretné rajzoltatni muninnal. Megcsámcsogtuk alaposan és nem találtunk másik egyszerű megoldást arra, hogy szétválogassuk a webes, levelezési, chates, egyéb forgalmat a torenttől, userenként.
Rendszerint user nem elég expert torrent file változtatáshoz. Meg ha a fő ip-ről letiltja a torent portokat, akkor már lehet annyi akadályt okozni, hogy ne akarjon buherálni az user. Meg lehet root tulajdonba tenni a konfigot, user olvasási joggal -
bambano
titán
válasz
VladimirR #2825 üzenetére
ha kézzel, akkor:
ifconfig eth0:1 10.1.1.2 netmask stb. up
ha nem kézzel, akkor ugyanúgy csinálni kell plusz bejegyzéseket a /etc/network/interfaces-be:
auto eth0:1
iface eth0:1 inet static
meg a többi.
szerintem ez lenne a legtisztább megoldás. A juzereknek meg egyedi torent konfig és abban beállítani az ip-ket.
[Szerkesztve] -
bambano
titán
válasz
VladimirR #2821 üzenetére
Két lehetőség merült fel bennem:
1. az összes tcp/ip kapcsolatot naplózod, hogy mekkora forgalmat generáltak majd a /proc/net/tcp file alapján folyamatosan hozzárendeled a naplózott forgalomhoz az uidokat. Ez elég favágó munka, de szerintem megoldható. A gond az, hogy nincs benne semmi információ, hogy webezett az user vagy torentezett. Ez tehát nem teljesen arra a kérdésre válasz, hogy mennyi a torent forgalom.
2. Ha nem tudod teljesen szétválogatni hálózati adatok alapján a forgalmat, akkor marad az a megoldás, hogy külön ip címekkel jelölöd meg a forgalmat. Van a linuxhoz egy user mode linux nevű cucc, ami gyakorlatilag virualpc jellegű megoldás, vagyis egy felhasználói programba zárva futtat komplett linuxot. Csinálsz minden felhasználódnak egy user mode linuxot, annak adsz külön ip címeket és megmondod, hogy abban torenteznek. Ekkor az user mode linuxok ip címére rakott forgalom mérő filter meg fogja adni a torent forgalmat. Elismerem, nem a legjobb megoldás.
3. Elvileg vannak olyan programok, amelyeknek meg lehet mondani, hogy melyik interfészre kapcsolódjanak. Pl. postfix, squid. Az általad választott torent klienst nem ismerem. Ha annak is lehetne ilyet mondani, akkor egyszerű lenne felhúzni annyi interfész aliast (eth0, eth0:1, eth0:2,eth0:3, külön ip címekkel), ahányan torentezni akarnak.
Agyalok a kérdéseden, mert jó kérdés és jó agytorna, de nem találtam eddig tisztességes megoldást rá. Ezek csak ötletek, esetleg nem is a torentnél lesz hasznos máskor. -
bambano
titán
válasz
bambano #2816 üzenetére
Hm. az iptables tud uid alapján logolni. Hátrány, hogy a torrent forgalom keveredik az összes többivel.
Hmmhmm. ha egy fájlt több seedertől szedsz össze, akkor összegezni kell a forgalmat... (csak gondolkodom
Szerk: és a jó megoldást az iptables man-ja adja meg:
--pid-owner processid
ps -ből grep-pel meg lehet találni a processzazonosítókat, fel lehet rá állítani egy-egy szabályt és utána lehet muninba logolni, plusz amikor munin elvitte a forgalom számot, akkor nullázni az iptables számlálót.
[Szerkesztve] -
bambano
titán
válasz
VladimirR #2808 üzenetére
Ha egy net megosztó router mögött vagy, akkor esetleg ki kellene próbálni, hogy userenként adsz egy-egy ip címet a gépnek és a személyes ip címeken futna a torrent.
Ez ha triviálisan nem megy, akkor esetleg user mode linux-szal teljesen szeparálni lehetne az usereket.
Más: a /proc/net/tcp fileban benne van a forrás és a cél ip +socket és az uid is. Ha minden kapcsolat hosszát lelogolod és megnézed ezzel a file-val, hogy kihez tartozott, akkor lehet, előbbre jutsz. Első ránézésre elég favágónak tűnik... -
bambano
titán
válasz
ngabor2 #2785 üzenetére
Ha voltak olyan bénák, hogy a connect metódust nem tiltották le a proxyban, akkor putty-tyal ki lehet menni, ehhez persze lehet, hogy 443-as portra is fel kell rakni sshd-t.
Ha pedig rendesen be van állítva minden, akkor a htc-hts párossal tudsz kijutni egy tűzfalon. (ip over http proxyk). -
bambano
titán
-
bambano
titán
válasz
rokefeller #2683 üzenetére
A samba domain kontroller is. Legalábbis a régebbi, nt domaines időkben még az volt, az ad-t nem valószínű, hogy tudja.
-
bambano
titán
válasz
dr_strange #2630 üzenetére
xp írja-olvassa az ext2/ext3-at, nem tudom, mi a kérdés.
-
bambano
titán
Ez így egy kicsit tág kérdéskör. Én pl. cat-ot meg néha mc-t használok.
Persze parasztos a dolog, mert van hozzá hw tömörítő kártya. Szóval jó lenne tudni, hogy mi a hw.
Van a transcode-hoz is grafikus felület. avifile gondolom akkor kell, ha olyan codec-cel tömöríted és olyan konténerbe teszed, amit az ismer. Lehet, megnézném az mplayert, mencodert, hogy le lehet-e fordítani a te gépeden.
Esetleg nézd meg a mythtv-t is. -
bambano
titán
válasz
@Pirate@ #2561 üzenetére
Ha az a feladat, hogy fullosan az utolsó bitig mindent legyalulj a diszkről abból a célból, hogy xp egyszerűbben rámenjen, akkor linuxos livecd vagy valami ilyesmi, terminál ablakban:
dd if=/dev/zero of=/dev/hda bs=1024k count=16
ez letörli az első néhány sávot, a régi linuxos loadert meg pár ilyen szemetet. az xp loadere ezek után kényelmesen felmászik. de ez minden információt elérhetetlenné tesz a diszken, tehát megfontoltan.
egyes live cd-ken egy csökkentett képességű dd van, ebben az esetben:
dd bs=1024k count=16 </dev/zero >/dev/hda
(ok, nem gyalul le mindent a diszkről az utolsó bitig, csak az elejét kinullázza. ennek az az eredménye, hogy csak igen komoly tudással lehet bármit is leszedni róla ezután, tehát kezdő linuxos számára ez legyalult mindent). -
bambano
titán
válasz
VladimirR #2521 üzenetére
a pcap csomaghoz nem kell valami kernel támogatás?
packet socket kapcsoló a networking optionsban, ha modulba fordítottad, lehet, hogy be kellene tölteni. nem emlékszem, milyen kerneled van
illetve ha a a darkstat iptables-en keresztül méri a forgalmat, akkor azt is meg kellene nézni. ezt nem ismerem, de van másfajta forgalom ellenőrző, ami ezt csinálja (berak log targetre szabályokat, azzal lehet mérni az aktuális forgalmat)
ha minden kötél szakad, a /sys/class/net/eth0/statistics/ alatt találsz interfész statisztikát és megfaraghatod kézzel. -
bambano
titán
tud valaki működő freebsd fórumot?
-
bambano
titán
válasz
Forest_roby #2487 üzenetére
A wine-nak is van egy opengl-től függő darabja, azt is fel kell tenni. libwine-gl csomag.
-
bambano
titán
válasz
VladimirR #2459 üzenetére
A grub filerendszer szinten keresi a menu.lst-t (ellentétben a lilo-val). Ha összeolvasztod a két partíciót. akkor annak a partíciónak, amit a másik végéhez csapsz, megszűnnek egyes rendszerterületei (gyökérkönyvtár), ezért csak egy /boot dired marad, azt fogja használni.
Én kimenteném mindkét partíciót és utána egybeolvasztanám, újraraknám az egészet. -
bambano
titán
válasz
steveetm #2456 üzenetére
Semmi baj nincs azzal, hogy nem olvastad el, hogy az unideb tűzfalában alapból tiltva van minden port. Egy domainnek meg annyi köze van pl. az unideb hálózatához, hogy ha nem felel meg valamilyen okból a gép, akkor megszűnik az aldomain/gépnév delegáció és pont.
Egyetemi hálózat nem olyan, hogy jogod van telepíteni. Nem játékszer. Törvények, szabályok, rendeletek vonatkoznak rá.
Szerintem zárjuk le a témát, mert itt mindenki hajtogatja az igazát és csak a hozzá nem értésére ad bizonyítékot. -
bambano
titán
válasz
ngabor2 #2434 üzenetére
Nem ésszerűség. Az unideb-en belül mindenféle szabályok és elvárások vannak. Biztosan nincs (elvileg sem létezhet) kívülálló, aki ezt helyette tudni fogja. Ha meg félrevezetik, az mindenkinek rossz, az unidebnek is meg neki is.
Pl. a Lake Success-i megállapodás részleteiről a rendszergazdák igen nagy része nem szokott értesülni, pedig néhány százmilliárdos kérdés pusztán.
Összefoglalva: a legnagyobb segítséget akkor kapja tőlünk, ha az egyetemi emberekhez irányítjuk őt. -
bambano
titán
válasz
YouCanCANON #2429 üzenetére
A triviális megoldás, hogy bemész a diszkbe és kinyittatod a tűzfalat, majd megkeresed a matintézetben a rendszergarázdákat és ők segítenek neked megoldani. Nem hiszem, hogy bárki külsős el tudja pontosan mondani az unidebes elvárásokat.
-
bambano
titán
[link]
Eszerint a t5500-ban nincs. Nem jött össze az xp-s dolog, valamiért az xp bootoláskor eldobja az agyát, de nem tudom elkapni a képernyőképet.
Mintha a diszkekkel nem boldogulna. Majd megnézem, hogy a vmware-ben telepített xp milyen drivereket rakott fel és esetleg megpróbálom áttolni a másikba. -
bambano
titán
5.5.2-es vmware workstation (amikor vettem, még pénzes volt), advanced meg custom módban konfigurálva ad olyan választási lehetőséget, hogy
use a physical disk (for advanced users).
Még nem teszteltem, lehet, hogy nekifutok a héten
A mikrokernel az kicsit más tészta. Ott az eszközmeghajtók felhasználói programokként futnak. és sima szolgáltatásként vannak eszközeid, ebbe bootolnak bele egy unix processzt is. Elvileg mach mikrokernelen anno futtattak több linuxot egyszerre, arra volt jó, hogy egy gépen lehetett debuggolni és fejleszteni és tesztelni a kernelt. -
bambano
titán
A sima xen egy dolgot tud: paravirtualizálni. Ez azt jelenti, hogy a xen virtuális eszközöket, egyebeket nyújt a rajta futó vendég oprendszer számára és a vendég oprendszert át kell faragni, hogy ezeket keresse, ne a szokásos vasakat. A legújabb, fejlesztési stádiumban levő xen már tud rendes virtualizációt is a para mellé, ami azt jelenti, hogy módosítás nélküli vendégoprendszereket is képes futtatni. Ez nem megy proci szintű hw támogatás nélkül, ezt a hw támogatást hívják virtualizációs technikának. Ennek a jele, ha linux fut a gépeden és a /proc/cpuinfo fileban a processzor képességek között fel van sorolva a vmx. Az inteles doksikban ezt, amit a linux kernel vmx-nek hív, az intel VT-nek nevez, az amd meg pacificának.
Magyarul vagy tudjon a proci vmx-et vagy tudd átfaragni a vendég oprendszeredet. Xp-nél létezik xen-re átfaragott verzió, mert szakmai szórakozásból megcsinálták ms segítséggel, de nem publikálhatják.
Sima szoftveres megoldás is létezik, az egyik a vmware, ami mostanában lett ingyenes bizonyos verziókban. A vmware azt csinálja, hogy elereszti a vendég oprendszert user védelmi szinten és ha a proc védelmi rendszere megfogja (mert kernel szintű védelmi szintre akart kapcsolni), akkor a vmware szoftver visszafejti a kódot, hogy mit akart a vendég oprendszer, ami védelmi hibát okozott és helyettesíti egy olyan kóddal, ami emulált vmware hívásokká alakítja a vendég oprendszer rendszerszintű dolgait. Ettől van az, hogy brutális erő kell egy vmware guest bootolásához, de utána már egész jól elgurul (nekem is ez van). A másik megoldás a qemu, ami szoftveres pc szimuláció, mindent emulál, mintha igazi pc lenne. Ennek lett olyan új verziója, hogy vmx-szel már egész gyorsan megy az emuláció.
Másik megoldás lehet a cooperative linux, win32 kernelen futtathatszt áthekkelt linuxot.
Rég néztem, de mintha nem minden c2d tudna ilyet. De ezt nem mondom biztosra.
Nekem paravirtualizált xenem van egy pár, meg van egy vmx-es gépem, csak nem értem még rá meghekkelni az egészet. xen levlisták szerint simán működik a dolog. -
bambano
titán
Ha a notebookod tud vmx-et, vagy ahogy intel hívja: VT-t, ahogy amd: pacifica-t, akkor qemu-val vagy xen-nel szerintem ezt meg lehet csinálni. A kérdés, hogy a windows képes-e több különböző hardver verzión futni, mert a video és az ethernet driver biztosan nem lesz ugyanaz.
-
bambano
titán
válasz
ngabor2 #2392 üzenetére
Van, a plextor usb-s mpeg tömörítőjét használtam sokáig, de nem tetszett, mert a saját felvevőjével mindig szétcsúszott a hang meg a kép, mplayer méretű dromedárokat meg nem akartam használni hozzá. Egyébként működik, ha lett volna türelmem pontosan beállítani a képfrekit a hanghoz, jó is lett volna. De nem volt
[Szerkesztve] -
bambano
titán
válasz
VladimirR #2345 üzenetére
ha lokál aliast használsz, akkor lehet három postafiók.
én azt csináltam a saját rendszeremben, hogy (a te neveiddel példázva) van három alias:
cyla@cyla.homeip.net: /home/postoffice/cyla.homeip.net/cyla
vladimir@cyla.homeip.net: /home/postoffice/cyla.homeip.net/vladimir
gaborcyla.homeip.net: /home/postoffice/cyla.homeip.net/gabor
Vagyis nekem a virtuális mailboxaim a /home/postoffice dir alatt vannak, ahol minden levelezési domain számára csináltam egy külön aldirt, majd azon belül egy-egy mailboxot. Más kérdés, hogy én nem szeretem a mailbox stílusú levelezést, nekem maildir van, ami annyiban különbözik, hogy egy perjel (/) van minden alias végén, és akkor az mta maildirbe kézbesít (pontosabban az én mta-m, mert az exim4-ről fogalmam sincs).
Viszont a maildires kézbesítéshez nem jó a teapop, nekem courier-imapd van postgresql authentikációval. A maildires kézbesítés nagy előnye számomra, hogy a szerveren maradnak a levelek és akárhány gépről nézem thunderbirddel, mindig mindegyiket jól látom. -
bambano
titán
-
bambano
titán
-
bambano
titán
válasz
dr_strange #2231 üzenetére
Szerk: elbeszélünk egymás mellett.
Tehát annak az esélye, hogy egy kosár véletlenszerű kártyából kihúzol egyet és csupa f lesz a mac címe, nagyjából azzal egyenlő, hogy döglött-e a kártya elektronikus logikájának egy része vagy sem. Illetve azzal is, hogy hulladék gyártótól származik-e a kártya vagy sem (már láttam olyan gyártót, ptc-t vagy hogy hívták, hogy minden kártyájának ugyanaz volt a címe. meg olyat is, hogy a driver állította be a címet, ha generikus drivert tettél fel, akkor marhaságot csinált, ha sajátot, akkor valahonnan előkotorta a rendes címet és bevéste a kártyába. ezt meg asusnak hívták, alaplapi kártyák csinálták).
Annak az esélye, hogy kiveszel egy kártyát és az általad elvárt címe lesz, meglehetősen kicsi. De annak, hogy kiveszed, és csupa F, ehhez az előbbihez képest lényegesen nagyobb.
[Szerkesztve] -
bambano
titán
Létezik olyan hálózati protokoll, ami nem használható olyan kártyával, amelyik kártya mac címe nem írható át. Ma már jellemzően nem használják, de egy időben az egyetemeken nagyon elterjedet volt. DECnet Phase IV-nek hívták.
Ebben a decnetben az arp protokollt a mac címek átírásával kerülték meg. -
bambano
titán
válasz
dr_strange #2216 üzenetére
Elektronikai szemszögből közelítve a dolgot a digitális integrált áramkörök jelentős része a szabadon hagyott bemenetét logikai 1-nek veszi. Tehát előfordulhat, hogy megpusztult a kártya vagy annak egy része, esetleg a címet tároló eeprom, és amikor be akarja olvasni róla a mac addresst, akkor nem olvas semmit, amit ff-nek értelmez. Tehát a kérdésedre a válasz: nem, matematikailag a tiszta f-nek nagyobb az esélye, mint a többinek.
-
bambano
titán
Ha ráérsz, a sorokkal kapcsolatban érdemes belenézni ebbe: [link]
A kernelben levő hibákkal az is a baj, hogy régebben volt 2.páratlan.x-es kernel, amiről lehetett tudni, hogy olyan, amilyen, de mire 2.páros lett belőle, addigra rendberakták. A párosokkal olyan hajdenagy problémákba nem lehetett belefutni (mondjuk inkább: nem volt jellemző). Most meg mindenki azon a kernelen rodeózik, amit stabilnak hisznek. -
bambano
titán
válasz
dabadab #2193 üzenetére
Az egyik bug egy olyan gépen futott, aminek egyik darabjához csak a 2.6.18.rc1-től van támogatás. Tehát eszi-nem eszi nem kap mást.
A másik bug meg egy olyan gépen, amin az a 2.6.16.x-es kernelek vannak mostanában, amiről azt állítják a linuxosok, hogy folyamatosan fejlesztik és ügyelnek a stabilitására. Ennek a bugja szerintem még most is benne van a kernelben és szerintem megint megborulna az egész, ha vinyóhalál lenne.
Az oprendszer egyébként sarge, ezt talán ne nevezzük bleeding edge-nek. Sarge-ban 2.6.8-as kernelt látok, a security focus 6 oldalas listát közöl a benne levő biztonsági hibákról. A kernel bugzillában és a kernel forrásban van néhány scsi driver (adaptec, fusion) hiba, ami szintén kritikus (volt).
Olyan épeszű it stratégia pedig nem létezik, ahol egy működő kódban történt friss fejlesztést nem tesztelnek le és ezt ki lehet védeni. Backup nem került szóba, végül mentés nélkül is helyre tudtam tenni, de ettől ez még idő, kiesés, stb.
Köszönöm, de az ismételjük meg együtt stílusból nem kérek. Észérveket kérek arra, hogy miért vannak ekkora hibák a kernelben. -
bambano
titán
válasz
dabadab #2178 üzenetére
Ha porzósra rúgják a hátsómat, mert egy szolgáltatás egy napig nem megy pusztán azért, mert bugos a raid1 kód, vagy ha sok éves levelezésem megy a levesbe, mert rendes ember módjára raid1-re tettem márkás szerveren, de a raid kód hibája széjjelgyakta a rendszert, akkor tényleg megérett az idő a mormonság tanulmányozására.
A fő bajom az, hogy évekig nem volt komoly bajom a kernellel, megfelelő odafigyeléssel lehetett normális üzemet elérni, mostanában viszont dől-borul minden -
bambano
titán
válasz
VladimirR #2173 üzenetére
Tegyük fel, hogy a gép ki van kapcsolva. Ha nem, ctrl+alt+del-re vagy rebootol (normál linuxos beállítás) vagy megáll.
Beindítod a gépet, megvárod a szokásos bios üzeneteket és a lilo prompt-ot (ha lilo-s, ha grubos akkor nem tudom). A lilo promptnál nyomsz egy alt-ot (csak bal alt az alt), tab-ra kiírja a bootolható kerneleket.
Kiválasztod az aktív kernelt, beírod a nevét, majd utána szóközzel:
lilo: kernelneve init=/bin/sh
ki fogja írni a szokásos kernel inicializációs üzeneteket, majd kapsz egy root promptot. A root filerendszer ilyenkor readonly.
mount -o remount,rw /
ezek után két opciód van:
- kitörlöd a régi root jelszót: vi /etc/shadow és a root sorban levó sok betűs krikszrakszot kitörlöd, a kettőspont a mezőelválasztó, azok maradjanak.
- átírod az ip adatokat és nem bántod a root jelszót
majd három sync (csak a legnagyobb unix guruk tudják, hogy miért három, én nem, de három)
majd:
mount -o remount, ro /
majd valami utasítással vagy durvulással újraindítod. Van, hogy reboot, van hogy reboot -q, van hogy halt, van hogy semmi nem állítja le, linux életkorától függ. Mivel a filerendszer readonly, nem csinálsz túl nagy gondot, ha simán megnyomod a reset gombot.
Én nem ismerek triviális megoldást a root jelszó visszafejtésére. Bonyolultat se.
Másik triviális megoldás: debain install/netinstall cd letölt, bebootol, egyik konzolon shell indít, kézzel shadow kézzel editál. -
bambano
titán
válasz
Mandrake833 #2159 üzenetére
Ha elolvasod pl. a 2.6.18.1-es kernel changelogot, amiben ilyenek vannak, hogy nem szinkronizált a raid, a bug javítva, akkor szerintem minden okod megvan rá, hogy sírva menekülj a linuxtól.
Idén év elejétől a netcraft szerint az a tendencia, hogy csökken az apacs és nő a microsoftos webszerverek részaránya.
[link] -
bambano
titán
válasz
Renegade(c) #1931 üzenetére
Beírod, hogy www.linuxdoc.hu, redirectel ide: [link]
Itt megtalálod a linuxos doksik igen jelentős részét.
Ehhez már csak olyanokat kell tudni, hogy az uhulinux könyve letölthető:
[link] (nem friss, de nem is régi). Szerintem a közösség számára hasznosabb munkákban is részt vehetsz annál, hogy csinálsz 51231. linux oldalt.
Új hozzászólás Aktív témák
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- 27%-OS ÁFÁS SZÁMLA I Jogtiszta Microsoft digitális és fizikai termékek I DIGITALKEYZ.COM
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Asus A520 R5 3600 16GB DDR4 500GB SSD RTX 2060 8GB Rampage SHIVA CoolerMaster 700W
- BESZÁMÍTÁS! Gigabyte GA-A620M R5 7600 32GB DDR5 512GB SSD RX 6700XT 12GB Rampage SHIVA Corsair 750W
- Samsung S25 Ultra 256GB Csak kipróbált!! Jótállás: 2028.06.19.-ig
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest