- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen monitort vegyek?
- Milyen billentyűzetet vegyek?
- Vezeték nélküli fülhallgatók
- OLED TV topic
- Milyen HASZNÁLT notebookot vegyek?
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- OLED monitor topic
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen TV-t 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
-
válasz
Rhino666 #34890 üzenetére
Az SELinux az annyira secure lett, hogy kb. használhatatlan. Gyakorlatban az AppArmor egy sokkal értelmesebb security modul. A kernel hardening az passzív védelem gyakorlatilag kikapcsolsz felesleges dolgokat, ez aktív. Előbbivel óvatosan, nagyon hülye guide-ok vannak.
Máig a kedvencem amikor valami kezdő security-s az ügyfélnél szólt, hogy kapcsoljuk ki az IP forwardingot, mert az nem secure. Ezután jeleztem neki, hogy a termék egy router -
válasz
urandom0 #34038 üzenetére
Egyébként a sudo legtöbb sebezhetősége ilyen snassz buffer overflow és hasonlók voltak, ilyesmik ellen meg nem véd a systemd sem (főleg, hogy azt is C-ben írták).
Kell hozzá a SUID bináris, az a fő gond. Ha nincs SUID bináris máris sokkal kevésbé problémás pl. egy buffer overflow.
A SUID/GUID koncepció lehet, hogy rossz, de erre vannak módszerek a különféle LSM-ek képében, mint pl. a SELinux és az AppArmor. Védekezzünk egy szar architektúra ellen ágyúval? Az SELinux egy katasztrófa, borzalmasan nehezen konfigurálható. Az AppArmor egy fokkal jobb, de azt is adott rendszerre kell belőni.
(#34044) sh4d0w Volt nem túl régen olyan projektünk amit valami ruszkik gányoltak SysVinit-el, na az egy kalap fos volt. Közben Yocto-s embedded rendszeren systemd-vel annyi egy unit fájl, hogy megírod a service fájlt (aminek eléggé RTFM manuálja van) és "inherit systemd".
-
A u-boot a jó rendszer architektúra szempontból. Az csak egy bootloader, beinicializál amit kell (pl. network, hogy TFTP legyen) utána berántja a kernelt és eltűnik a memóriából. A kernel a memória képet a device tree-ből kapja, ami eszköz specifikus és a kernel tree-ben van normál esetben. Ez az attack vectorokat is jelentősen csökkenti. Btw ARM esetén pl. microcode sincs, mert RISC.
A BIOS annyira konyhanyelv, hogy maga a vendor is BIOS-nak hívja a mai napig.
De x86-on van ez az SMM dolog amikor végrehajtás közben visszaugrik a proci a BIOS-ra. Szóval ott a memóriában marad a BIOS, és kell is, mert az kezeli a hardver csatlakoztatást.
(#33448) Livius A mikrokód igazából tök mindegy, a kernel úgyis felupgradeli early boot-ban ha régi.
-
Tehát bebootolok 3-as futási szintre, tty auotologin utána automatikusan indítson el egy alkalmazást.
Ez valami sysvinit? Vagy mar systemd? Mert utobbiban nincsen ilyen futasi szint szeru baromkodas. Mi az, hogy tty es autologin? Daemont akarsz inditani, scriptet futtatni? Megvaltoztatni a login binarist (utobbi kicsit meresz)?
-
válasz
CPT.Pirk #33256 üzenetére
Tegyük fel, hogy szünetmentes táp ellenére is előfordulhat, hogy kihúzzák a tápot vagy egyszerűen nem szabályosan állítják le, csak kinyomják... Ragaszd bele a gép kábelét a szünetmentesbe
(Komolyan)
Ilyesmi működhet, pl. embedded rendszerek esetén rendszeres. A kulcsszó az overlayfs. Az ext4 elég elavult fájlrendszer, lehet érdemes elgondolkozni egy BTRFS-en. Az biztosan feljön crash után, max. elvesznek egyes fájlok. Az ext4 simán lehalhat teljesen.
(#33257) emvy Nem szabad kikapcsolni a page cachet, mert baromi lassú lesz. Inkább limitálni kell, hogy mennyi ideig lehetnek a dolgok a memóriában [link]
-
Ilyet alapból nem nagyon kéne csinálni, de erre van a -static kapcsoló. Kelleni fog a libc statikus verziója (.a). Különböző glibc verziók között papíron nem létezik kompatibilitás. Gyakorlatban is minimálisan. Manapság az első i7-ekre szokás fordítani.
gitre meg a readme-be bökd bele hogy ubin főzted, expected to work on every distro
(#33190) coco2 Miért raksz valamit bináris formában gitre?
-
Próbáld ki "Type=oneshot"-al.
bash-5.0# sudo systemctl enable mpdlcd
Synchronizing state of mpdlcd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable mpdlcd
insserv: script mpdlcd is not an executable regular file, skipped!
update-rc.d: error: no runlevel symlinks to modify, aborting!Ez nem értem mi a fene, mit ír ki ez a SysVinit-ről?
-
Az NFS tényleg elég gagyi egy csomó célra, az SMB sokoldalúbb rendszer. De az SMBv1-et tényleg felejtsük már el a francba.
(#32832) emvy A CPU használat networking esetén értelmetlen kérdés protokoll nélkül. Nem mindegy mit csinálsz. Maga a fogadás az csak egy másolás szinte, de pl. egy 10G-s linken csak az alap dolgok el tudnak vinni elég sok CPU időt.
(#32838) Sub-ZeRo Első körben ezt nézd meg. Bár nem feltétlen module param, config time is ki lehet herélni belőle. zcat /proc/config.gz | grep CIFS_ALLOW_INSECURE_LEGACY + samba configból is ki lehet lőni.
-
De engedi lecsatolni, csak blokkolo call. Szoval addig nem fog visszaterni a mount, amig nem fut le a sync. Ez normal Unix mukodes. Tobb fele keppen is el lehet kerulni:
- Alapbol sync-el mountolsz es akkor nincs page cache
- A dd-t futtatod sync-el
- Hivsz egy sync parancsot a dolog vegenA swappiness-nek nincs koze a page cache-hez.
-
válasz
f_sanyee #32777 üzenetére
hA dirty_ratio-val az a baj, hogy az a memoria szazalekat jelenti, szal ha sok akkor lehet egyszerre nagyon sokat kell majd kiirni. HDD-n en joval konzervativabb szamokat hasznalnek. Az expire_centisecs is 3000 vagyis 30s, az baromi sok. Ha beut a szar akkor nem igazan lesz jo egy ideig a gep semmire amig malmozik es sync-el. Plusz egy kernel crash-nel potencialisan 30s logot vesztesz, ami nyilvan itt nem akkora gond
De akkor is baromi sok.
-
Ha ilyen nagy fajlokat mozgatsz kulso hdd-re akkor nyugodtan be lehet kapcsolni a sync-et. Vagy szimplan futtatni egy sync-et ha vegzett. Az 1MB block size nyugodtan lehet sokkal tobb, en 128MB-vel meg hasonlokkal szoktam. 1MB-vel szoktuk irni 64MB-s, 128MB-s flasht beagyazott rendszeren.
-
válasz
lionhearted #32747 üzenetére
A socket az socket, nem device.
-
válasz
fatpingvin #32692 üzenetére
Én a script irányba mennék.
-
Nem akarom DOS-olni magam, így konkrétat nem mondok. De minden gyártó 5G eszközei DPDK-val mennek. A reklám anyag a valóságban még jobban kihúzható. Egy AMD szerver proci ma már brutál erős, olyan FPGA-t nem tudsz csinálni ami akár azt megközelíti. Nincs HW gyorsítás, a HW maga a proci. Még a hardware checksumming-ot is kikapcsolja a DPDK. Közvetlenül a hálókártyáról pollolja a real time futó thread (övé a mag, nincs preemptive scheduling) a packeteket. A pfSense nem használhat DPDK-t, mert az Linux only szoftver.
Mond Linusnak, ugyanis a kernel architektúra továbbra is x86 maradt
(#32607) bambano Nem értek egyet, azokban a szegmensekben pont a mips/arm gyorsabb adott áron és fogyasztás mellett. Az igazán brutál routerek (több 100G vagy akár több T) azok viszont PC alapúak.
(#32603) Lenry Viszonylag friss, támogatott LTS kernel. Problem?
-
x64 nincs és sose volt. Mindenki csak x86 hívja szakmai körökben. A kiterjesztés neve x86-64.
Nem a Linux végzi és nem az x64 végzi a routingot semmilyen formában olvass már utána kérlek. De, ez a state of the art. Közvetlenül a network kártyából mennek ki a csomagok userspace-be, meg onnan vissza.
BSD szintekkel gyorsabb routing és fűzfalban, nem véletlen lett az használva tűzfalakban nagyon sokáig bare metal telepítésekben, amíg nem volt a CPU-kben olyan sok dedikált gyorsító. A BSD gyorsabb volt 15 éve, azóta sok minden történt.
[link] Itt vannak performance tesztek.
-
válasz
inf3rno #32572 üzenetére
Információbiztonságban általában úgy megy, hogy megveszik a hardvert, ami tud annyi sávszélességet, aztán kalap. Kicsiben, ha több ezer node-ot kell deployolni akkor már elkezdenek inkább konfigurálni
Otthonra egyet értek amúgy a BSD alapú megoldásokban.
(#32579) bambano Tudtommal mindenki DPDK-t használ ([link]) magas szintű szűrésre. Ehhez kell egy Linux kernel, meg valami jó brutál vas. Az ilyen arm, meg mips 1 gigára jó ha elég.
(#32583) vicze1 Ma már olyan brutál erősek az x86 procik, hogy nem igazán kell FPGA. Akár virtuális gépen elmegy ilyesmi, csak kell neki adni megfelelő hálózati kártyát. De régen is FPGA volt, ASIC-el nem szűrsz forgalmat
-
válasz
sh4d0w #32569 üzenetére
Szervert nem szoftveres tűzfallal védünk elsősorban, hanem hardveressel. Ha kell az otthoni szerver, tegyél elé rendes eszközt: Bitdefender, WatchGuard, Mikrotik, Netgear - és akkor nem probléma, hogy az iptables kicsit többet eszik a CPU-dból, mint az nftables
Hülyeség, egy mai Linux bőven megállja a helyét közvetlen az interneten. Lassan a core network routerek 100%-a Linuxot futtat. Plusz a dedikált firewall eszközök is általában Linuxal mennek.
Különösebb baj amúgy nincs az iptables-el. Ami szerintem nagy hibája az a teljesen külön IPv4 és IPv6 stack. De mivel amúgy mindkettő netfilter module akár egyszerre is használhatod a kettőt.
-
válasz
fatpingvin #32517 üzenetére
Igen
A wines és a Linuxos nem ugyan olyan. A wines amúgy tradicionálisan okosabb (mármint az NT), de ma már linuxon is vannak bonyolultabb permissionok is, a szokasos unixon felül.
-
válasz
Speeedfire #32103 üzenetére
Az, azt megmondja, hogy nem ez a bottleneck. 60kB/s-t még az USB 1.1-nek is vinnie kéne.
-
válasz
Speeedfire #32100 üzenetére
iostat mit mond?
-
válasz
fatpingvin #31995 üzenetére
NV-re csak a zárt drivert használd. Ha nyílt drivert akarsz felejtsd el az nvt.
szerk.: fura, biztos jó drivert használsz?A fordítós dologra én elsősorban ramhibát gyanítok. Második esetben környezeti problémát. Ha minden ugyan az nem lehet más a kimenet a proci márkája miatt, wtf
-
válasz
fatpingvin #31949 üzenetére
Driver nyilván van hozzá, mert a többi disztróban megy
Én vagy arra tippelek, hogy kiszedték a drivert, vagy simán bugos és valamiért nem működik az újabb kernelben. Nem hiszem, hogy sokan tesztelnék ezt a drivert...
-
válasz
BlackSoft #31946 üzenetére
A nomodeset az csak framebuffer módot állít be. Attól X11-nek még kéne mennie, a VESA módnak meg főleg (nagyobb felbontású terminál).
Most nézem ezekben a xeonokban nem mindben van IGP, akkor viszont valaminek az alaplapon kell adnia a képet, ha nincs. A 2020-as isoval nézd pontosan mi van benne. A dell windowsos driverei alapján valami Matrox cucc
Lehet valami bug a kernelben, nem gyakori manapság a matrox GPU...
-
válasz
fatpingvin #31915 üzenetére
Spagetti kód at its finest.
-
De miért kéne új kernel? Amíg van security patch, meg bugfix addig tökéletes a dolog.
5.10-es kernel viszonylag friss
is lehet.A legrégebbi még támogatott LTS kernel a 4.4.
Adott verzió support ideje 6 hónap és csá, ez elég messze van az LTS-től, csak a kernel ősrégi benne. Ott van normális upgrade path, meg pont a kernelt annyira nem szokták csesztetni. Nekik full saját águk van. Nagyon veszélyesnek tartom a kernel erőltetett frissítgetését.
Szóval nincs olyan, hogy a kernel nem frissül, max. olyan van hogy ritkábban frissül és nincs benne nagyobb újítás. Az eredeti postban direkt nem használtam a frissítés szót. A patchlevel frissítés nem upgrade.
-
Nem minden distro rolling. Se a Red Hat-en és származékain (fedora, meg a centos) kernel upgrade egy verzió alatt, se openSUSE Leap-en, vagy fizetős SUSE-n. (Nyilván thumbleweeden van, de az full rolling, ott release sincs.) Debianon sincs. Az ubuntu LTS egyik legnagyobb hibája a kernel upgradelgetése szvsz. Vagy legyen rolling vagy legyen fix a verzió.
-
válasz
gregory91 #31881 üzenetére
De egyébként hogyan lehetne a csomagot "karbantartani"? Újabb verziót feltölteni vagy törölni az egész csomagot?
Normális distrón amikor egyszer ki lett adva utána nincs verzió upgrade, csak security és bug fix. Kivéve kivételes esetben, nem úgy mint az ubuntunál ahol képesek kernelt upgradelni. Ezeket a karbantartó backportolja. Illetve nyilván új release esetén lehet utána kell húzni a buildelő scriptet.
-
válasz
magortaltos #31670 üzenetére
Az fdisk a másik kollegának szólt... Alapvetően nagyon nem mindegy, hogy java vagy python. Javaban valami olyan IPC megoldás kell amit támogat a java, első körben mondjuk egy Unix socketre lőnék. Ha python vagy hasonló natív nyelv akkor foglalnék 2MB-os hugepage-eket aztán go. Amit bambanő mondott a posix shared memory szintén jó megoldás lehet, de elég lassú tud lenni, plusz borzalmas az API-ja, de standard és jól támogatott. Megoldás lehet egy fájl is viszont ott valahogy meg kell oldani a lockingot.
-
válasz
magortaltos #31668 üzenetére
Erre kb. 30 féle módszer van. Pontosan mire akarod használni?
(#31667) oatis Próbáld fdisk-el, az nem szokott kérdezősködni
Btw biztos DOS partíciós tábla? Manapság kezd a GPT lenni az elterjedtebb.
-
válasz
sh4d0w #31615 üzenetére
Az a baj, hogy én legtöbbször csak a vmcoret látom
A legváltozatosabb módokon tud megpusztulni a hardver:
1. SSD hiba
2. Ram hiba
3. Kilazult proci
4. Túlfeszültség
5. Túlmelegedés
6. Döglött BIOS chip
A legenda szerint egyszer olyan is volt, hogy Dél-Amerikában egy béka belemászott a cuccba -
-
válasz
f_sanyee #31609 üzenetére
+1 soha nem láttam memória hibás crasht telehányt mcelog vagy valami külső probléma (túlmelegedés, feszültség problémák) nélkül. A memória nagyon érzékeny cucc, pillanatok alatt kinyírja a legappróbb túlmelegedés vagy túlfeszültség.
(#31608) Lenry Csak a bitsorozatot változtatja, mert sérülés esetén hatással lehetnek egymásra a bitek. Na alapvetően ebből az ilyen minta kellene (fizikailag amit nem tudsz, hogy van):
010101
101010
010101Eddig elég gyorsan eljut, a vége felé már nagyon bonyolult mintázatokat használ és elég kicsi a valószínűsége, hogy azzal hibás lesz, ha eddig nem volt az.
-
-
Nem nagyon, főleg nem susén ahol a btrfs az alap fájlrendszer és elég alaposan tesztelt. A ramhiba onnan jött elő amúgy, hogy egyszer jártam így, szétszedte a metadatat, hiába töröltem fájlokat továbbra is tele volt. A régebbi susékon a snapper default configja nem igazán szerencsés, újabbakon már agreszzívebben takarít.
-
-
válasz
Speeedfire #31211 üzenetére
Lehet SELinux vagy apparmor védi, vagy valami hasonló security modul.
-
A btrfs elvileg tud olyat, hogy nem az egész eszköz RAID1, hanem csak egy mappa rajta. Valakinek megvan, hogy ezt hogy kell bekonfigolni? Vannak olyan adataim amik megvannak ugyan máshol, de messze és nem árt ha helyben is dupla a tárolás a szívás elkerülése végett.
-
válasz
regener #31125 üzenetére
Első körben megnézném valami mással. Ha az jó akkor a következő lépésben másik kliens programmal. 3-dik körben kezdeném el túrni SFTP szerver konfigját.
Firewall nincs közte? Manapság igen beteges tűzfalak vannak. Eddigi kedvencem ami letiltott egy sima FTP kapcsolaton tar.gz átvitelt, mert volt benne egy olyan python verzió amiben van egy durvább sec hole (ami a valóságban nem is volt benne, mert backportoltuk a patchet).
Új hozzászólás Aktív témák
Hirdetés
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Path of Exile 2 early access kulcs
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Gamer Notebook! Acer Nitro 5! Csere-Beszámítás! I5 11400H / RTX 3050Ti / 16GB DDR4 / 500GB SSD!
- iKing.Hu - Motorola Razr 50 Ultra Midnight Blue Használt, karcmentes állapotban 12 GB RAM / 512 GB
- AKCIÓ! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Lenovo IdeaPad 3 17ITL6 - 17.3" HD+ Intel 6305 - 8GB - 256GB SSD - Win11 - MAGYAR
- AKCIÓ! Apple Mac Studio M1 MAX 2022 32GB 512GB számítógép garanciával, hibátlan működéssel
Állásajánlatok
Cég: FOTC
Város: Budapest