-
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
-
Dißnäëß
nagyúr
válasz
ubyegon2
#33754
üzenetére
Kurvajó, mikor a kezdő kung-fu-s megmondja a másik kezdő kung-fu-snak, hogy mi a profi kung-fu
Made my day.Mondjuk ahhoz képest, hogy megoldást nem hoztál, a többiektől sem látok sok megoldást, szerinted a kezdőben jobban boldogulnék ?
A Windows-al arra akartam utalni, hogy abban lehet szabályozni policy-ben, hogy a felcsatolt médiumot hogy kezelje, legyen írás cache, vagy csak olvasásra legyen ilyen.
Minden bizonnyal tud ilyet a Linux is, mert amikor megkapja a seggébe az USB kütyüt, lefut a háttérben valami mount script az egyik bugyrába eldugva. No, ott lenne számomra az a mount paraméter, amihez hozzá tudnék adni egy sync-et, vagy hasonlót, ugye erre várjuk a választ.
Áhh, felejtsd el. Menj.
Zseniális.
(Közben megoldottam).
-
Dißnäëß
nagyúr
válasz
5leteseN
#33725
üzenetére
Az nem megoldás, hogy egy progress bar előbb végigmegy 3x akkora tempóval, majd befejezettnek jelent mindent a program, miközben az OS a háttérben írogat még fél óráig.
Valós progress bar-okat szeretnék látni mindenhol.
sync, nocache, egyéb, ... mi a magic mount option ?
-
Dißnäëß
nagyúr
Sziasztok, hogy lehet megadni ennek a tetves Cinnamonnak, hogy bármilyen USB disk-et cache nélkül mount-oljon, mint Windows-ban a "Quick remove" opció ? Ne legyen write cache.
Debian. Szétvet az ideg
Másolok rá filmet és majd még iostat-ot figyeljek meg minden hülyeséget, hogy vajon a cache mikor írta ki, amikor már átmásoltnak jelentette a fájkezelő amúgy... hogy kivehessem a gépből...Köszi !!
-
Dißnäëß
nagyúr
AMD fronton HDR-t illetően van vmi infótok ?
Debian Testing + Cinnamon, semmi különlegesség, de megvettem most a csilivili monitort és a redmondi szoftver jól hajtja, a Linuxban viszont nincs erre utalás, hogy HDR-t kezelne (se VLC se Settings se semmi).
A GPU a Ryzen prociba integrált (4650G).
-
Dißnäëß
nagyúr
Ez bármelyikre igaz, de vannak arany középutak, például nekem a Testing egy nagyon jó balansz stabilitás és frissesség között, biztosan van olyan része, amiben a stable még jobb, de nem jöttek még velem szembe a Testing esetleges bennragadt bugjai, cserébe viszonylag friss rajta minden csomag. (A Stable meg jóval lentebb kullog a Testing után, elég nagy köztük a gap szerintem, ZFS-nél rá is futottam ezzel kapcs. egy kis bibire, de amúgy ok. És mégsem kell a rendszert olyan szinten manuálisan felépíteni, mint az említett másik kettônél.
Szóval kis szopásokat bevállalok még, nagy mélytorkosakat nem
-
Dißnäëß
nagyúr
válasz
gregory91
#33373
üzenetére
python-ozgatok és kísérletezgetek, játszadozok, infra és konténeresdi.
Tanulás céllal.A desktop itthoni gépem Debian Testing, nekem bevált már 10+ éve.
QEMU-val van jópár VM-em, amiken a kő minimál telepítés van, gyakorlatilag röhejesen kicsi ahhoz képest, amekkora a host.. mind memóriában, amikor fut, mind háttértár foglalásbanVolt 5950X-em, de nem használtam ki, leváltottam 4650G-re, itt azért ha több VM indul és dolgozik, érezni, nem annyira izompacsirta. De azt hiszem, vissza már nem váltok a sokmagosra (bár ki tudja, kegyetlenül tepert az a proci).
Igazság szerint a kíváncsiság hajtott el mindig RedHat-Fedora irányba, de jó ez így, ha maradok ezen, azt hiszem.
Ubuntut próbáltam még, nem tetszett valamiért (tök szubjektív dolog, tudom), Linux Mint az egyedüli Ubuntu származék, amivel kifejezetten meg tudtam barátkozni.
Arch, Gentoo és ilyesmik, nope. Öreg vagyok én már ahhoz
-
Dißnäëß
nagyúr
Jó reggelt szakik !
Hogyan tudnék egy teljes könyvtárszerkezetből (sok alkönyvtár) kitörölni egy bizonyos típusú fájlt ? (És ha a könyvtárban egyedül volt, azt is törölje).
rm -rfd ./*.txt
csak ott törli azt a txt-t, ahol állok, nem megy alkönyvtárba tovább, hogy az ott lévőt is törölje.Egy egész fájlrendszert szeretnék így szelektíven kitakarítani némi sallangtól.
-
Dißnäëß
nagyúr
Kézzel mount-olok, nem fstab-ban még.
Default..
exfatprogs version : 1.1.3Logokban nincs nyoma a chown-os operation not permitted-nek, az egész /var/log összes fájlja közül egyedül auth.log és syslog frissült ebben a percben, hogy megint rápróbáltam és semmi köze hozzá dolgok vannak benne (cron mindegyikben a hülyeségeivel).
Szerintem feladom, lesz ntfs akkor. Azért köszönöm.
-
Dißnäëß
nagyúr
válasz
bambano
#32505
üzenetére
szerintem az ext4 is csinál ilyet.
nem, azzal tök simán megy minden.
mountolás után újra add ki a chown-t. emlékeim szerint elég egyszer.
sudo-zva sem engedi a mount-olt /mnt/valami könyvtár permission-jét állítani mindaddig, míg alatta az exfat/mnt-ben állva és be van mount-olva alá az exfat:
valami@desktop:/mnt$ sudo chown -v valami:users sam870evo1t
chown: changing ownership of 'sam870evo1t': Operation not permitted
failed to change ownership of 'sam870evo1t' from root:root to valami:users
valami@desktop:/mnt$
Ugyanez csont nélkül lefut, ha nincs alá mount-olva az exfat, VAGY ext4 van (például) alatta. -
Dißnäëß
nagyúr
Sziasztok, segítenétek kérlek megfejteni, mi a lóhere van ? Valamit nagyon benézhetek.
- /mnt/ -ben létrehozok egy könyvtárat egy új Samsung SSD-nek
- beállítom user-nek a desktop módú linuxon használt user-emet, group-nak a "users"-t
- még nincs mount-olva fs ugye...
- sudo mkfs.exfat /dev/disk/by-id/ata-Samsung....... -> létrehozom a fájlrendszert, amit Windows-ból is láttatni akarok (dual boot), ezért exfat
- lemegy, minden oké
- sudo mount /dev/disk/by-id/ata-Samsung....... /mnt/valami - mount-olás megtörténik
- létrehoznék könyvtárat - permission deniedKintebb lépek eggyel és látom, hogy amint az exfat-ot fel-mount-olom a neki létrehozott könyvtár alá, a /mnt/valami könyvtáram permission-je átvált root/root-ra, amint umount-olom alóla az exfat-ot, ismét user/group.
ext4-el nem csinál ilyen hülyeséget, gyönyörűen elérem mountolás után az új fájlrendszert a mezei user alól read/write.
Hogy lehet ezt kikerülni ? (még fstab-nál nem tartok, csak konzolban küszködök).
És a durva, hogy sudo-zva sem engedi a mount-olt /mnt/valami könyvtár permission-jét állítani mindaddig, míg alatta az exfat. Ha umount-olom, akkor azonnal viszi sudo-val is, csak felesleges, mert visszaáll az üres könyvtárra a user/group jog.
Nem értem.
(Debian) -
Dißnäëß
nagyúr
Mert a luks header-ek is a kulcson volnának. Ha kulcs ki, akkor pedig BIOS beállítás mentén indul az SSD egy részérôl a W10-em, az SSD-n lévô EFI partició alapján.
Azt sajnálom, h nincs jól összerakva a dm-crypt és az LVM kezelés installerben. Hiába NEM titkosítottam az usb-n lévô /boot-ot, az SSD-re tett gyökeret pedig már igen, nem úgy hagyja ott a rendszert a telepítô, hogy boot folyamat során feloldja a gyökeret elôször, hanem keresi, keresi, keresi az LVM VG-t és LV-ket, majd kitesz a sivatagba
hogy hát nem találja ôket. Találtam egy cikket errôl, ki-ki ugrik az ember installer közben konzolba mókolni, kipróbálom.
Egyszer jöjjön össze, onnantól jó a dolog.
Lehet benézek #debian-ra vagy valahol nyomot hagyok nekik, hogy ezt így 10-es verzió körül meg lehetne igazán oldani, mert installerben szépen össze lehet rakni amúgy a dolgotés tök jól érti az installer azt, hogy crypto /dev/mapper-es eszközre teszem az LVM-et, csak nem jól implementálja mentéskor, aztán reboot és elhasal. -
Dißnäëß
nagyúr
válasz
Dißnäëß
#30885
üzenetére
Jahh. EFI kellett neki. Szupi.
Viszont a gyökeret (ami ssd-n van) installerben titkosítottam. Rá LVM, 1 rendszer és egy swap LV, és hadd szóljon.Bootol, de elôbb keresi az LV-ket, ahelyett, hogy feloldana.. busybox rulz.
Random-key-el titkosítottam, nem interaktívra. Jó lenne tudni, ezt hol tárolja /boot-on belül.
crypttab persze üres, /dev/mapper nincs is..
*sóhaj*
Holnap újra. Root titkosítás nélkül, mert esélyes, hogy dm-crypt + LVM a Buster installerben el van szabva
.. -
Dißnäëß
nagyúr
Jó estét !
UEFI módban lehetséges olyan, hogy a /boot -ot USB-n tároljam ? Nem látja a stick-et, pedig a telepítő lement. Ha CSM-et aktiválom, akkor látja, csak vmi hibával a legelején elszáll, MBR módot vár valszeg.
Lehetséges, hogy így CSM aktivált módban kellene MBR-es telepítőt kreálnom rufus-al és így tudok egy másik külön pendrive-ra /boot -ot tenni ?
Vagy maradhatok UEFI módban, csak az usb stick-re kellene raknom egy EFI partíciót a /boot létrehozása előtt ?
-
Dißnäëß
nagyúr
válasz
Frawly
#30878
üzenetére
Igen, lossless-ek, a konverternek csak kényelmi szempontokon kell átmennie nálam. Régen, lossy zenéknél, mp3 fénykorában még ügyeltem arra, melyik konvertert használom, az vajon lame library-t használ-e vagy valami egyebet, szórakoztam ogg-al, mpc-vel, stb, de mára már lényegében csak lossless-em van, így az igazi. Nagyon rég hallgattam már mp3-at. Van pár egzotikum, amit még használtan vadászgatok itt-ott, mert képtelenség fellelni online lossless-ben, de ezek 'rarities' kategória.
-
-
Dißnäëß
nagyúr
válasz
Frawly
#30874
üzenetére
Na, az Aimp konverter része is hasonló.. DeadBeefre ránézek akkor kicsit jobban újra. Köszi a leírást. (Simán elfér haladó Linuxban, why not?)
Ez is csak egy Linuxos program 
Ritkán konvertálok amúgy, csak Wavpack, Ape, ALAC-ot néha, FLAC-ba, illetve ha DTS 5.1/FLAC 2.0 MKV/MKA, akkor abból a 2.0 FLAC részt külön kiveszem. -
Dißnäëß
nagyúr
válasz
Frawly
#30867
üzenetére
Meglátom, mi lesz, már hétvégén nincs időm újrarakni az OS-t, de jövő héten meglépem. Viszonylag gyorsan belakom, nincs ezermillió progim.
Snap-ről köszi a részletes beszámolót, lejövök a szerről, végülis az AIMP-ot is Wine alól futtatom (a lejátszó részét nem használom, viszont a konverter szekció valami beteg jó lett szerintem).
-
Dißnäëß
nagyúr
válasz
sh4d0w
#30855
üzenetére
Így más a dolog és nekem is kezd büdös lenni. Köszi. Nem tudtam, .. az nvidia driver-től eltekintve nagyon én sem csípem a prop. cuccokat, lásd snap/Canonical. Szerintem meg is győztél Debilről, aahhhhhh teszek egy próbát megint
hátha túlél egy évet grafikában.. (néha a Fedora is megbizserget, mi-lenne-ha alapon, erre a desktop-minilab gépre. Cégben úgyis RHEL van, meg CentOS, bár nem adminisztrálok.Chrome: egyébként Vivaldizok, őskedvencem, a RÉGI Opera emlékére (az eredeti készítője a Vivaldiban él tovább, a jó ideje már kínai kézbe adott Opera meg .. hagyjuk). Emlékeztek a régi Operában a "Show tabs in separate rows" opcióra ? Csak egy pipa és teljes szélességben több fül-sorban volt képes a fülek címeit megjeleníteni felül. Istenverte mai "kreatív" böngészők egyike sem tudja ezt külső plugin nélkül, és az is vacak. Gyakran van az informatikában az, hogy visszafele lépdelünk egy engine váltás miatt.. (ez akkor történt az Operával, amikor váltottak).
@mpc-hc, most olvasom: +111111 Fapad, de az aztán mindent evett nálam anno, miután rommá tömtem a gépet codec-ekkel (még W7 alatt).
-
Dißnäëß
nagyúr
válasz
Frawly
#30853
üzenetére
Ha bármelyik lejátszó a piacon tudja csak messziről is ezt a fajta két vizualizációt 1 képernyőn, akkor megvett kilóra.
Deadbeef-et próbáltam, 10 percig bírtam. Lehet nekifutok mégegyszer majd.
Snap-el mi baj ? Ubuntu, de nemsokára újrarakom másik bloatware ikertesójával a rendszert (Kubuntu). Sajnos a Debian Stable nagyon hátul van, be-be ugatgat 1-2 .deb csomag, ha valami nem a legfrissebb, a testingje meg amikor egy frissítés után elcseszi az nVidia DKMS környékén a grafikámat, az úgy erősen no-go nálam. (Pedig szívem szerint tenném a jó kis debil minimált ismét). Bár Ubuntuk is Deb. Testingből jönnek, azért egy fokkal jobban teszteltek, ez látszik. Grafika pl. mióta élek, nem fosta még össze magát nálam alattuk, Debianon meg már vagy 100x. (Proprietary-val).
Erős Debian-hívőként kénytelen voltam desktopra megalkudni az Ubuntu törzs tagjaival és tök oké eddig. Persze ízlések és pofonok, csak ha már megjegyezted a Snap szemetet.. nálam nagyon kerek és túrásmentesen megy minden most, ez nagyon jó feeling, és annyira még azért nem érzem "intrusive"-nak az automatizációit itt-ott, hogy idegesítsen.
Béke.
-
Dißnäëß
nagyúr
válasz
elektron@
#30848
üzenetére
Foobar, én nem tudok lejönni róla. (Mondjuk nem egy csicsa cucc, tény, de k* jó).
Debian XFCE alatt is, Ubuntu alatt is, Kubuntu alatt is.. bárhol igazából, ilyen nagyobb disztrókon.sudo apt install snap
snap install foobar2000Utána lehet tologatni alá a plugineket ezerrel. Foobar alatt a virtuális Z: meghajtó a linux / könyvtára, onnan meg már rendben vagy. A felületet érdemes jól személyre szabni, rommá lehet konfigolni.
-
Dißnäëß
nagyúr
Nem túl jó a környék, ahol lakok, földszint, nincs bizt. ajtó sem és minden ablak utcára is néz, egyik egyikre, másik másikra. Bár egy központi lécsőházajtó van, de na.
Ha meg tudja, mi van a gépben és nem egyből a MÉH-be megy vele, akkor nyert 6x4TB diszket és egy SSD-t, egészségére, már pattinthatja is fel rá a partíciókat és használja, amire tudja, vagy eladja, stb. Nem hinném, hogy a kvantumszámítógépek holnapután kezdenének terjedni mainstream-ben. (Ha pedig igen, addigra majd kvantumtitkosítunk).
Egyszerűen csak így vagyok nyugodt, ennyi. Az érdekelt volna, hogy ilyen kernelcserés upgrade-ek során valami boot loader (uefi-vel nem vagyok annyira tisztában) is frissül-e, vagy csak a fájlok /boot-ban és kész.
-
Dißnäëß
nagyúr
Én jobban szeretem a titkosítási kulcsaimat és a diszkek luks2 header-jeit ezeken tudni, ha pedig ki van kapcsolva a gép, a nyakamban, zsebemben, pénztárcámban. Természetesen az usb is titkosan, csak jelszóval nyílik, de ha kinyílt, utána automatikusan nyitja az összes diszket tovább a header-ök, key fájlok segítségével. (Ezekről van backup-om felhőben is veracrypt konténerben, meg emailben is magamnak elküldve, nem gémél).
Arra nincs igényem, hogy távolról is újraindítható legyen, bár van csilivili router-em és dinamikus dns és WOL, ez most nem kell.
Ez egy desktop gép, amolyan szerver is, home lab, nevezzük akárminek, nem egy dedikált 7/24-es klasszikus szerver (de gyakran van bekapcsolva napokat. Nem mindig, de gyakran). És az egész eddigi IT-s életem rajta kb. (Cold backup van kettő is).
-
Dißnäëß
nagyúr
Sziasztok Szakik !
/boot milyen gyakran frissül ? Nagyjából nagyon ritkán, jól sejtem ? Ahogy a boot folyamat elején megvan a gyökér könyvtár az OS-el (ami másik eszközön lenne), lényegében /boot el van felejtve, stimm ?
USB eszköz lenne. Boot folyamat végén automatikusan át-mount-olva az OS gyökerében lévő /boot könyvtárba és kihúzhatom a stick-et a gépből.
Mi az, amire ügyelnem kellhet egy ilyen esetben ?
Amit eddig látok:
1. 2-3 USB eszközöm is legyen, identikusak. (Elég fájl szinten, nem kell dd, igaz?)
2. apt full-upgrade és hasonlók esetén a boot-ban lévő dolgok is frissülhetnek, ha mondjuk jön le egy új kernel is.. ez az OS diszken lévő /boot könyvtárban le is megy, majd végül átmásolom ezt a visszadugott stick-ekre és jó vagyok, stimm ?
Kubuntu, uefi.
-
#30830
Dißnäëß
nagyúr
lionhearted
#30829
Dißnäëß
nagyúr
válasz
lionhearted
#30829
üzenetére
Tényként írtam felsorolás szerűen, egyértelmű, hogy itthonra NAS célra jobb a Seagate. A Purple kényszer vétel volt, valóban alma és körte.
-
Dißnäëß
nagyúr
Igen. Nekem a W10 VM-ben fut ugyan, de van az a felhasználás, amikor jól jöhet. Mindeközben a ZFS Windows-os portján is dolgoznak állítólag, hogy milyen tempóban, passz.
----------------
10 reallocated sector-om van 2db HDD-n is, a 6-ból.
(5db Seagate NAS, 1db WD Purple).A Seagate-eken 100 lehet ezek száma (legalábbis HDS szerint, de lehet rosszul értelmeztem az oszlopok leíróit), a Purple-ön 200.
Hááát... ééérdekes. De amíg nem szaporodnak, zümmögjenek csak.
Régen volt gyenge minőségű táp miatt is több HDD-vel gondom, mire rájöttem, hogy bakker, mi van, ha táp. Nem gamer config volt, hogy elfogyott erőben, hanem szimplán valami nem volt kerek, kicseréltem (nagyobb VGA miatt) és eltűntek a hibák, én meg pislogtam, ez most mi volt. Aztán raktam csak össze.
De a mostanim egy 500W FSP, VGA elhanyagolható (GF 710), kifogástalan, a NAS vinyók futottak eleget már, ezt tudom, szóval nem lepődök meg, csak ez, hogy bejelzett pár hete és 1 hétig ott volt a 99% aztán visszagyógyult, érdekes jelenség volt. Két manuális scrub-omba került, pusztán intuitív alapon. Egyik a bejelzés után, másik pedig akkor, mikor visszagyógyult (hiszen mindkettő változással jár). Mindkétszer hozta a CKSUM hibát és korrigált is a ZFS.
Jól elvittem a témát, sry mindenkitől. És köszi, hasznos kis duma volt.
-
Dißnäëß
nagyúr
válasz
inf3rno
#30818
üzenetére
Hát utal rá, nyilván nem egészséges az olyan kütyü, amin megjelenik 1-2 hibás szektor, de ha poreszt tárol polcon, nem téma, ha pedig logikai rétegekben van megoldva ennek a hibának az áthidalása, szintén nemtéma. Azonnal nem temetném.
Mindjárt megnézem, mennyi a reallocated sector count-om a "gyógyult" HDD-mre.
-
Dißnäëß
nagyúr
Olvasáskor nem ? Mert mondjuk azt nem kell tudnia, mi van a hibás szektoron, de annak ténye, hogy ott valami nem oké a fej alatt egy ponton, mikor elsuhan alatta párszázszor, szerintem azt képes lenne detektálni. Lásd HDSentinel Surface Scan, Read mód. Lazán pakolgatja be nekem a feketéket egy szar vinyón.
Mondjuk nem WD Purple (ahol nincs firmware szintű CRC), hanem Seagate NAS, ahol meg van.
Na mindegy, azt hiszem, a lényegre választ kaptam, tehát LUKS mellett egy adott titkosított blokk úszik, leves, a ZFS meg erre ugyanúgy megoldás innentől, mintha LUKS nélkül válna valami alatta inkonzisztenssé. Jó. Kiváló.
-
Dißnäëß
nagyúr
válasz
Frawly
#30811
üzenetére
Szerintem ugyanazt beszéljük, mert én végig ezt mondom... HDD hiba, LUKS adatvesztés, ZFS meg resilver és kész, illetve ha pont rámegy, elvileg még auto-healing is, de nyilván resilverezem, ha épp úgy jön ki, hogy meglátom. (HD Sentinelre néztem rá, 1 bad volt 2 hete vagy 3-4 napig, 100/99, aztán visszajött 100/100-ra. Na mondom mi ez ? Resilver, checksum hiba, javítva. Megköszöntük neki, vállvonás. Csak egy LUKS-ot közbeékelve -integrity kapcsoló nélkül (dm-integrity), mivel a ZFS pont erre való, akartam megtudni, vajon mi lenne, ha.
Akkor lényegében értve vagyunk.
-
Dißnäëß
nagyúr
Ez tiszta és világos, csak nem a kérdésre adott válasz.
De jó, ha mások is tudják. Tehát újra: HDD-n történik valami és lesz 1 bad sectorom, amirôl az OS tudomást szerez. Ahogy történt is nemég, ami el is tûnt magától (HDD firmware pótolta spare tartományból, zfs meg korrigált scrub során).
Ezt a hibát egy ntfs, egy fat, akármi, felvenné azaz megjelölné rossznak, normál esetben. Csakhogy ott LUKS "szemét" van, ergo a feloldott mapper device-on megjelenítôdik vajon a hiba ? Hogy a zfs lássa.
Mert ha egy fizikai szektor sérül, HD sentinel is jelzi, az a LUKS titkosított blokk, ami ehhez tartozik, szintén sérülni fog és feloldhatatlanná válik, emiatt - feltételezném - a mapper device-on is a legkisebb logikai egységnyit hibaként fog betudni a rendszer, az ezen ülô zfs meg majd a többi HDD + checksum -ok segítségével pótolja az adatot, máshol elhelyezve azt.
De lehet nem ez történik, csak gondolkodom hangosan. A sorrend biztosan az, hogy amit egy réteg elrejt, elmaszkol, a felette lévô nem lát, ez vili. A lényeg pont az lenne, hogy lássa.
-
Dißnäëß
nagyúr
válasz
Frawly
#30791
üzenetére
bambano találta fején a szöget, de én fogalmaztam hiányosan lehet.
ZFS raid-ezek, csak ott ezt nem raid-nek hívják, hanem raidz-nek, mirrornak és stripe-nak, de lényegében user szemszögbôl mint funkcionalitás, raid.
Nem akarom egyelôre a zfs beépített encryption-jét használni, azt szeretném, ha random szemétnek látszana minden HDD tartalma, erre a LUKS2 képes, ha a titkosítás header-öket máshol tároljuk.
Szóval:
1. HDD-k LUKS2 titkosítása
2. Az elôállt mapper device-okkal (amire a fájlrendszer kerülne) ZFS pool-ok építése.Az érdekelt, hogy fizikai HDD hiba, bad sector esetén mit lát az ember a mapper device-on. Bad-ként megjelöli, vagy mi lesz pontosan. A zfs legfelsô layerként ezt lekezeli szépen (mirrorom és raidz1-em egyaránt van).
-
Dißnäëß
nagyúr
Sziasztok,
ha LUKS2-vel titkosítok 3 diszket, ami logikai köteteken utána raid-el mókolok (vagy zfs-el): ha egyik fizikai hordozón megjelenik egy bad sector, azt a LUKS automatikusan átvezeti az érintett logikai kötetre és ott is megjelöli bad-nek azt a blokkot ? (Amit egy erre tett zfs valszeg látna és korrigálna a replikák segítségével egy ép blokkal).
-
Dißnäëß
nagyúr
Sziaszok,
van arra ötlete valakinek, milyen irányban kellene-lehetne tovább menni.. ? Adott pár célgép, amikre sftp-vel akarnánk kliens oldalról feltölteni fájlokat. A célgépek identikusak, előttük egy load balancer dobálgatja a forgalmat ide-oda. Mivel a kliens oldalon csak 1 virtuál ip és 1 hostname látszik mindegyik tényleges host-ot illetően, viszont a valóságban mikor melyik host-on végződik a kapcsolat, változik a host RSA key, ami oké a kliensnek, ha éppen random a nála eltárolt key-ű host szolgálja ki a kapcsolatot, minden egyéb esetben errort dob és nincs kapcsolódás. Ezen ellenőrzés kikapcsolása kliens oldalon nem megoldás. A host-okra egységesen 1 kulcsot rátenni (mindre ugyanazt) szintén elég hülye lenne (még ha működne is, valaki így csinálta és megy). SSL terminálás a load balanceren szintén nem megoldás, ha onnan titkosítás nélkül megyünk a célgépekre. Lehet kapcsolódó kliens oldalon kellene vmit script-elni, vagy megoldható a címzett oldalon valami ügyes trükkel ? Úgy tudom, egy kliens oldalról látszó host-hoz csak 1 key rendelhető (ha lehetne többet is, az megoldaná instant a fejfájást). Köszi.
-
Dißnäëß
nagyúr
válasz
Graphics
#30221
üzenetére
1. A multiboot pendrive-odról (aminek puszta létrejötte is X-akta számomra is) tehát feltelepítettél egy 16G-s SSD-re egy Ubuntut.
2. Ha fentebbi állítás helytálló, akkor install végén körbenézett a Grub telepítője, hol talál alternatív, egyéb oprendszereket, megtalálta az említett multiboot telepítő pendrive-odon a Windows telepítőt és úgy gondolta, jól teszi, ha felveszi az elérhető OS-ek listájába a Grub menübe. Nem tesz különbséget aközött, hogy az most Windows telepítő, vagy készre telepített és használt Windows rendszer.
2.5 Nekem úgy jön le, hogy MBR-be tettél Grub-ot, nem UEFI-zgetsz, de lehet tévedek. Mondjuk a kettő nem zárja ki egymást, max +1 kis kavarodás a logikában.
3. Grub menüből ki kell venned a Windows menüpontot és kész. Próbaként boot-olj be a feltelepített Ubuntu-val, nézz be /etc/grub fájlba, illetve /etc/default/grub.d/ -ben találhatókba, ha látsz Windows-ra vonatkozó bejegyzést, biztonsági mentés után gyepáld ki, végül 'update-grub' parancs és ha jól csináltad, nem lesz a következő boot-odnál a Windows telepítője ott zavaró jelenségként. UEFI esetén máshol (is) kellhet gyepálni, abban majd a nálam okosabbak
Csak tipp..
-
Dißnäëß
nagyúr
Sziasztok,
úgy érzem, van egy témám, amivel kapcsolatban jobb, ha erősítésért jövök, hátha tudtok valami okosat mondani.
Adott egy 240-es Intel SSD-m, eléggé használt már és ezen van minden, ami rendszer. Két rendszerről beszélünk: egy W10 (ezt játékra tartom, ritkán veszem elő) és egy Debian (lvm-en).
Kb. így néz most ki a felállás. Historikus és lustaság oka van a kicsit káosznak, bár annyira nem vész:
Model: ATA INTEL SSDSC2BW24 (scsi)
Disk /dev/sdd: 240GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 524MB 523MB ntfs Basic data partition hidden, diag
2 524MB 628MB 104MB fat32 EFI system partition boot, esp
3 628MB 645MB 16.8MB Microsoft reserved partition msftres
4 645MB 79.3GB 78.6GB ntfs Basic data partition msftdata
5 79.3GB 80.3GB 1000MB ext4 boot
6 80.3GB 106GB 25.2GB lvm
8 106GB 168GB 62.9GB lvm
7 168GB 240GB 71.6GB ext4 W10_VM1, 2, 3 - szerintem érthetők kb.
4 - natívan futó W10 C:
5 - Linux boot
6, 8 - Linux rendszer cakkpakk, eredetileg csak 6, majd hozzácsaptam némi plussz helyet 8-assal.
7 - Korábban natív W10 D: amit leürítettem és most egy W10-es VM-nek fenntartott partíció, virtualizálva futtatok 1-2 totál Windows függő dolgot a Linux alatt, semmi kül.Szeretnék átköltözni erről az SSD-ről egy újra. Ti hogyan tennétek ?
Újratelepítés nélkül.Elképzelésem szerint fogom magam és butában át-dd-zem egyiket a másikra. Ezzel kapcsolatban pár aggályom van és talán meg is válaszolom magam, miért NE:
1. eszközök fstab-ban nem /hda, hdb és hasonlók mentén vannak mount-olva, hanem uuid-k alapján. Ami jó és így helyes (általában), de ha tegyük fel, dd-vel áttolom erről az újra az egészet és arról indulok, az újon lévő fstab-ban át kell a régiről az újra írnom az újonnan kapott UUID-re, ha jól sejtem. Ami eddig szép és jó, de honnan lesz az új eszköznek új UUID-je, ha rá dd-ztem a meglévő régit ?
2. A méretük is eltér, 240G -> 500G, pláne nem tudom, dd helyes lenne-e és hogyan viselkedne a történet.
3. Ezért úgy gondolom, valami ügyességgel az alap UEFI-tartozék kis partíciókat át kéne mozgatnom (1,2,3 és lehet 4-et is) dd-vel az új SSD-re. Sőt, akár mindet.. egyenként... Ehhez először a partíciós táblát kellene lemásolnom egyikről a másikra. Mivel ? (van ilyen parted/sgdisk funkció? Vagy első X bájt/kilobájt ? GPT.)
4. ..és akár dd nélkül, sima copy-val is másolhatok onnantól. Bár a W10 allergiás lehet dolgokra, szóval ..
A lényeg, hogy most egyelőre úgy gondolom, partíciónként dd-zve jó lehet a sztori, az, hogy mi hol helyezkedik el partíción belül, garantált dd által és nekem is megfelel így.5. Ha megvagyok minden partíció át-dd-zésével, egy 9-ediket létre tudok hozni, lvm-be beveszem és kiterjesztem vele a meglévő helyemet, vagy behasználom másra.
Szerintetek ? (Nem biztos, hogy külső tool-t akarok minderre használni, nem zárkózom el, csak szeretném saját fejből megpróbálni először).
Hibázni tudok eleget, az új SSD-n ügyködnék úgyis, a régi kvázi "readonly"-ban lenne a folyamat során (folyamatra értem), szóval nem kockáztatok semmit igazán. Valszeg egy live cd alatt lépném meg a nagy költözést. Minden hasznos véleményt megköszönök.
-
Dißnäëß
nagyúr
válasz
inf3rno
#30154
üzenetére
Hááát maradok a saját nyelvén, valami Processing vagy mi, jó lesz az, nem egy nagy rakétatudomány ahogy elnéztem. Egész érthető. Csak kéne egy induló szett
PoE jó dolog, rahedli kis Arudino kütyüt elbír egyetlen kábel, de valszeg valami ultraolcsó kis wifi modullal oldom meg, így egyetlen kábellel végig tudok menni áramellátást illetően a kütyük hadán sorosan, nem kell switch-ből kiindulva csillagpontosan húznom mindenhova 1 tyúkbelet. Előbbi esetben kell a wifi az adatátvitelhez, utóbbi esetben meg PoE miatt magára a kábelre tehetem rá az adatot is, de inkább wifizek, még a többlet költség ellenére is. Szerintem tálcánként - de majd kiadja úgyis a tényleges projekt - elég lesz 1 kisebb Arduino kontroller a "cserepekbe" tett szenzorokat figyelni, de majd meglátom. Jó kis hókamókák ezek. Milyen poén lehet úgy enni valamit az asztalon, mondjuk egy kis tepsis fűszeres burgonyát, hogy a krumpli a saját biokrumplink, amit a kütyük neveltek fel, az ubisali uborkája és fokhagymája dettó, paradicsom, stb. minden az asztalon az "üvegházból" van Nagy álmom így élni. Egyszeri nagyobb költség, de aztán évekig nyugi van. Egy RPi-re már kellene mindig OS frissítés, ez, az, amaz, az Arduino kellően buta ahhoz, hogy 20 év múlva is csinálja ugyanazt, amit ma, zéró logic. Bár egy mai Pi is elvan, de azért ott az OS mégiscsak egy Debian rajta, logolgat, kicsit önállóbb életet él, tényleg nem egy olyan eszköz, amibe beleírod a programot és elvan míg szét nem esik. De tuti lesz Pi is a rendszerben, de szerintem ő csak a fej lesz majd. -
Dißnäëß
nagyúr
válasz
inf3rno
#30150
üzenetére
Úgy van, ahogy a kolléga mondja, határvédelemben kopog az ember.
Kicsiben privátban én is NAT mögött vagyok, van egy olyan-amilyen iptables script-em mégis a linux host-omon, de ennyi. Ha Kína bejönne a Netflix-en keresztül az okostévébe és elkezdené törni a gépem, ne essen el azonnal, kicsit megnehezítem a dolgukat (pár perccel)
Viccet félre, paranoidnak lenni mindig jó és hasznos.
Tanulás: én most meló mellett próbálok tanulni annyi mindent, hogy nem győzöm
Elektronika, frontend, node.js és régi dédelgetett álmom, az Arduino. Akarok egy vagy termőföldes, vagy teljesen hidropónikus minifarm projektet építeni vele, talajnedvesség szenzorokkal meg minden pittyputty-al és mindig azon kattogok, hogy ha már node-ot tudok, akkor miért nem Raspberry Pi-zek, de rájöttem, hogy nem kell nekem OS ahhoz, hogy alap tökautomatizált rendszert építsek fel, ami bekapcsolás után pár mp-el már működik is és ha 20 évig nem update-elem, akkor sem történik semmi. Egyszerű, igénytelen, teszi a dolgát. Szóval maradok az Arduino-nál és majd valamiféle aggregált módon állok hozzá az egészhez, hogy 1 Arduino több szenzort visz, az őket begyűjtő és vezérlő Arduino-k (nem sok) pedig végül befutnak 1 Pi-be mondjuk. Hát ez is egy hosszú út, de legalább látom értelmét. Próbálok mostanság olyat csinálni, aminek van is értelme, nagyon elvesztem az elmúlt években haszontalan dolgokban. Mikrotik lett volna még, de azt is annak gondolom, pedig piszok jó cucc, de többet hoz nekem real-life-ban egy raklap itthon termesztett zöldség, amit automatán öntözök és monitorozok + figyelmeztet egy naptár funkció, ha megérett "aratásra", mint az, hogy most milyen router oszt nekem egy netet. Sajnos egy nap még mindig csak 24 órából áll 
-
Dißnäëß
nagyúr
válasz
inf3rno
#30144
üzenetére
Látom jó kis egészséges vita alakult ki REJECT és DROP körül az általad linkelt fórumon.
man iptables -ben a REJECT target írója Jozsef Kadlecsik, lehet elő tudnád ásni az arcot, ha utánajárnál. Nála lesz olyan infó, ami ÚGY VAN és 100% hihető, feltételezem (ha 1. a Netfilter csapat tagja, 2. ő írta a REJECT-et).De amúgy meg azt is látom, hogy az iptables is kifutó lassan, itt az nftables helyette: [link]
Picit más szintaktika és logika, de többet tud + teljesítményben is jobb. Lehet érdemes lenne erre felülni, mielőtt túlzottan kitanulod az iptables-t. (Én meg ipchains-el szívtam anno sokat és iptables-ön tanultam. Nem kell egyik a másikhoz, most sem kell iptables mester lenni, hogy nftable guru legyél.. ha már kézzel írogatunk) . -
Dißnäëß
nagyúr
válasz
inf3rno
#30138
üzenetére
A második felvetésedre: hááát ez jó kérdés, iptables-ben (vagy még az elődjében, ipchains-ben) volt anno olyan target, hogy REJECT, talán ma is megvan még akármilyen okok miatt, na az viselkedik úgy, hogy elutasításkor visszajelez, hogy "ide nem jöhetsz be" , aminek puszta megtörténte miatt elárulva, hogy ott van gép, port, szolgáltatás, amit lehetne törni. Az akkoriban erre válaszul hozott DROP target már olyan végződtetés, hogy onnan semmi infó nem megy vissza a küldő fele, szóval mintha fekete lyuknak beszélne, DROP esetén nemigen tudja megállapítani, van-e ott valami vagy sem. Még TCP SYN dolgokkal bohóckodhat, de mindenre fel lehet készíteni egy gépet úgy megcsinálva, hogy távolról isten se mondja meg, hogy ott van valami az adott ip címen, hacsak nincs fizikai hozzáférése a network-höz.
Első felvetésed:
Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat. Vagy valamit nagyon nem értek a hálózati kommunikációból.
Az, hogy egy port nyitva van-e, egy dolog. Arra is kihatásunk van, MIRE van nyitva. Egy nagyonegyszerű csecsemőbiztos példa most így fejből gyorsba, a teljesség igénye nélkül, csak az INPUT chain-re fókuszálva (pedig egy korrekt tűzfalban az OUTPUT is szűrve van, legalábbis akkor, ha magáról a tűzfal gép védelméről beszélünk.. ha a többiekéről, akkor meg a FORWARD mindkét iránya nat mangle és egyéb táblákban is, felhasználástól függően).Tehát egy marha primitív kézi fal arra a host-ra, amit védeni akarunk, és egy SSH-t beengedünk. Illetve a mi saját kimenő csomagjaink visszatérő lábát is
különben semmit nem lehet erről nagyon csinálni azon kívül, hogy egy buta SSH kiszolgáló.
iptables -X
iptables -F
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPTÉs akkor a vastaggal emeltet lehet (igazából erősen illik) cizellálni, hogy source-ot adunk neki, egy adott ip-t vagy ip régiót, satöbbi.
Kérdésedre a válasz a state-ekben rejlik, azaz a 22-es port knocking alatt csukva marad NEW csomagok számára, de természetesen ha egy másik host már sikeresen bekopogott oda és kapcsolódva van, őt egy RELATED,ESTABLISHED szabály beengedi, ami generalizáltan, minden protokollra és minden source/destination portra értelmezve van. (Ezért nem szoktam használni ebben a formában, csak szűkítve, de akkor hasznos).
Ha csak 22-es portra akarunk kétszintű definíciót, ami beengedi a már felépült SSH-k visszatérő lábait, de újakat nem enged be korlátlanul:
iptables -A INPUT -p tcp --dport 22 -m limit --limit 10/s -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPTEz minden 22-es portra érkező ÚJ kérést úgy enged be, hogy csak másodpercenként 10-et enged ebből, a többit dobja. Minden új kérésre érvényes, de csak újakra. Az alatta levő sor pedig korlát nélkül enged minden 22-es portra beeső SSH csomagot, aminek van egy korábbi kimenő párja a táblákban már, így ha egyszer kapcsolódott valaki, egy SSH fájlátvitel sem okoz limit miatt gondot, bármennyi csomaggal korlátlanul kommunikálhat az sshd-vel.. szóval RELATED,ESTABLISHED lábakat nem szokás (vagy csak nagyon paranoid esetben) limit-el ellátni, burst-re is ügyelve de arra most nem térek ki.
A port knocking NEW-ra értendő, hiszen nem egy korábban kiment csomagra adott válaszcsomag az, ami érkezik és kopogna be, hanem új csomag, amolyan azonosítatlan, követés nélküli akarna bejönni. Őt csak számolni kell, mint kopogásszámot, de dobja is DROP-ra, míg a szekvencia nem teljesül, ergo nem lesz kimenő lába, mindig minden "kopogó" csomag NEW-nak minősül.
Ha ezen dimenzió mentén nézed, máris nem lehet azt mondani, hogy nyitva egy port vagy zárva: van, amire nyitva, van, amire limitáltan nyitva és van, amire zárva.
A limit egyébként hasznos, de érdemes a burst-öt is definiálni az elején, illetve tudni azt, hogy ha a szabályban definiált limitet pont egy hülye bot, vagy akármi lezabálja, Te sem jössz be már
Csináltam egyszer olyat, amikor egy hobbigépem törni akarták (még kezdő szöcske koromban, amikor 22-esre tettem ki SSH-t a nagy világhálóra), hogy láttam a logokban a millió jelszópróbálkozást, auth-ot, úristen mondom mivanitt, bruteforce indult ellenem
és úgy döntöttem, teszek 22-es portra NEW próbálkozásokra egy 3/m limitet, azaz 3 próbálkozás / perc, utána csőváz mindenkinek.1x tudtam belépni, utána kvázi örökre kizártam magam, mert a percenkénti 3-at elérte a próbálkozások száma a botok által, a fal zárt, én meg ugyanúgy kint maradtam egy putty zárás és újranyitás után
Szóval mindenre a limit sem megoldás, de mondjuk túlterhelések ellen egy egészséges mérték beállítása jó lehet, ami azon képzeletbeli határ felett van, ahányan akarnak oda jönni amúgy, botokkal együtt. Meg általában ezek a zombi gépek, botok, akármik többnyire 22-es porton kopognak, tehát ha a 22-est vagy az sshd-ban, vagy iptables-en keresztül nem 22-re rakod ki a publik interfészen, hanem valami tökmáson (1024 felett lehetőleg), az sokat segít. (Persze ne híres port legyen lehetőleg). SSH esetében úgy tudom kell induláskor a root jog, de egyébként ha most IRC szervert vagy akármi egyéb alkalmazást akarnál kitenni a netre, mindenképp 1024 fölé érdemes tenni, mert 1024-es alatti portokhoz root jog szükséges, azt meg nem akarjuk odaadni minden processznek (hacsak fel nem vesz utána nobody-t stb, de az megint más tészta). Azt vettem észre mindenesetre, hogy 22-ről ha elviszed SSH-t bármilyen módszerrel is, drasztikusan lecsökkennek az auth próbálkozások számai. Ez még nem jelent semmit, csak plussz háttérinfó, könnyítünk az sshd lelkén kicsit
Knocking esetén a NEW próbálkozások számát kell nézni, nem a RELATED,ESTABLISHED-eket, értelemszerűen. Utóbbiakból másodpercenként irdatlan sok jöhet és kell is bejönnie, lásd fájlátvitel, így a már felépült SSH kapcsolat nincs elkaszálva. NEW-val meg kopogjanak bátran, akinél teljesül, az eljut a szent grálhoz
-
Dißnäëß
nagyúr
válasz
inf3rno
#30114
üzenetére
Még annyit, hogy nagyon figyelmesen olvasd el stopperos összefoglalóját, amit linkeltem előzőben. Arany
Lesz benne érintve memória is, struktúra is, minden ilyesmi.Nem ez lesz az első 1-2 pool-od ma megkreálva, ami életed legjobban agyonoptimalizáltja lesz
de nem elméleti fizika azért. -
Dißnäëß
nagyúr
válasz
inf3rno
#30112
üzenetére
Így van, csak dedup, amit ritkán ajánlanak hogy használva legyen, totál felhasználásfüggő. Legalábbis ZFS fronton a "földi halandó" ne dedup-al kezdje. Egy médiafájlokat tartalmazó fájlrendszeren, ahol - feltehetően - nincs két egyforma fájl, se alatta lévő blokk, meg úgy semmi sem, teljesen felesleges és memóriafaló. Compression szintén nagyon függ sokmindentől, be is lehet kapcsolva (úgysem tömörít pl. már eleve tömörített fájlokat, lásd megint a híres média fájlok, FLAC-ok, mkv-k, stb), de nálam pl. a fontos fájlokat és vegyesbazár mindenfélémet tartalmazó mirror-on be van kapcsolva, míg a nagy médiafájlokat tartalmazó raidz-men kikapcsoltam már kreáláskor (ez kihatással van nem csak a puszta tényre, hogy tömörítve van-e adat, hanem arra is, hogy a blokkméretek fixek, vagy változóak). ZFS fine tune-ról külön könyvet lehetne írni, ezt sokan mondják és én is így látom.. nagyon mélyvíz és nagyon eltérően viselkedő megoldás ahhoz, hogy csak úgy általánosan egy skatulyába téve kijelentsünk róla dolgokat úgy, mint egy ext4-ről mondjuk. De a generalizálással mindig is gondja van az emberiségnek, törekszik mindenki az egyszerű dolgokra, na a ZFS nem az
De öröm az ürömben, hogy default beállításban is egész vállalhatóan műxik és amire létre lett hozva, az adat integritás garantálása, arra hibátlan. (1 lemeznél tudja jelezni a hibát, 2 vagy több esetén egy raid felállásban már korrigálni is). Az említett COW is fura így megemlítve, ugyanis a zfs alapból cow-s, ez a default másik jellemzője (ezért is SSD barát, ZOL TRIM támogatás hiánya ellenére - de már dolgoznak azon is). Meg nem csak fájlrendszer, hanem logikai kötetkezelő is egyben, kicsit LVM szagú. Dedup nélkül a zfs nem eszik sokat, csak valamivel többet, az ARC miatt (is), de az pl. paraméterezhető, ha a default beállítás nem tetszik, viszont dedup nyilvántartó táblák komplett kiesnek a képletből, default install és használat, pool/dataset creation esetén sincs bekapcsolva, jobbnak látta mindenki ezt off-ban tartani, enterprise felhasználásban egy (vagy több) dedikált storage admin ember már feltehetően még nálunk is jobban tudják, mit csinálnak és miért, ha szakértői a ZFS-nek és bekacsolhatják a dedup-ot.
ZFS-ről csinált egy marhajó összefoglalót stopperos fórumtárs, [link] , aminek már megírtam egy 2., gyakorlati részét jómagam, majd hamarosan publikálom talán. Lesz benne kicsiben is, VM-ben elpróbált játékok, meg a saját nagyobb példám is. Valamikor..
Nálam itthon 24 terányi diszk van különféle konstellációkban ZFS-re befogva, eddig nagyon elégedett vagyok vele. Nemsokára jönnek a cache drive-ok is, két enterprise grade SSD személyében, szóval egy egész pattogós házi storage motyó áll össze, de most sem panaszkodom. Talán idén át tudom a mostani workstation PC-met konvertálni egy igazi komoly storage vassá, egy új rack házikóban, ez még a jövő zenéje.
Az ARC mérete általában a rendelkezésre álló RAM /2 -ig mehet max, nálam most reggel óta van bekapcsolva a gép és 32G RAM-ból 5.76G foglalt, ebből a linux szerint 1.5G a buffer/cache és mérete a ZFS-ről történő olvasás és ráírás ellenére nem látszik változni perpillanat.
-
Dißnäëß
nagyúr
válasz
Frawly
#30104
üzenetére
Ezt itt és most azonnal megvétóznám, egyrészt így tanultam ki magam is a zfs-t anno, mielőtt élesben elcsesznék valamit, (nem, nem kell alá tenger memória, a közhiedelemmel ellentétben), másrészt 1 szem vCPU-val és 1-2G RAM-al simán lehet php-zni, node.js-ezni és megannyi akár architekturális, akár backend és middleware fejlesztést és szimulációt csinálni. 8G RAM mellett ne mondd már, hogy nem tud az ember lecsípni némi RAM-ot és valami hasznosat alkotni, mert most azonnal magamhoz nyúlok
és neeem akart megfulladni semmi, hogy nincs alatta 100 CPU mag..Szerintem kicsit bőkezűen osztod az erőforrásokat, vagy csak nagyon egy irányba akarsz lőni ágyúval verébre. Értem én a nagyszerveresdit, de azért van a lónak túloldala is (ezt leírtam) + nyilván ki milyen jól lovagol, e kettő között még rengeteg lehetőség és tudnod kellene, melyik fázisban vagy éppen.
De egy webshopot, egy társkeresőt (nem azt, de hasonlót, mindegy), egy mittomén milyen dolgot, sok-sok egyéb komoly pénzcsináló projektet simán összerakok egy ilyen laptopon, egyet meg konkrétan a haverommal közös cégünknek rakott össze egy külsős fejlesztőbrigád és az egész motyó elfutna ezen az említett laptopon lazán, legalábbis a mostani 30-40 user-el (ha felfutott, az egy más téma, de itt már nem is csak DEV, hanem egyenesen UAT-ról beszélek).
Egy BSS stack-et már nem rakunk össze ezen, az igaz. Meg számlázórendszert sem, meg SAP gigainterfészeket sem. De az azért pont a ló túloldala, meg az ágyúval griffmadár kategória, itt most verébről volt szó végig.
És de, pont az InnoDB HA a másik, amit itthon teszteltem ki és paramétereztem mikor hogyan szénné, 3 kis VM-ben, előtte meg próbálgattuk a cégben még anno három másik soványka VM-en szintén, úgy kellett sírni a kapacitásért... de az MSSQL a másik akkor, ne csak szerencsétlen MySQL legyen mindig, itt sincs semmi dráma 3 ekkora VM-en egy Always On-t összelökni. Nem egy nagy sztori az egész, sem erőforrásban, sem konfigolásban, de igen, 3 csöpp VM-ben is elindul és tesztelhető, így tettük mi is. Tudod, írtam is, hogy PROD-ra semmiképp, de előtte.. na .. feltételezem, tisztában vagy a szoftverfejlesztés főbb állomásaival és az egyes állomások erőforrás igényével, szerintem nem kéne csodálkoznod, hogy tesztelésről van szó, igen, fejlesztői teszt DEV-en, egy ilyen laptopon, lazán. Előző munkahelyemen egy pénzügyi startup-nál giga portál tesztelődött ugyanígy lokál laptopon 8G RAM-al és ment fel utána a nagyvasakra következő fázisba, végül állt élesbe felhőben és csattantak rá többszázezren. Nincs ebben semmi különös, pedig ott azért nem a snake-et írogatták.
No offense, csak ne dobálózz már olyanokkal, hogy én dobálózok, egyrészt nem dobálózás, másrészt direkt hozok ilyen példát, mert mindenki - lásd, még egy szakmabéli is - azt gondolja, ezek ilyen ördögtől való boszorkánykonyha "atyaúristen" elérhetetlen szupertechnológiák, amiket ne lehetne ledemózni 3 csoffadt kis VM-en. Dehogynem lehet, röhögve, nekünk powerpoint helyett élesben ment az főnökök előtt, hogy kirúgtuk az egyik lábát és néztük, mikor hogyan viselkedik melyik node, később ugyanez durvább teljesítmény teszt alatt, meg még több tucat egyéb..
Most mi is 150+ magos dedikált farmon futtatjuk a motyót elképesztő mennyiségű RAM-al, de ez már más tészta. És 3 fentebb említett szaros kis VM juttatott minket oda, hogy elkezdjük ezeket tisztességesen kitesztelni, megnyúzni, agyonhajtani, használni, meg az én hajnalba nyúló óráim itthon az akkor még csöpp konfigomon, nem a consulting cég jött csillióért megmondani nekünk a tutit. Ja bocs, de, de ők azt se tudták, mi ez még tavaly és hoztak egy olyan megoldást elsőre, ami ugyan HA-t adott, de konzisztenciát nem, meg még pár egyéb dolgot sem.
Ne dobálózzunk olyanokkal, hogy mit lehet és mit nem, mert csak kreativitás és odafigyelés kérdése és nagyon sokmindent lehet.
-
Dißnäëß
nagyúr
válasz
Frawly
#30102
üzenetére
Hát feszegettem szerver célra, a környezet laptop volt mindvégig. Nem írta meg a kérdező, milyen CPU végül. Vt-d nélkül sok esély nincs, vt-d-vel is csak szolídban, kicsiben (i5 és fentebb az ő esetében, új vasaknál már az i3 is 4-magos + vt-d-s).
Na közben meg is van a Deb10 testing friss install egy 1 magos 512 RAM-os VM-be.
root@debian:~# free -h
total used free shared buff/cache available
Mem: 482Mi 56Mi 350Mi 0.0Ki 75Mi 413Mi
Swap: 509Mi 0B 509MiLehet ezzel bohóckodni sokat
Kérdés, mit akar virtualizálni. 8G fizikai RAM-al még egy 4G-s W10-et is tud, igaz, mire bejön, elmehet vacsizni közben Mindig a "mire" a kérdés.
-
Dißnäëß
nagyúr
válasz
Frawly
#30098
üzenetére
Öööö, szerintem ne nekem
De nagyjából kifejtetted kicsit részletesebben, amire én is utaltam a kérdezőnek.@bambano: +1, igazából attól függ, mire kell. Ilyen alap logikai izolációkra, hogy semmi durva teljesítményelvárás, csak ül 1-2 buta szerver démon a maga kis elzárt homokozójában, néha kiszolgálva 1-2 kérést, még 2 fizikai mag is bőőőven oké. De újabb i3-ak 4 fizikaival pláne, igen.
De Frawly-nak is igaza van, csak lehet, félreértett engem (vagy én fogalmaztam nemjól), eszem ágában nem volt i3-azni szerverbe, de kérdés, mit tekintünk szervernek. A home lab, vagy egy fejlesztő kezében egy sima laptop is lehet "szerver" arra a pár órára, míg beröffenti a dolgokat, mert miért ne lehetne. (Legalábbis nálam ez tipikusan ilyen kis szerver / nagy szerver kategória, ma már bármi lehet szerver, egy Raspberry Pi is.. meg ugye környezet függő, DEV-nek jó lehet, PROD-nak nyilváááán SOHA)
Még mindig a fejlesztéshez vissza, mert pont ebben vagyok én is mostanság: HAProxy-s pacemaker-es loadbalancer-es felállást meg minden ilyen "ökörséget" kicsiben tökéletesen el lehet játszani Virtualboxokban is egy Windows host-on, én így csináltam pár éve, igaz gamer laptop volt 4 maggal, de 1 szálat kapott minden és miután beboot-oltak a VM-ek, idle-ben ott üldögéltek kb. az idő 99%-ában, viszont konfigolgatni, demózni, próbálgatni ezt-azt nagyon hasznos volt a kis mini-lab. A 8G RAM elég sokmindenre, egy Debian "standard" installer iso pedig desktop nélkül 1 vCPU-val és 512 RAM-al elég jól tud hasítani, valami 80 MB az alap RAM igénye az első friss telepítés után, de mindjárt lepróbálom egy netinst-en.
-
Dißnäëß
nagyúr
válasz
I02S3F
#30092
üzenetére
Hát nézd, próbáltam rövidre fogni, de nem megy.
Főleg i3-i5-i7-2xxx sorozatú CPU-k, ha jól tévedek. Egyébként véleményem szerint kétesélyes. Az intel vt-x -et követő vt-d sincs még meg minden ilyen CPU-ban (de kellene a tényleges proci modelled), ami i/o eszközök paravirtualizációját teszi lehetővé.
Most ránézve az Intel procilistájára, egy ilyen generációs i3-ban nem látok vt-d-t, míg egy másik ugyanilyen generációs i5-ben igen. Valszeg vt-d hiányában kevesebb az esély élvezhető sebesség elérésére, tehát jó, ha a CPU is tudja ezt, és a BIOS/UEFI is támogatja és bekapcsolható (és be van kapcsolva), vagy nincs sehol sem benne (és gyárilag be van kapcsolva). Vt-d hiányában a teljes virtuális gép hardvert emulálnia kell a hypervisor-nak, ami rengeteg CPU időt zabál fel, vt-d mellett lényegesen kevesebbet.
Amit látok, hogy virtualizáció téren lassú a növekedés feature téren, egy stabil lineáris valami, semmi ugrásszerű. VGA kártyát és jópár speciális hardvert és képességet a host-on még mindig nem tudunk, vagy csak nagyon korlátosan úgy odaadni egy vagy több VM-nek, hogy rendesen kihasználják a hardvert. Vannak rá módszerek, de nem triviálisak, pl. a W10-emnek VGA kártyát csak úgy tudnék adni, ha alaplap, processzor, BIOS + a VM-nek odaadandó hardver (!) egyaránt kivétel nélkül támogatná az IOMMU funkciót, és ez is úgy működne élőben, hogy mondjuk egy második VGA kari lenne a gépemben, amit a host nem használ, de rá van kötve egy monitor, az első monitoron látszik a host és a desktop vagy konzol vagy akármi, amit akarok, a második monitor még kuka, majd amikor indítom a W10 VM-et, a hypervisor odaadja neki a dedikált, eddig alvó VGA karit, a W10 ezt látja immár rendes driveren keresztül (pl. nvidia, amd, mindegy) és akkor van egy W10-em, amivel egész jó natívközeli teljesítményben tudok grafika ügyileg játszani, míg vagy 5%-ot bukok CPU oldalon (ami nagyon jó arány ma már). És ez is még csak köhög, bug-ok, fagyások, de nem-desktop célokra viszont hatékonyak már a mai hardverek és virtualizációs megoldások.
A jövő szerintem amúgy ebbe az irányba mutat, hogy van egy hardver és valós időben képes lesz futni egymás mellett akár két tökmás OS is, vagy egyik a másik hypervisor-a lesz ultra minimális overhead-el, vagy ténylegesen egymás mellett (utóbbira kevesebb esélyt látok most, előbbi pedig lassan de biztosan megvalósulni látszik).
Szóval szervernek - ha nincs nagy i/o igény - befogható a laptop, grafikában viszont nem lesz egy rakéta, az az egész virtualizált élményt meg fogja ölni, lassú ablakok, vánszorognak, húzás közben széttörnek, 1-2 fps-es youtube video-k és sorolhatnám.
Szervernek "headless" üzemmódban jó lehet, csak mégiscsak egy laptop, nem arra lett kitalálva, se akksi, se hűtés, se ECC, se semmi. Szóval mégsem.
De ha mondjuk Windows-od van rajta és tegyük fel, fejlesztő vagy és kellenek virtualizált környezet(ek)ben "zárt világok" és szórakozol olyannal, hogy:
- mondjuk egy 3 node-os MySQL InnoDB HA cluster (3 VM, 1 vCPU, 1G RAM)
- backend és/vagy middleware környezet, valami kisméretű php motor, java, mittomén (2 VM, 1vCPU, 512 RAM)
- mondjuk load balancer-el előtte, pacemaker-el, tűzfalak, akármi (legyen 1 VM, 1vCPU, 512 RAM)
.. ez így nagyot hasalva 6 vCPU, 4-5G RAM... el lehet szórakozni..Sebességben szerény leszel, DEV rendszernek meg UAT-nak jó lehet akár amúgy, ha van sok RAM-od és óvatosan adagolod a vCPU magokat, PET-nek már nyilván nem, ahhoz fel kell tolni felhős gépekre a lefejlesztett full stack-et, bekonfigolni rendesen és úgy meghajtani, mielőtt PROD-ra mész vele.
De kicsiben "bohóckodni" és igazából a lényeget, funkcionalitást, script-eket, proxy-kat satöbbiket lefejleszteni, beállítani, bekonfigolni, kipróbálgatni a viselkedésüket, egymás közötti kapcsolatokat, stb stb stb, arra tök megfelelő lehet.
Mondjuk főleg 4 fizikai magos kellene itt is ami a Te szériádban ritka, inkább 2 mag lesz az, jó esetben 4 szál, szóval mondom, nem kell rakétát várni, de azért lehet értelmes dologra használni.
Ez csak 1 példa volt, fogalmam sincs, miért virtualizálnál egy ilyen laptopon, de fentebbiek szó nélkül. Minimál Linux grafikus felület nélkül (vagy ha nagyon muszáj, akkor egy LXDE/XFCE, de minek) és indulhat a móka.
A Windows host-nak hagysz a 8-ból 3-4 Gigát (lehetsz először szigorú, hogy csak 3-at, a többit kiosztod VM-eknek) és igazából jó lehet a dolog.Webfejlesztéshez meg full stack motyókra én így csinálnám (vagy még a konténerek ugye, 1 VM-be akár több konténer is, már ami konténerizálható..) .. és lenne valami távoli storage-om mindegyik virtualizációs környezetbe belinkelve, ahova néha felszinkronizálom az adatokat, fájlokat, akármit, amolyan biztonsági mentésként, ha máról holnapra megdöglene a laptop, vagy megsemmisülne, ellopnák, akármi.. legyen ez akár egy buta rsync, akár egy sftp cron-al a háttérben rendszeresen meghívva, akár eleve egy elosztott fájlrendszer, bááármi....
Magánvélmény, uff. Tökéletes megoldás nincs, de ki lehet próbálgatni a nagy alkotómunka előtt, meddig feszítheted a vászont
-
Dißnäëß
nagyúr
válasz
Frawly
#30043
üzenetére
Nnnna, közben sikereket értem el: van egy olajozottan viselkedő W10 guest-em.
Vééégre.
Virtio full driver pack-et feltettem, a storage-ot már telepítéskor (2 CDROM-ot kapott, egyik a Windows telepítő volt, másik pedig a virtio drivereket tartalmazó iso).. network-öt utólag, QLX grafika utólag, minden egyéb utólag. Van egy exe az iso-ban, ami felpakol kvázi mindent.Fedora munka, van stable és latest, én bepróbáltam a W10 guest-en a "latest"-nek az iso-ját és gyönyörűen műx
Pattog a W10 VM-ben is mint állat, tudtam is egy jót fullscreen-ben használva (mint natívban) Photoshop-ozni egy jót. Gondoltam, leírom. Aki esetleg hasonlókkal küzd, vagy hasonlóan perverz, hogy otthon is desktop gépen Linuxozik és VM-ben futtat egy W10-et, annak melegen ajánlom: [link] , a lap 3/4-ede körül lent, Stable és Latest "virtio-win iso" fájlok egyike lesz az.
A drivereket ha kézzel tolja fel az ember, a rendszer nem találja meg, tehát rá kell erőszakolni, viszont úgy nem fog hibát dobni, hanem megeszi szépen.
A "Balloon" driver feltétele után nem kell megijedni, ha az üres, nyugalmi állapotú W10 rendszer ~95%-ig foglaltnak-használtnak jelzi a memóriát, az normális innentől. (Elég morbidul néz ki, de direkt lesz ilyen).
-
Dißnäëß
nagyúr
válasz
f_sanyee
#30088
üzenetére
A kép csak egy mém, de igaz.
Nem konzisztens viselkedésre utal nekem egyébként, illetve gyanakodom valamire:- mióta úgy lövöm le a rendszert, hogy mindent becsukok szépen kézzel, vagy akár nyitva is hagyok és XFCE jobbfent nem "Shut Down" menüpontra megyek azonnal, hanem "Log Out" és a felbukkanó választóablakban megyek a "Shut Down"-ra ("Save session for future logins" beikszelve), 100% mindig gyönyörűen leáll.
- ha direktben a Shut Down menüpontot választom egyből, csak egy 30mp-es visszaszámláló ablak jön fel, melyre ha nem kattintok, lelövi a gépet, ha kattintok, hogy cancel, nem lövi le.
Emlékeim szerint ennél az utóbbi módszernél produkál olyat, hogy egy kétperces várakozást dob nekem a mémen látható módon, én meg malmozok, hogy na most ki az úr a gép felett, én, vagy ő, vagy mi a fene történik. Ha azt mondtam shutdown, akkor flush caches és állj le Te idióta gép, az sem érdekel, ha a be nem zárt user space app elreccsen - ezt várnám.
Egyébként nem zavar, csak láttam ezt a mémet és bedobtam a kérdést. Első módszerrel lövöm le egy ideje már, totál graceful módon, azóta nem jött még elő a visszaszámlálósdi.
Állítólag - amit olvastam erről - ez attól lehet, hogy a systemd mind a boot, mind a shutdown folyamatot párhuzamosítja, így előfordulhat, hogy nem feltétlen egymásutáni sorrendben állnak fel, vagy állnak le az egyes service-ek és az erre érzékeny még futó dolgoknál az történik, hogy kiszalad a lábuk alól a talaj, míg ők még nem álltak le teljesen, és ilyenkor megakasztják a teljes shutdown sequence-t egy várakoztatással. De többet nem tudok erről, nem mélyedtem bele.
-
Dißnäëß
nagyúr
válasz
Dißnäëß
#30083
üzenetére
Nabasszus, lekezeli korrektül a lehúzást. (Előbb power kábel, aztán SATA). Elnézést, hogy túráztatlak Titeket.
Várnom kellett vagy ~10mp-et kb, mire eltűnt lsblk listából... de eltűnt, ahogy illik.
Szerk.: és a rádugott új is gyönyörűen feljött.
Annyit még láttam, hogy van, aki elővigyázattosági okból hdparm -Y -al bealtatja a diszket, ekkor fejeket parkolóba húzza már eleve + lepörög. Így szedi le a kábelről. (Nekem desktop házam van, nem fiókom)..
Hát akkor ... nincs teendő. Jó étvágyat mindenkinek
-
Dißnäëß
nagyúr
Sziasztok,
bekapcsoltam BIOS-ban a Hot Plug-ot az egyik SATA portomra, amin az elkövetkező napokban cserélgetnék 1-2 HDD-t (leürítés, dd nullázás, stb). Nem akarok reboot-olgatni.
Ezt kényelmes elérnem, a gép felém eső hátoldala alatt, így amúgysem kell az egész gépházat feltúrnom.
Az eddig oké, hogy hot-plug, de hogy mondom meg a rendszernek, hogy "na én ezt most lehúzom" ? (Umount-hegyek, stb.. minden megtörtént, már ki is van nullázva).
Illetve a következő HDD-t ha rádugom a kábelekre, hogyan fogom felismertetni a rendszerrel az új jövevényt ?
Böngészve a netet erre sokfélét látok, így végül nagy tanácstalanságomban tettem egy próbát és lehúztam csak úgy a SATA kábelt a vinyóról, semmi nem történt.
Messages-ben látszik ennyi:
Apr 22 11:35:02 DESKTOP kernel: [ 9027.436548] ata5: SATA link down (SStatus 0 SControl 300)
Apr 22 11:35:02 DESKTOP kernel: [ 9027.436555] ata5.00: disabled
Apr 22 11:35:02 DESKTOP kernel: [ 9027.436572] ata5.00: detaching (SCSI 4:0:0:0)Lsblk továbbra is listázta.
Ezután visszadugtam rá, szintén semmi, full kuss. Messages-ben is megjön:
Apr 22 11:35:03 DESKTOP kernel: [ 9029.270228] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Apr 22 11:35:03 DESKTOP kernel: [ 9029.271487] ata5.00: ATA-8: WDC WD6401AALS-00L3B2, 01.03B01, max UDMA/133
Apr 22 11:35:03 DESKTOP kernel: [ 9029.271490] ata5.00: 1250263728 sectors, multi 16: LBA48 NCQ (depth 32), AA
Apr 22 11:35:03 DESKTOP kernel: [ 9029.272495] ata5.00: configured for UDMA/133
Apr 22 11:35:03 DESKTOP kernel: [ 9029.272620] scsi 4:0:0:0: Direct-Access ATA WDC WD6401AALS-0 3B01 PQ: 0 ANSI: 5
Apr 22 11:35:03 DESKTOP kernel: [ 9029.272938] sd 4:0:0:0: [sdf] 1250263728 512-byte logical blocks: (640 GB/596 GiB)
Apr 22 11:35:03 DESKTOP kernel: [ 9029.272951] sd 4:0:0:0: [sdf] Write Protect is off
Apr 22 11:35:03 DESKTOP kernel: [ 9029.272966] sd 4:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Apr 22 11:35:03 DESKTOP kernel: [ 9029.272998] sd 4:0:0:0: Attached scsi generic sg5 type 0Szerintem azért tudatni kellene vele normál esetben, ha valamit csinálok, főleg mikor lehúzom - szerintem - és annak látszania a rendszerben utána, nem annyi, hogy lehúzom és helószia. (A visszadugása pedig lehetne szvsz automata felismerős, de lehet azt is kézzel kell).
Van egy LSI-m is a gépben, de ez konkrétan alaplapi port most. Windows alatt kipróbáltan kitt-katt és működik szépen a hot-plug.
Szórakozott már vki ilyennel ?
-
Dißnäëß
nagyúr
Én ezt értem, de egy mini ITX konfigot nem kell nulláról tanulnom, pont tanulok elég újat mostanában, a Linux meg ugye tud elég sokmindent. Meg szerintem ne kategorizáljunk, azért jól tud esni, mikor megkérdeznek, miért wifin keresztül DD-zem a gyerek gépét, mikor backup-olom, az marha lassú lesz, és a válaszom, hogy 800Mbit körül hasítok egy fallal arrébbról egy lassan 4 éves router-rel, meg konkrétan az 1000-es Digimet kimaxolja, úgyis mögötte futtatok mindent, nem rajta.
Szóval vicc vagy nem, nekem bőven tökjó
Nem érdekel a Mikrotik, akinek van olyan irányú affinitása, használja, egészségére, nála sokkal fontosabb dolgokat prio-ztam előre az életemben.De ez már itt nagyon off, hogy engem mi érdekel
A passzívra: nem építettél még. Pláne nem Akasa Euler-ekkel.
-
Dißnäëß
nagyúr
válasz
inf3rno
#30066
üzenetére
Igazából aki "komolykodni" szeretne, annak csak arra jó bármiféle Media Markt-os konzumer csicsarouter, hogy gigabit portok, meg modern wifi képességek, mert 3 kattból van nete. Komolyabb célokra dedikált gép kell, szokták emlegetni a Mikrotikot is, nekem spec. nincs kedvem megtanulni, szoptam már annyit Linuxon pppoe-vel, hogy mára már ne jelentsen gondot Linuxból fasza router-tűzfal-vpn-koncentrátort építeni, meg ilyen mindenes házi vagy irodai szervert. Nálam is kényelemből van az ASUS a hálón, szemezek is már egy kis passzív mini ITX motyóval, hogy végre megszabaduljak tőle mint router-től (és akkor marad a wifi része butában). Csak mindig van az embernek valami sokkal fontosabb projektje is
-
Dißnäëß
nagyúr
válasz
inf3rno
#30064
üzenetére
Hát OpenWRT-t nem ismerem, DD-WRT-ztem régen egy Linksys WRT54GL-el, most meg egy korszerűbb ASUS-ra tettem fel a "Padavan" féle firmware-t, mert a gyári kicsit bugos itt-ott, ez meg enged parancsokat szkriptből lefuttatni magán, akár többet is, szóval jó.
Szerintem bármilyen Linux alapú motyón megy a dolog.
Nem kell amúgy egy nagy darab tartományra beállítanod a port fw-ot. Elég csak azokra a konkrét portokra, amiken kopogást vársz
és amíg nem a megfelelő sorrendben történik ez meg, onnan is leesik mindenki, tehát a külvilág felől az látszik, hogy nincs reakció. Én nem adnék meg egész tartományokat port fw-nak.
-
-
Dißnäëß
nagyúr
válasz
Fecogame
#30053
üzenetére
Jó cucc, én az ellenkezôjében (is) hiszek, amikor alapból úgyis zárva az SSH (példánál maradva) és port knocking-al, kopogtatva lehet kinyittatni azt ideiglenesen a host-al, az adott beérkezônek.
Ezt portscan-elgetheti jobbrabalra bármilyen módszerrel bármeddig, nem fog látni semmit, míg nem a megfelelô módon kopog be az ajtón, ami nem más, mint egy pár adott portra valamiféle szekvenciának megfelelôen be próbál jönni (errôl egy nmap gondoskodik, magáról a bekopogásról). Ha az általunk definiált sorrendben kopog be a megfelelô portokon valaki, akkor az ip-jére kinyitódik esetünkben az SSH portja X másodpercre, a kapcsolat felépítéshez.
De amúgy paranoidok sosem lehetünk eléggé, szóval a kettôt kombinálni is lehet.
[link] Az alapokat elmeséli. Jópofa megoldás.
Én az OpenVPN portom védtem így egy ideig, üresek is voltak a logok
, most az ASUS routerembe (linux alap) van lehetôségem lehelyezni egy scriptet, amit lefuttat minden boot-kor, így nem felejti el a dolgokat, ezt lehet megcsinálom megint, és akkor egy gyengébb titkosítást is használhatunk a VPN-re cimbimmel, mert nekem 1000-es net, neki 500-as, de nem bírja a két router, a titkosítás megeszi a procikat (Vagy lehet befogok egy RPi4-et VPN terminálásra).. -
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).
-
Dißnäëß
nagyúr
válasz
Frawly
#30043
üzenetére
Igen, ezeket ismerem, de nincs két VGA-m, viszont hogy ENNYIRE betetűsödjön a guest VM grafika, nem gondoltam volna. Nem szerver volt a cél ezzel, de egyelőre le is tettem róla, hogy VM-ben "grafikázok".
Azaz az IOMMU lesz ez, csak előtte még vennem kell egy nagylevegőt
(Meg egy 2. VGA-t a GF GT710 mellé). Ezt a fícsört az alaplapnak is tudnia kell (tudja), a CPU-nak is (tudja), és a VM-nek exkluzívban odaadott hardvernek is tudnia kell (nemtudja). Szóval nagylevegő, de legalább már irányba álltunk. -
Dißnäëß
nagyúr
No. Még emlékeztek rá valszeg, hogy lassúnak találtam a QEMU/KVM VM-jeimet, akárhány procit osztok nekik, akármit is csinálok.
Nos, ez igencsak a VGA (azaz emulált VGA) tetűsége lehet, mármint inkább szubjektív feeling részemről és úgy néz ki, alaptalan volt.
Sysbench-eltem a CPU-t 1 szálon és 4 szálon is, memóriát szintén.
Előbb a host-on párszor, aztán az egyik Linux (ráadásul KDE-s) VM-emen, aminek 4 mag volt odaadva.Az eredmény memóriánál közel 0% eltérés, procinál meg ilyen összehasonlíthatatlanul kicsi szintén (a host javára). Szóval én úgy gondolom, a virtualizáció és a képességek használata CPU és RAM oldalon rendben van, diszk is gyors a VM-ben is, bár swap-et nem is használ, szóval ... valszeg megoldódott a "bajom" és csak én gondolom úgy, hogy tetű, mert amúgy teszi a dolgát mindenben, de a gyorsítás nélküli VGA egy desktop esetében nyilván odatesz az élménynek, mennyire "pattogós, folyékony" az egész.
Érdekes.
-
Dißnäëß
nagyúr
válasz
I02S3F
#30012
üzenetére
4 éves korom óta függöm, de így sem érdemes már mindent megtanulni belőle, akkorára nőtt a torta azóta..
Én azt mondom, hogy aki most kezdi kicsit mélyebben, az kicsit kapargasson meg minden témát, minden aspektusból. Nem kell belemenni nagyon, csak kicsit-közepesen. Idővel meglesz az, ami fekszik az embernek és amiben szeret majd elmélyedni. Legyen az frontend fejlesztés, IT architektúra tervezés, adatbázis specializáció, storage, clustering, elosztott rendszerek, valami tudományos computing dolog, esetleg játék fejlesztés, grafika/3D/VR, robotika, mikrokontrollerek (Arduino & Co), .. nagy a paletta és egyik sem hal ma éhen.
Sok sikert, találd meg amit élvezel benne és abban merülj nyakig
-
Dißnäëß
nagyúr
válasz
I02S3F
#30010
üzenetére
4x fejlesztést gyakorló környezet (DEV, TEST, UAT, PROD), 3x MySQL InnoDB HA cluster (+ 1x kontroll gép, ahonnan elérem), 2x W10, 1x PiHole (ismerkedek vele), 1x OPNSense (ismerkedek vele), 1x tetszőleges LiveLinux VM amikor le akarok gyorsan tesztelni valami "új" Linux-ot csak poénból - hirtelen ennyi, de nem mind egyszerre megy természetesen. Annyi szemem, agyam nincs
Nem is ők eszik meg a RAM-ot igazán, persze ha kényelmesen osztok nekik 4-8G-ket, W10-nek 8-at, azért szemmel látható a fogyás, de szerintem még a 16G is elég lenne, csak utolsó pillanatban vettem még 16-ot mellé, hogy meglegyen a dual channel legalább, mert az első 16G-m 1 modulon van. Ha pedig már ennyi RAM-om lett, ramdrive-ban szórakoztam egy ideig és valszeg fogok még, meg igazából tök kényelmes 32G-n létezni ma szerintem. Photoshop-ot is visszaizzítom, ilyesmik, meg lehet elkezdek zenélni (zenét írni), amire kipróbálnék egy Ubuntu Studio-t. Meg erősítőt, hangfalat építek, elektronikát tervezek, ezeket is már mindet Linux Desktop-on, KiCAD és társai, ... elvagyok
Próbálom a host-ot kímélni és nem "teleszemetelni", szóval nálam - lehet kicsit pazarló, de annyira nem gáz - a legtöbb pittyputty tevékenységre van egy külön VM. Azért választottam ezt, mert például csak elektronika és hifi témában van vagy 10-20 böngészőablakom nyitva és szeretem őket látni egyben, ha meg még a fotós és devops és egyéb dolgokat is mellévesszük, mellényitnám, lenne vagy 50-60 ablakom nyitva 1 böngészőben, az meg átláthatatlan számomra. Úgy gondoltam, Linux Desktop-okkal témákra "szeletelem" az életem és mikor melyik gépbe megyek így be kényelmesen, a host-on meg van egy XFCE mint felület, egy KeePass a jelszavaimnak, egy Foobar2000 a zenének (ez mégiscsak jó, ha natív hangkártyát lát, bár VM alatt is szuper) - és ennyi. Néha 2-3 is be van izzítva, mert mondjuk egy DIY külföldi fórumon megy a fórumban a párbeszéd ilyen párperces kérdezz-felelek tempóban, míg közben csinálok más témában mást, egy másik VM-ben.Szóval mikor mi jön rám. A ramdrive meg tőlem függ, mennyire nyomom tele és mivel, szóval oda elég 1G is, meg nemelég 512G se
de ez általában le van lőve, teszt célból nyomtam meg kicsit, érdekes volt kísérletezgetnem vele, mikor mennyire pakolom tele és a rendszer hogy reagálgat rá, melyik RAM típusból fogy.. Jó így empirikusan tapasztalni, vagyis én szeretem.Hát ... kb ...
Az említett konkrétan "agyonterhelem a host"-ot dolog csak példa volt arra, hogy elmentem már vele eddig is és tök jó élvezhető maradt a rendszer. Azért nem ez a jellemző
De ha valaki megkérdezné tőlem, mennyi RAM-ot tartsak fenn a host-nak ma, ilyen átlagosabb vegyesbazár dolgokra, azt mondanám, 2-3-4G, attól függ, mennyi mindennel tömi meg a host-ot. A többi mehet VM-eknek. A 4G host-ra az olyan tök ideális szvsz, míg nincs sok terányi ZFS, bekapcsolt deduplikációval (de azt meg hülyeség lenne akkor másra használni, mint storage, szóval az egy dedikált NAS gép lenne, nem egy mindenes workstation). -
Dißnäëß
nagyúr
Ha engem kérdezel, egy általános felhasználású host-nak szerintem a 4G is sok, de legyen 4G
Persze mindig jó elgondolkodni azon, milyen fizikai host-on mi fog majd futni.
Nálam workstation módban van használva a gép, ezen élek, dolgozok, amolyan "home lab" jellegű valami, NAS is, szóval minden. Simán televágom úgy a RAM-ot VM-ekkel vagy éppen ramdrive-os (tmpfs) szórakozásokkal, hogy 1.5G-2G marad a host-nak (és 1.8-at foglal most 21 nyitott böngésző füllel), tehát összesen olyan 4 körül marad host-nak mindenre, és a többi 28G oda van adva akárminek, pedig még 24 tera ZFS-em is van.
Fontosabbnak tartom a swappiness értékét kicsit átállítani, ha indokolt lehet, vagy legalábbis tenni vele néhány próbát éles üzem előtt.
-
Dißnäëß
nagyúr
válasz
Jester01
#29997
üzenetére
Megvan. Teljesen hatástalan.
desktop:~$ xinput --list-props 11
Device 'Telink Trust Wireless Mouse':
Device Enabled (155): 1
Coordinate Transformation Matrix (157): 0.100000, 0.000000, 0.000000, 0.000000, 0.100000, 0.000000, 0.000000, 0.000000, 0.100000
libinput Natural Scrolling Enabled (292): 0
libinput Natural Scrolling Enabled Default (293): 0
libinput Scroll Methods Available (294): 0, 0, 1
libinput Scroll Method Enabled (295): 0, 0, 0
libinput Scroll Method Enabled Default (296): 0, 0, 0
libinput Button Scrolling Button (297): 2
libinput Button Scrolling Button Default (298): 2
libinput Middle Emulation Enabled (299): 0
libinput Middle Emulation Enabled Default (300): 0
libinput Accel Speed (301): 0.000000
libinput Accel Speed Default (302): 0.000000
libinput Accel Profiles Available (303): 1, 1
libinput Accel Profile Enabled (304): 1, 0
libinput Accel Profile Enabled Default (305): 1, 0
libinput Left Handed Enabled (306): 0
libinput Left Handed Enabled Default (307): 0
libinput Send Events Modes Available (277): 1, 0
libinput Send Events Mode Enabled (278): 0, 0
libinput Send Events Mode Enabled Default (279): 0, 0
Device Node (280): "/dev/input/event2"
Device Product ID (281): 5215, 466
libinput Drag Lock Buttons (308): <no items>
libinput Horizontal Scroll Enabled (309): 1Még a 2-es és 4-esen van virtual pointer a 11-en kívül, ugyanúgy 157-es Coordinate Transformation Matrix-al, átállítom, nincs változás.Fura, hogy mióta élek, ez küzdelmes minden Linux alatt. Nem szeretem az érzékeny egeret
Made my day.
Régi szép idők.. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- PH!otósok beszélgetős, offolós topikja
- Nintendo Switch 2
- eBay
- SD-kártyát vennél? Ezért ne csak a GB-ot nézd! – Tech Percek #9
- Azonnali alaplapos kérdések órája
- Milyen légkondit a lakásba?
- Azonnali notebookos kérdések órája
- Bambu Lab 3D nyomtatók
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- PlayStation 5
- További aktív témák...
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Vírusirtó, Antivirus, VPN kulcsok
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Telefon felvásárlás!! Samsung Galaxy A22/Samsung Galaxy A23/Samsung Galaxy A25/Samsung Galaxy A05s
- Bomba ár! Lenovo X1 Yoga 2nd - i7-7G I 8GB I 256SSD I 14" WQHD Sérült I W11 I CAM I Garancia!
- BESZÁMÍTÁS! ASRock B550M R5 5600 16GB DDR4 512GB SSD RX 6600 XT 8GB Kolink Observatory LM RGB 600W
- DELL PowerEdge R730xd 16LFF+2SFF rack szerver - 2xE5-2680v3,64GB RAM,4x1GbE,H730 RAID v ZFS
- Bomba ár! Dell Latitude 3590 - i5-8GEN I 8GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Garancia!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest