-
Fototrend
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
-
vicze
félisten
válasz
#68216320 #33169 üzenetére
Válasz olyan szolgáltatót aki támogatja alapból, különben alapból leheltelen, mivel a kulcsot be kell, írd és az rendszer előtt van, tehát low level interaktív web console kell, ami nem mindenhol adott.
Linod-on használtam és jól működik, illetve ott kb. bármit meg lehet csinálni.
Másik lehetőség ha a szolgáltató támogat low level interaktív konzolt, és enged image-et akkor egyszerűen feltölthetsz egyet. Amazonnál ha jól tudom adott ez is rescue móddal, de ott még nem csináltam. -
urandom0
senior tag
válasz
#68216320 #33171 üzenetére
Szerintem root partícióra legfeljebb akkor lehet megcsinálni, ha találsz olyan VPS szolgáltatót, ami kifejezetten támogatja ezt. Ilyet kell keresni, hátha van.
De amúgy miért fontos a root partíció titkosítása?
Ha van is virtuális konzol, az jellemzően onnantól fogva képes működni, hogy a rendszer már bebootolt.Szerintem egyszerűbb és jobb (és persze drágább is) a saját szerver elhelyezés, ott azt csinálsz a gépeddel, amit akarsz.
-
urandom0
senior tag
válasz
#68216320 #33097 üzenetére
Bocs, hogy triplázok, de lassan jutnak eszembe a dolgok.
Beállíthatsz egyszerre public key authenticationt és passwordauthenticationt is:AuthenticationMethods "publickey,password"
PubkeyAuthentication yes
PasswordAuthentication yesÍgy csak akkor tudsz belépni, ha a pubkey ÉS a jelszó is jó.
-
urandom0
senior tag
válasz
#68216320 #33110 üzenetére
Lokáció alapján is tilthatod az IP-ket: https://felipeferreira.net/2016/04/25/iptables-block-country-script/
-
vicze
félisten
válasz
#68216320 #33097 üzenetére
Csak biztonságos titkosítást engedélyezz. (Chipher suite)
Nyilván a privát kulcs legyen jelszavas.
Az MFA-t mondták, erre vannak jó OTP pluginek.Jelszavas privát kulcs + MFA és egy támadó bejutási esélye elég alacsony, konvergál 0-hoz.
Nézz egy CIS Benchmark-ot az adott distro-ra ott még lesz pár javasolt beállítás SSH-hoz, de nagyrészt PAM-re lesz, illetve PAM hardening.Nagyon HC akarsz lenne akkor újraforgatod OpenSSH-t, hogy kikapcsold a service bannerét, amit sajnos nem lehet anélkül. (bár ez okozhat problémát elvileg, ha jól emlékszek)
-
urandom0
senior tag
válasz
#68216320 #33110 üzenetére
Esetleg be lehetne állítani, hogy az sshd ne a root nevében fusson, de ezt csak akkor tudod megcsinálni, ha engedélyezve van a PAM. Bár ha 2 faktort tervezel, igen, akkor is kelleni fog a PAM.
Egyébként én még ezeket be szoktam állítani:
UsePrivilegeSeparation yes
StrictModes yes
MaxSessions 1
MaxStartups 1
MaxAuthTries 2Egyébként a Red Hat Enterprise Linux 9 Securing Networks doksi szerint az Ed25519 algoritmust ajánlja az RSA helyett.
-
bambano
titán
-
bambano
titán
válasz
#68216320 #33079 üzenetére
"ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub"
mivel az rsa titkosítás szimmetrikus abból a szempontból, hogy melyik kulcsot nevezed ki privát kulcsnak, és melyiket publikusnak, az az állítás, hogy egy egyszerű parancssori utasítással le tudod generálni a privát kulcsból a publikusat, ekvivalens azzal az állítással, hogy a publikus kulcsból egy egyszerű paranccsal le lehet generálni a privát kulcsot.azé' ettől az állítástól egy pár ember bokáig összef.sná magát hirtelen, összes bank, katonai titkosítások, stb. ha erre az állításra lenne korrekt bizonyítás és működő megoldás, akkor a Föld gazdasága kb. 20 perc alatt omlana össze a kőkorszakig.
-
-
válasz
#68216320 #33082 üzenetére
> Jelszókezelőt nem használok és nem fogok. Ez egyszerűen egy elvi döntés, nem bármiféle minősítése a szolgáltatásnak.
Mindenkepp hasznalsz 'jelszokezelest', marmint valahol mindenkepp tarolni fogod pl. a privat kulcsokat. Az a gyanum, hogy kevesbe biztonsagosan, mintha pl. a 1Passwordban tarolnad.
-
bambano
titán
válasz
#68216320 #33070 üzenetére
a kulcspár egy identitást azonosít.
több kulcspár egy adott identitáshoz eléggé kilóg a tervezett felhasználásból.
minden egyes gépen, amin kulcsos ssh-t akarsz használni, generálsz egy darab kulcspárt, és utána minden másik gépre, amire be akarsz arról a gépről jelentkezni, átmásolod az azonosítót. akár szövegszerkesztővel, akár ssh-copy-id utasítással."A kérdésem arra irányult, hogy amennyiben minden helyre külön kulcspárt csinálok, akkor több id_rsa (vagy éppen ami a fájlnév az új algoritmusú privát kulcshoz) lesz a laptopomon?": nem.
ha minden helyre külön kulcspárt csinálsz, akkor a notebookod id_rsa.pub fájlja lesz több helyre átmásolva. nem a szerver publikus kulcsát másolod a notebookra, hanem a notebookét a szerverre. -
-
vicze
félisten
válasz
#68216320 #31463 üzenetére
Hát igen azt is szettnéd, hogy valaki meg is kapja a levelek és ne csak úgy az éterbe menjenek, akkor egy kicsit bonyolultabb. Jobb esetben megy spam-be rosszabban meg se kapja senki meg elég rövid idő alatt blokkolják az IP-t.
Kulcsszavak: MX, SPF, DKIM, DMARC
Még számít, domained kategorizálása / domain reputation, persze a fentiek függenek, hogy hova akarsz e-maileket küldeni.
Most a különböző mail fejlécek odabiggyesztésébe nem megyek bele.Amit hcl leírt az az egyszerűbb sokkal, bár ott is lehetnek buktatók, a Gmailed biztonsági szintjétől függően. Gamil amúgy napi 500-as napi limittel rendelkezik(sima nem üzleti) és asszem van /perc limit is.
-
-
vicze
félisten
válasz
#68216320 #31322 üzenetére
"FakeRAID
This type of RAID is properly called BIOS or Onboard RAID, but is falsely advertised as hardware RAID. The array is managed by pseudo-RAID controllers where the RAID logic is implemented in an option rom or in the firmware itself with a EFI SataDriver (in case of UEFI), but are not full hardware RAID controllers with all RAID features implemented. Therefore, this type of RAID is sometimes called FakeRAID. dmraid from the official repositories, will be used to deal with these controllers. Here are some examples of FakeRAID controllers: Intel Rapid Storage, JMicron JMB36x RAID ROM, AMD RAID, ASMedia 106x, and NVIDIA MediaShield." -
válasz
#68216320 #31227 üzenetére
nm
Sajna anno Win miatt kellett párszor használnom, de majd 10 év alatt sem felejtettem el a nevét.
Amúgy Frawlynak igaza van, spéci disztrókkal is megoldhatnád, de bonyolultabb lenne odáig eljutni. A Kalinak tuti vannak erre csomagjai, de a Parrot OS is hasonló szerintem. De minek egy teljes disztrót feltenni. Nekem anno merevlemez műveletekhez volt nagyon hasznos a Hiren's.
-
Frawly
veterán
válasz
#68216320 #31216 üzenetére
A Rar-verzió csak azért érdekes, mert a 3.x-ig egyszerű CBC-s eljárással titkosított a Rar, meg a WinRar is, és a 4.x-től álltak át AES-re. Ha tényleg 3.80-assal csináltad, akkor mákod van, könnyen törhetőnek kéne lennie, a megfelelő célszoftverrel másodpercek. És azért írom így általánosságban, mert bár csináltam ilyet, hogy 3.x-es .rar archivumról oldottam le a jelszót, de évekkel ezelőtt volt, és akkor Windowst használtam, és arra kiadott célszoftverrel törtem, talán valami Rar Password Cracker vagy már nem is tudom mi volt a neve, pár mp. alatt simán nyitotta az archívumot. Linuxon nem tudom melyik natív tool jó erre.
Az AES256-os zip törése elég reménytelen viszont. Persze, meg lehet próbálni, de mivel csak brute-force lehet, az elég sokáig fog tartani, kivéve ha 12345 vagy password vagy ilyesmi blődség a jelszó.
-
Frawly
veterán
válasz
#68216320 #31209 üzenetére
Szerintem nem éri meg erre időt pazarolni. Zip-nél attól függ, hogy milyen Zip progi jelszavazta, milyen titkosítással, Rar-nál meg hogy milyen régi volt a tömörítő. A modern Zip progik (pl. 7-zip), meg a 3-asnál újabb Rar AES-t használ, min. 128 bit, néha 256 bit, plusz pár bites kulcserősítés, így nagyon hosszú brute force-szal törni őket, nem nagyon éri meg. Ha meg is csinálod, akkor se a nyereségvágy, hanem csak a tanulás, szakmai kíváncsiság hajtson.
De ha régi fájlok, amiket régi Zip, főleg pkZip, WinZip csomagolt, meg régi Rar, azokat elég könnyen törik kulcsrakész megoldások, pár másodperce egy átlag desktop gépen.
A Zip-pel a legnagyobb baj, hogy nem biztosan szabványos. Ahány Zip progi, annyi féle megoldást használnak. Rar-ból legalább csak egyféle van.
-
-
Dißnäëß
nagyúr
válasz
#68216320 #30045 üzenetére
Két érdekes dolgot vet fel ez a gondolatmenet:
1. "azonnal lekapcsol" - tehát nem High Availability (magas rendelkezésre állású) rendszer, hacsak nem egy elosztott fájlrendszer fut az egész felett és ez annak egy fizikai node-ja. De tekintsünk úgy rá, mint 1 standalone szervergépecske. Akkor miért kell raid ? (Sebesség faktor miatt megértem. Játék faktor miatt is, szeret az ember "kütyüzni", néha cél nélkül is).
2. rebuild során szoktak megmakkanni a diszkek, főleg a forrás diszkek (a másik kettőből az egyik), mivel többnyire ugyanazokat veszik, ugyanattól a gyártótól, ugyanazt a szériát.
Érdemes a jövőben diverzifikálni őket, nem nagyon, csak pont akkora mértékben, hogy feltételezhetően máskor következzen be meghibásodás a diszkek között.
A nagy sebességbeli eltérés (pláne logikai-geometriai) nem egy hasznos dolog, de én az itthoni gépemben simán kombináltam logikailag síkugyanolyannak látszó, magáról tök ugyanazt jelentő 2db 4T-s HDD-t, egy Seagate NAS HDD-t (lassú forgás, 64M cache) és egy WD Purple-t (lassú forgás, 64M cache). Ugyan a Purple helyett lőhettem volna WD Red-et is, de csak későn tudtam meg, hogy a Purple miért nem jó NAS célra (hiába pörög 7/24-ben, ha nincs a firmware-ben CRC hibakorrekció, a Seagate-ben van például. Mondjuk ZFS esetén töknyolc, ezért is maradt meg a Purple, de csak úgy egy alap raid és ext4 mellett meggondolnám 10x is, azt olvastam-e be róla vajon, amit kiírtam oda X hete).
De visszatérve a raid5-re, rebuild alatt hajlamos hullani, állítólag valami 8% körüli ennek az esélye (statisztikailag), ami eléggé szemmel is látható esély már. Érdemes 4 diszkből megcsinálni ugyanezt, 2 paritással, persze ha poreszt tart rajta az ember, arra elég a raid5 is (raid0 azért arra se, na).
-
vzozo
senior tag
válasz
#68216320 #30034 üzenetére
RAID5-nél azt vedd figyelembe, hogy ha az egyik diszked meghibásodik, akkor van kb. 10-15 órád arra, hogy kicseréld, és imádkozz közben, hogy egy második lemez ne adja meg magát, mert egyébként még nem épült újra a tömb, és mindent elvesztesz. Nem hiába nem menő a RAID5 már jó ideje...
-
Jester01
veterán
válasz
#68216320 #30036 üzenetére
Igen, dmesg parancs vagy /var/log/dmesg vagy /var/log/syslog
Valami ilyesmi:vmunix: raid6: avx2x4 gen() 14046 MB/s
vmunix: raid6: avx2x4 xor() 8443 MB/s
vmunix: raid6: avx2x2 gen() 13716 MB/s
vmunix: raid6: avx2x2 xor() 9066 MB/s
vmunix: raid6: avx2x1 gen() 10642 MB/s
vmunix: raid6: avx2x1 xor() 8393 MB/s
vmunix: raid6: sse2x4 gen() 9400 MB/s
vmunix: raid6: sse2x4 xor() 6250 MB/s
vmunix: raid6: sse2x2 gen() 9654 MB/s
vmunix: raid6: sse2x2 xor() 6333 MB/s
vmunix: raid6: sse2x1 gen() 4930 MB/s
vmunix: raid6: sse2x1 xor() 5272 MB/s
vmunix: raid6: using algorithm avx2x4 gen() 14046 MB/s
vmunix: raid6: .... xor() 8443 MB/s, rmw enabled
vmunix: raid6: using avx2x2 recovery algorithm
vmunix: xor: automatically using best checksumming function avxSzerintem a 100MB/s az bőven belefér a te prociddal is.
-
-
sonar
addikt
válasz
#68216320 #30023 üzenetére
Ha nem domaines akkor lehet, hogy ez segít:
server role = standalone
Illetve kell neked a netbios támogatás? Ha nem akkor tiltsd le a nmbd-tsystemctl stop nmbd; systemctl disable nmbd
szerk:
wins meg a netbios win10-hez már nem kell. sőt azt kell mondjam, hogy ha samba4-ed van akkor socket options sem kell. -
haddent
addikt
válasz
#68216320 #28540 üzenetére
Hasonló setupom van, annyi különbségel, hogy én mindenképp full minimált szerettem volna, ezért Arch linux van és rajta kodi-headless volt. Pont ugyanez a jelenség jelent meg, de nekem csak a Leia -val, előtte nem volt ilyen hülyesége..
Na mindegy, a lényeg, hogy nem sikerült megoldanom csak úgy, hogy van egy minimál window manager, csak éppen semmit nem észlelek belőle, mert autostart, autologin és indítja is a kodit. Így megszűnt ez a probléma, szóval tudom ajánlani, biztosan ubin is megy:- lxdm wm-t tedd fel engedélyezd stb. (lxde nem is kell hozzá)
- /etc/lxdm/lxdm.conf -ban legyen egy autologin=kodifelhasznalo sor
- az előbbi felhasználó home -jában legyen egy .dmrc fájl és tartalma:
[Desktop]
Session=kodi-standalone(Nálunk a kodi-standalone bináris is települ a kodi -val, nálatok lehet, hogy ez külön csomag)
Elvileg ennyi, reboot és egyből indul a kodi, nincs több display sleep
Ha még mindig nem megy, akkor érdemes egy .xsessionrc fájl is a homeba:
xset s off
xset -dpms -
bambano
titán
válasz
#68216320 #28473 üzenetére
1. szerintem lesz elég bajod a cuccal, totálisan felesleges még egy dockerrel is bonyolítani az életedet.
2. ha van fent lamp, akkor valóban igaz, hogyha felraknád az nginx-et is, akkor összeakadnának, de minek raknád fel, ha van fent apacs. azt a feladatot, amit az nginx-re bíznak, megoldja az apacs is. -
#68216320
törölt tag
válasz
#68216320 #28374 üzenetére
A bizonytalan szektorok száma 0 maradt. Ami jó.
Az viszont annyira nem nyugtat, hogy képes a hdd 1-1 szektora, ha nincs újraírva, pár év alatt ennyire gyengülni. Mert kb erről volt szó. Nagyrészt 1* rákerültek az adatok és főként read volt. Azt hiszem bekapcsolva hagyom az ubuntu server-en a default beállítást, miszerint minden hónap első vasárnapján raid resync-et csinál.
Tudom hogy megterhelő a hdd-nek, de nekem sem volt egy "szláv karnevál" backupolgatni. -
Jester01
veterán
válasz
#68216320 #28372 üzenetére
Ha egyszer sikerül beolvasni akkor lesz reallocated mert akkor át tudja másolni a tartalék területre. Vagy ha oda írsz valamit akkor is egyből a tartalék területre teszi. Ha nem kell róla adat akkor írd tele nullával és reallocated lesz. Mondjuk ha visszateszed a raid tömbbe akkor annak újra rá kell szinkronizálni mindent és akkor is reallocated állapotba fog kerülni.
Egyébként ha a smart logban látszik melyik szektort nem tudta olvasni (vagy az oprendszer syslogban) akkor célirányosan rá lehet próbálni mondjuk dd-vel.
-
bambano
titán
válasz
#68216320 #28364 üzenetére
"Irigyellek, hogy egy olyan 4TB-os HDD-t, aminél még csak gyenge szektor van nem pedig bad-block, te csak úgy kihajítasz.": ezek a diszkek maguk menedzselik a hibás szektorokat. amikor ez már kívülről is látszik, az azt is jelentheti, hogy elfogyott a menedzselésre fenntartott hely. tehát a diszk erősen halad az elromlás felé.
engem nem zavar, ha a hsz-emet mellőzöd, téged fog zavarni, ha az adataidat is?
-
Plasticbomb
addikt
válasz
#68216320 #28361 üzenetére
Self testet inditsd el rajta. Ne a rovid par perceset, de a hosszu, tobbszaz perces tesztet. Mielott elinditod, legyel biztos benne, hogy huteni is tudja a kornyezete a HDD-t, kulonben a homerseklet ellegge felkuszhat, ami nem lenne szerencses...
Vagy windows alatt HDSentinel feluet teszt, olvas ir olvas tesztet. Vagy, ha le tudod menteni az adatokat, vagy nem szamit, hogy mi van rajta, akkor felulet ujrainicializalast nyomj neki.
De minden esetben bizonyosodj meg arrol, hogy nem fog lefoni a meghajto.
(Nekem van egy NAS HDDm, ami idleben 40 fokos 15-25 fokos szobaban, nem visz ra a lelek, hogy ilyen komoly muveleteket engedjek ra, amig nincs egy masodpeldanyom a tartalomrol, nem akarom megkockaztatni, hogy tul magasra emelkedik a homerseklete a drivenak, s elszall pl az iro olvaso fej, s ledaralja a lemez feluletet...) -
bambano
titán
válasz
#68216320 #28357 üzenetére
oké, akkor a részletek:
ha raid1 tömbbe teszed a partíciót, akkor az elejére odateszi az md superblockot. majd csak utána tudod rátenni az ext4fs első szektorát.
tehát ha raidben volt a partíció, akkor csak úgy tudod megnézni, hogy van-e rajta fájlrendszer, hogy csinálsz egy ideiglenes raid kötetet és belerakod (vagy tudod, hogy a mountot hogy kell paraméterezni elcsúsztatott szektoros mounthoz).vagyis normálisan nincs látható fájlrendszer a raidből kihullott partíción. hasonló módon értelmetlen fájlrendszert kreálni, mielőtt visszarakod a kötetbe.
ezt azért érdemes tudni, mert elfeded a valódi problémát, így azt nem javítod meg, vagyis lélekben készülj fel rá, hogy megint szét fog hullani a kötet.
-
#68216320
törölt tag
válasz
#68216320 #28354 üzenetére
Update:
Közben kiderült, hogy valami okból eltűnt az ext4 fájlrendszer a /dev/sde2 partícióról.
Megformáztam (sudo mkfs.ext4 /dev/sde2) és így már hozzá tudtam adni az md0-hoz (sudo mdadm --manage /dev/md0 --add /dev/sde2)Viszont az update-grub elméletileg nem futott le mindegyik HDD EFI partícióján. Ezt valahogy rendbe tudnám tenni?
-
Frawly
veterán
válasz
#68216320 #27919 üzenetére
Ja, így már értem. Akkor mégis a RAID tömb volt a baj, hogy volt rajta adat, erre valaki a lemezeket nem RAID-ként használva beléjük írt egy üres GPT partíciós táblát, ami tönkretettte az egyik lemezen a RAID tömböt, amit így nem lehetett visszaállítani. Ez ellen nincs megoldás, kő kemény user error, a kezét kell levágni annak, aki ilyeneket csinál.
-
Frawly
veterán
válasz
#68216320 #27914 üzenetére
Erre nincs megoldás szerintem. Felül lett írva, ha nem emlékszel a partíciós táblára, akkor utólag elég nehéz megtalálni a partíciós határokat. Ennek semmi köze nincs a RAID-hez, nem RAID-en is így van. Talán valami hex editorban megnyitva fájlfoglalási táblákat keresve vagy hasonló, de az is nagyon hardcore hekkerség.
Én pont hasonlók miatt vezettem be régen egy jó szokást: a partíciókat bizonyos séma mentén alakítom ki, mindig kézzel (nem bízok semmit automata telepítők automata particionálására): MBR-en csak a legutolsó partíció logikai, ha szükség van rá, egyébként csak elsődleges partíciókat használok, GPT esetén már ezzel nem kell szórakozni. Illetve a partíciókat egész MB-os (2048 darab 512 bájtos szektorral osztható) szektorhatárokon kezdem, és a partíciók mérete egész gigabájt, ami egyben 10-nek is többszöröse (tehát nincs olyan partíció, ami 231 vagy 232,5 GiB, kivéve a legutolsó, ami a lemez végéig tart), de a mai nagy lemezméreteknél már néha arra megyek rá, hogy 50-nek vagy 100-nak is többszöröse legyen. Így ha el is csesződne a partíciós tábla, akkor is létre tudom hozni fejből, szépen végigmegyek rajta, hogy az első partíció 2048 szektortól kezdődött, és mondjuk 30 GiB volt, ami 30720 MiB, ami 32 212 254 720 bájt, ami 62 914 560 szektor). A következő partíció meg mondjuk 250 GiB, és annak is utánaszámolok. A végén meg az utolsó partíció a lemez végéig. Így pontosan rekonstruálni lehet a partíciókat, ha pl. megsérülne a partíciós tábla, nem kell azon szorongani, hogy nem tudom pontosan mekkora volt, meg hogy ott volt valami rés közötte.
-
-
-
-
#68216320
törölt tag
válasz
#68216320 #26809 üzenetére
Közben annyival előrébb jutottam, hogy meghívja a script-et csak valamiért a híváskor minden esetben a ID_CDROM_MEDIA változó hiányzik. Ha eject -t paranccsal csukom be, akkor 2x kiadva már látja hogy van benne lemez.
Valahogy azt kellene megoldani, hogy amikor hívja a script-et, akkor már legyen ez a változó behelyezett média esetén.
-
sonar
addikt
válasz
#68216320 #25970 üzenetére
A raid-re kell létrehozni még a raid előtt egy /boot és egy /boot/efi -t akkor nem szokott máshova kerülni.
Valamint gyakori ubuntu hiba, hogy a grub csak az egyik disk-re telepedik ezert kezzel fel kell tenni mindegyikre...
grub-install /dev/sdb
grub-install /dev/sdc
grub-install /dev/sdd -
Rimuru
veterán
válasz
#68216320 #25966 üzenetére
Ott mar van systemd? harmadik pelda
-
Rimuru
veterán
válasz
#68216320 #25841 üzenetére
Szerintem eleg lenne ha kihagynad a mappa letrehozast es torlest, esetleg tedd feltetelle a mountot, mappa letrehozas sikeressegetol fuggoen
#!/bin/bash
{
if [ "$ID_CDROM_MEDIA" == "1" ]; then
mkdir -p /media/cdrom && \
mount -t $ID_FS_TYPE -o ro /dev/cdrom /media/cdrom
else
umount -l /media/cdrom
rm -rf /media/cdrom
fi
} &>> "/var/log/automount_cdrom.log" &
Új hozzászólás Aktív témák
- Konteó topic
- Microsoft Excel topic
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- Argos: Szeretem az ecetfát
- A fociról könnyedén, egy baráti társaságban
- Eredeti játékok OFF topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- sziku69: Fűzzük össze a szavakat :)
- Synology NAS
- PlayStation 4
- További aktív témák...
- BESZÁMÍTÁS! ASUS H81M-PLUS H81 chipset alaplap garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASUS ProArt Z790-CREATOR WIFI alaplap garanciával hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- Dell P2419H P2419Hc Full HD LED IPS 24" + P2719H 27" LCD monitor (vékony keretes)
- Bomba ár! HP ZBook 15 Studio G3 - Intel Xeon I 32GB I 512SSD I 15,6" FHD I Nvidia I Cam I W10 I Gar
Állásajánlatok
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest