-
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
-
Dißnäëß
nagyúr
Banális kérdés: hogyan lehet bármilyen disztró, bármilyen window manager alatt az egérmutatót még jobban belassítani ?
Egyszerűen csutkanullára húzva is még mindig túl sokat megy az egerem a képernyőn. Előző is, ez is, céges is. Működik a csúszka, de nincs értelme, ha ultraminimumon is elég jól halad a képernyőn a mutató, kis mozdításra is, ha meg elkezdem növelni, úh, pláne
Tehát működik a dolog, csak rohadtul kéne bele egy mocsok nagy offset ...
-
Dißnäëß
nagyúr
Van egy W10-em, annyit érdemes megtenni, hogy amit csak lehet, virtio-ra állítson az ember, illetve van húú talán a Qemu oldalán egy W10 alá való virtio-s
SATAdriver, talán ez... ? Ide hoz Gugli engem.. [link] Elvileg a telepítőnek az ezen lévő motyót kell megadni drivernek és akkor látja a VirtIO diszkeket, bár ez lehet csak korábban volt így, nálam virtio diszket is látott a relatív friss W10 telepítő. (Legalábbis nem vacakoltam ilyennel és felkúszott rá szépen). RAM 8G, 4-el swap-re hajlamos. Azaz pontosabban fogalmazok: a Windows mindig swap-el kicsit, csak 4-nél lényegesen többet, én régóta virtuális memória nélkül használom őt is, Linuxot is, mindent és mindenkit, bevált. -
Dißnäëß
nagyúr
válasz
bambano #29983 üzenetére
Szemeztem én is már ezzel szerelt lappal, de egyelőre okafogyottá vált, még mindig csak 1 gépen ülök. [link] Pár tavalyi és tavalyelőtti komment lentebb, linux érintettségű, akkor még azon kattogtak, hogy melyik disztróba kerül be támogatás és az milyen, illetve állítgatják páran, hogy jó a támogatása. Azóta ez csak javulhatott tovább, szerintem mint hardver, nemigen lehet gond vele, persze nem enterprise grade cucc, de otthon akár a külön szerelt kártyát, akár az alaplapra tett verziót akarjuk, simán behúznám ilyen itthoni célra, hogy akár egy drágább switch-el, akár direktben, összekössem az asztali fotó és video feldolgozó PC-m a pincében lévő NAS-al (ha nincs switch, direktben a két gépet, a többiek meg mehetnek a klasszik 1Gbit és wifi vonalon).
(Most hoztam is választ a kérdésedre, meg nem is, de inkább a megbízható ágra tippelnék, mint a vacakra).
-
Dißnäëß
nagyúr
válasz
sh4d0w #29978 üzenetére
Host:
- jól szellőző porszűrős ház (Thermaltake Core v31)
- ASUS TUF B450M PRO GAMING
- Ryzen 5 3600 alapon (néha fellöki magát, ez normális, a frekiket érintő beállítások auto-n BIOS-ban, szóval semmi tuning). Jó pasztázás, böhöm hőcsöves hűtő, kizárt a CPU throttling, hűvös az egész max kakaón is. Prime stabil bármeddig.
- 2x 16G DDR4 ECC 2400@3000 (Samsung B-Die, alapfeszen hagyva, ECC ON, teljesen hibamentes OFF-ban is, de természetesen ON-on használom, totál hibamentes edac-util szerint is)
- DELL PERC H310 (LSI 9211-8i kétportos SAS kontroller, legkésőbbi hozzávaló IT módú firmware-el és bios-al crossflash-elve, hibátlan)
- 1x 250G Intel SSD (82% de csak a kopás miatt, PERFECT státusz HD Sentinel szerint)
- 2x4T Seagate NAS + WD PURPLE, zfs mirror (egyik HDD alaplapi SATA-n, másik a PCIe-es LSI-n)
- 4x4T Seagate NAS, raidz1 (2 HDD alaplapi SATA-n, 2 HDD az említett LSI-n, bár raid5-szerű módban ennek semmi értelme, mert csak 1 kiesést bír, mégis ezt választottam a hely miatt, ha meg hullik, nem dőlök kardomba, a fontos a mirroron van. Kellett a hely.)
- GF710 VGA, két monitorral
- Debian friss testing, frissen update-elve. Hibamentes, évek óta testing-en élek, nem szokott bajom lenni vele (akkor álltam át stable-ről testing-re, mikor egy korábbi hardveremre a stable-t nem tudtam rávenni, illetve mikor megtudtam, hogy az Ubuntu alapja is testing branch)
- XFCEHost is és a VM-ek is SSD-n, VM-ek storage konténere QEMU (nem RAW bár egyesek szerint a RAW még jobb, de így is a VM-en belül dd-vel 400+ megát mérek).
Szóval érthetetlen. Mégegyszer benézek BIOS-ba, minden támogatva-e a CPU virt. opciók környékén, de kifejezetten emlékszem, hogy úgy hagytam. (Jó lenne, ha most mégis tévednék). Volt már sokkal gyengébb konfigon is pattogós VM-em, a VGA-tól eltekintve.
-
Dißnäëß
nagyúr
válasz
sh4d0w #29976 üzenetére
Én is ezt várnám, de .. kissé lassan tölt be a Debian-KDE, ahhoz képest, amit host-on tudna. (Bár ott XFCE fut, nem összehasonlítási alap, de volt KDE-m is korábban, nem sokáig ugyan, de sokkal pattogósabb, mint a VM tesó).
Lomha menük, egy Konsole megnyitása is kattintás után 1-1.5 mp, Chrome , Firefox indítása 10+ mp (!!) - közben se a diszkek nincsenek terhelve, se a CPU, se semmi. Úgy kellemesen elvan a gép, mintha üdülne, kiment volna a napra kicsit sétálni, fagyizni, holott vCPU-nak eléggé tekernie kellene (mint minden normális esetben) akár csak pár pillanatra is, a host CPU-nak meg minimum feléig, ha nem tovább (6mag12szál, vCPU 4 magot kapott, ami a host-on vagy 4 fizikai magra fordítódik le, vagy kevesebb fizikaira és a maradék az HT-ból megy a VM-nek, hiszen host-on ezek csak processzek igazából - lehet ütemezőt érintő kérdés, mennyire pattog egy VM ?).
Na, de pont fentebb nevezett HT miatt lehet, hogy ki kéne kapcsolnom host-on a HT-t és akkor más lenne a szitu, mert amit odaad a Hypervisor a VM-nek, az fizikai mag is lesz így egyúttal, legalábbis nem egy prociban-"virtualizált" HT szál. Ugyanakkor azt is tudom, hogy a Linux kernel elég okosan osztja be az erőforrásokat, milyen processznek miből mit ad, de nem jöttem még olyanra rá például, hogy CPU pinning, azaz hogy a pékbe paraméterezem be a KVM host-ot, hogy a 4 vCPU-t dedikáltan rendelje hozzá 4 host-béli maghoz (legyen az akár virtuális mag, tehát HT szál, akár HT nélküli tényleges mag) és ezt hogyan építem be a GUI Launcher-be.
Nem tudom. Lehet video-ra kéne vennem amúgy. Sőt, meg is teszem délután, munka után.
#29975 sonar: köszi a hsz-t. Ezek szerint normális, ha lejön "néhány" CPU feature flag.
Intelen Neked nemigen fog mutatni AMD-s virt CPU opciókat, nálam a választható CPU modellek között van az EPYC és pár egyéb AMD-s is. "host" = "Copy host CPU configuration", ezt csak én rövidítettem le "host"-ra, mert mire kiírom többször is, hogy "Copy host CPU configuration", megszülökSzóval a host így értendő e kontextusban, hogy a host-on kiválasztom a menüben a "Copy host CPU configuration"-t (na, mégsem úsztam meg, amit akartam)
Tudom haladó Linux topic-ban vagyunk, de nincs esetleg kéznél azon a host-odon egy Windows ? (Ami támogatja a CPU-dat fullba). Nézz hülyének nyugodtan, de akár egy aktiválatlan, külső USB-s SSD-re leszedett Windows Server 2019, amolyan trial-ba feltéve is lefuttatja szépen.
Amiért kérdezem: a Pass Mark CPU listában nincs benne a Te CPU-d, semmilyen mérésük, adatuk nincs róla. Senki nem küldött be még CPU-ra vonatkozó sebességteszt eredményt az ő sebességtesztelő tool-jukból, magyarul 0 minta. Ha megtennél 1-2 mérést és beküldenéd az eredményt hozzájuk, igencsak megjelenne a listában mint 1 minta, a Te procid (elég különleges darab). Poén lenne látni
+ hátha másnak is hasznára válik a közösségben. Persze nem kötelező, csak bedobtam, megértem, ha nem szórakozol ilyenekkel, mert ... (n+1 ok).
Lista: [link]
Progi: [link] (Server 2012-2016-2019-en is fut) -
Dißnäëß
nagyúr
válasz
Dißnäëß #29973 üzenetére
VM-en a legjobb eredmény (host-on "host" vagy EPYC CPU emuláció, mindegy) :
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core ssbd ibpb stibp vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero wbnoinvd arat umip arch_capabilitieshost:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca -
Dißnäëß
nagyúr
Sziasztok, kicsit lassúnak találtam a KVM-et, így eredetileg a kezdő topic-ban feltett kérdéseimmel udvariasan inkább ide küldtek, hátha.
Szóval: Ryzen 5 3600 (6 mag, 12 szál), 2x16G DDR4 ECC, Debian testing, raklap HDD ZFS-el és SSD, utóbbiról a rendszer és a VM-ek rendszermeghajtói. GeForce GT710.
A konfignak nem kellene, hogy gondja legyen bármivel is.. egy elég középerősnek számító workstation gépnek mondanám, ezen csinálok mindent kvázi.
Miután mindent átállítottam virtio-ra, ami csak létezik, SSD-nél cache off-ra + native kezelés (Virtual Machine Manager-ben, XFCE alatt), .. bár a diszk sebességgel sosem volt gondom, lemértem dd-vel és most sincs, 400+ Mb/sec, az jó, tehát nem a diszk fogja a VM-et (egyetlen VM futása se valami pattogós).
A létező összes vt-x és vt-d Inteles fícsör AMD megfelelője bekapcsolva, IOMMU, minden pittyputty ON-ra BIOS-ban, ami számíthat bármit is virtualizáció téren.
Gondoltam, akkor nézzük meg a vCPU fícsöröket, mit sikerül a hypervisor-nak átadnia a fizikai CPU képességekből a VM-nek:
Az összes CPU-emuláció féleséget végigkattintgatva + hard reboot, ez látszott rendre a VM-en belül:
1. grep flags /proc/cpuinfo | uniq > cpuinfo_...... .txt
2. ls -hn cpuinfo*
-rw-r--r-- 1 1000 1000 581 Apr 7 14:36 cpuinfo_copyhost.txt
-rw-r--r-- 1 1000 1000 581 Apr 7 13:58 cpuinfo_EPYC.txt
-rw-r--r-- 1 1000 1000 237 Apr 7 14:32 cpuinfo_kvm64.txt
-rw-r--r-- 1 1000 1000 281 Apr 7 14:23 cpuinfo_OpteronG3.txt
-rw-r--r-- 1 1000 1000 220 Apr 7 14:27 cpuinfo_qemu64.txtSzóval a méreteken látszik, mikor mennyi CPU flag-et tesz be a txt fájlokba a guest VM.
Ehhez képest amit a host mutat a fentebbi parancsra, egy 897 byte-os fájl, tehát a /proc/cpuinfo még a legjobb, host CPU jellemzőket másoló üzemmódban sem mutat annyi CPU flag-et guest-ben, mint amit a host tud. (Lehet nem is kell mindet, mert azok már nem érintenék a virtualizációt érdemben, de ebben nem vagyok biztos, tekintettel arra, hogy a különbség azért elég nagy).
Szóval a host-on raklap flag van, míg a KVM/QUEMU által a legjobb esetben is csak ezek sacc kétharmada van megmutatva VM-nek. Ez normális ? (Esetleg van kedvetek megnézni, Nálatok hogy néz ki?) -
Dißnäëß
nagyúr
Csönd van.
Megjött a posta némi ECC RAM-mal
Kis Memtest, finomhangolás ECC OFF módban, majd így ECC ON, Debian boot és elindult a zfs resilvering.
Sikeresen hozzáadtam a 2. diszket az első, önálló, adattal majdnem teli mellé és most mirror-ba kerülnek. Woo-hoo. Életemben nem csináltam még ilyet, csak teszten eddig (VM-ben).
Remegő térdek, eddig minden klassz
root@DESKTOP:~# zpool status -v
pool: zfsmirror1
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Wed Feb 26 19:52:30 2020
907G scanned at 668M/s, 146G issued at 107M/s, 3.32T total
146G resilvered, 4.28% done, 0 days 08:38:26 to go
config:
NAME STATE READ WRITE CKSUM
zfsmirror1 ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-ST4000VN000-1H4168_Z503T7M2 ONLINE 0 0 0
ata-WDC_WD40PURX-64GVNY0_WD-WCE6E3MS78Z9 ONLINE 0 0 0 (resilvering)
errors: No known data errors -
Dißnäëß
nagyúr
válasz
samujózsi #29774 üzenetére
Természetesen
de egyből overwrite kérdés, majd másol és a végén a hiba, hogy nincs joga (még szerencse, root-ként képes lenne felülvágni)..
1 fájllal.
Ha viszont 2+ fájllal csinálom ezt, vagy fájlok-könyvtárak vegyesen, devnull már nem is adható meg, mert eleve ugat, hogy könyvtárat kér
-
Dißnäëß
nagyúr
Kicsit más: van itt olyan elvetemült, aki szereti az MC-t néha elővenni ?
Arra lennék kíváncsi, hogyan tudok vele /dev/null-ba másolni (magyarul fájl másolás valós sebességet mérni). Ezt régen mintha tudta volna, vagy lehet keverem a Far Manager (?) "nul" target-jével ?
Parancssorból oké, most csak így MC-re specifikusan kérdem.
-
Dißnäëß
nagyúr
válasz
samujózsi #29749 üzenetére
Nem mondom, hogy nincs igazad, de én úgy tudom, 1 drive mellett nincs zfs integritás-kezelés még. Nemrég rágtam át magam n+1 doksin és leíráson, szerintem kell hozzá a kettő. De megoldható 1 drive-on valahogy, valami nyakatekert trükkel, lehet. Csak úgy out-of-the box nem.
Zfs-en már az is előny, hogy az ellenőrző blokkok nem ugyanott vannak, mint egy dm-integrity esetén az adott adat blokkban, hanem máshol, így ha adat blokk sérül (jó eséllyel fizikai hiba miatt), annak az ellenőrzője nem ott lesz és ha van másik adatblokk +1 diszken (és annak ellenőrzője), 3-ból már egyértelmű, mi a jó és mi a rossz.
De 2 diszkkel nem csak redundáns, hanem golyóálló is lesz a motyó, az biztos
Amúgy lehet ECC nélkül is élni, de nonstop bekapcsolt gépnél sok csillagnak kell úgy állnia az égen, hogy nagyon ritkán történjen bithiba. Mindenesetre jó cucc, egy ASUS lapban Ryzen 3500-el most állok át ECC-re. (Szívom is a fogam, tuning RAM-ok ki, szottyadt 2400-asok be aranyáron, de legalább ECC, majd ellenőrzöm is, ha kicsit túl feszesre veszem gyáriról a timing-okat, ahol már kezd hibázgatni, hogy hogyan viselkedik).
-
Dißnäëß
nagyúr
Btrfs felejto, beszoptam vele meg onalloban is, raid amugyis bugos (0,1 stabilnak mondott, 5-6 gaz, de szvsz az egesz btrfs gaz).
ZFS csak ECC mellett, lasd elozo hsz-ek. De ha van ECC, ez egy rohadt jo filerendszer, de kicsit erteni kell hozza, kulonben a performancia nem lesz valami top. Backupra nem hasznalnam onallo meghajton.
Esetleg ext4-hez nezz egy dm-integrity -t is, bar van ahol kellhet es van ahol nem.
A 4T-s Seagate NAS HDD-m melle vettem meg egyet, tokugyanolyan parameteru WD40PURX-et.
A seagate-en van on-the-fly error correction, igy ott kisebb a valsege a rossz bit olvasasnak, mert mar hardver szinten korrigalja a HDD. A WD nem csinal ilyet (okkal, mert surveillance hdd), ergo annal mar felnek.
ZFS mirrort epitek, desktop lap, ECC RAM, igy ez sima liba, de backupra nincs sok ertelme a ZFS-nek, ha integritast nem tud szamolni 1 drive eseten: ha nem stimmel az adat es annak checksum-ja, mi alapjan donti el a ZFS, hogy melyik a szar, az adat vagy a checksum ?
Csak 2+ diszknel van ertelme ennek, ott el tudja mar donteni, es korrigal is. Szoval vagy ecc-s gepen zfs mirrort hasznalsz backup-ra ( = 2 diszk minimum), vagy elfelejted.
2 hdd + ecc = zfs es jol parameterezni a pool-t letrehozaskor, ne defaulttal.
1 hdd = ext4.
-
Dißnäëß
nagyúr
válasz
haddent #29713 üzenetére
Na ez nagyon jó, a vasamon most egy QEMU/KVM van az XFCE Virtual Machine Manager-e szerint, úgy pár hónapos Debian rendszer, ezt kezdem belakni. Nem gondoltam volna, hogy egy cégben is használt vSphere-el szemben ez labdába rúghat, az azért elég durvi cucc, ahogy láttam, csak itthon nem szórakoztam még el vele.
A tervem az, hogy a host-ot és annak fizikai hálókártyáját ugyan az ASUS router-em LAN portjára kötöm, de lesz egy VM, ami egy teljes saját alhálónak (a többi VM-nek) lenne a tűzfala, router-e, VPN koncentrátora, mindene (egy OPNSense, én most azt tanulgatom, iptables kézzel írás után elég nyakatekert, de szokható). És pár egyéb VM egy kicsivel nagyobb projektecske környezeteinek, amibe végre belevágok.
Amúgy eredetileg nem ezért jöttem ide, csak már reflektálok és köszi a visszajelzést.
--------------------------------------------------------------------------------------------------------------------------------------------
És akkor amiért jöttem: a jövőben szeretném a gépet Pendrive-ról boot-olni.
Van 3 teljesen új, teljesen egyforma, síkugyanolyan, egyszerre vettem.1. Mindegyikre tegyem ki a /boot-ot és a végén dd-vel másoljam át 1-es tartalmát 2-3-ra
VAGY
2. MD RAID1-ezzem be őket ? Egyedülállóan is boot-olnak ilyenkor nyilván. De szerintem ez csak komplikálja a dolgokat, mert minek.Nyilván ha a rendszeren upgrade-et ill. full-upgrade-et tervezek letolni, feltétlen beteszem az egyik pendrive-ot és mount-olom a /boot-ba, majd upgrade lefut, frissebb kernel a boot-on (a pendrive-on), a pendrive-ot ismét átmásolom a másik kettőre, frissítve így őket is aktuális boot-olóra és kész, kivehetem (a /boot-ot meg umounttal egyidőben egy HDD alapú kamu /boot-al helyettesítem - vagy nem kell egyáltalán, full tökelvan a gép apt upgrade-et nem cseszegetve /boot nélkül ? Mert akkor ha umount-olom a pendrive-os /boot-ot és kihúzom a kütyüt, nem is tökölnék a helyettesítésével amúgy. Ha minek).
-
Dißnäëß
nagyúr
válasz
bambano #29703 üzenetére
Na jó, nem 24. 16-18 ? 96-ban Netscape navigátoroztam faternál a cégben és néztem a DOS után az űrtechnikát, utána jött egy ősrégi SUSE, amivel elkezdtem kapizsgálni egyáltalán, mi az a Linux, utána jöttek az első szopások VMWare-el, hát az ja, úgy kb. 2000-es évek első fele, pont gimi után. Akkoriban még jobban érdekelt az IT, mint a punci, érdekes módon.
-
Dißnäëß
nagyúr
válasz
I02S3F #29696 üzenetére
Én csak próbáltam 24 éve ezt meglépni és lepattantam. Sem a Wine, sem a virtualizáció, se semmi nem tartott azon a fejlettségi szinten, amin most.
Ma egy álom, kis túlzással. Ha ügyes az ember, lassan GPU dedikált elérést is hozzá tud rendelni VM-hez (bár ezt még nem próbáltam, ez a következő lépcső, az meg milyen már, hogy VM-ben játszunk nagy fps-ekkel)
Nem mintha játszanék, de amikor megjelenik majd a plussz VGA guest-ek felé kiajánlásának képessége, mindez két kattintásból, az piszok jó lesz
Ma rengeteg minden sokkal de sokkal könnyebb Linux-ban. Anno először SUSE-n tanultam (van még yast ?)
aztán tátott szájjal beszaladtam a Debian falloszerdőbe
-
Dißnäëß
nagyúr
válasz
I02S3F #29693 üzenetére
Ja. Soha nem gondoltam volna (de tényleg: SOHA), hogy XFCE lesz és elég mindenre nekem. Szar rájönni, hogy ennyire igénytelen vagyok.
Van két 4-terásom, végre nem kell raid-el megalkudnom, megyek egyből zfs mirror-ozni velük. (Egyik üres, másik 80% tele). Kicsit remeg a tírgyem, de e van, egyszer élünk, igaz ?
-
Dißnäëß
nagyúr
Urak !
Én elhagytam a Windows-t, jelentem. Mármint így TÉNYLEG.
Desktopon.És mióta a Foobar-t is tudom "natívban" futtatni a Linuxon, a kedvenc vizualizációs plugin-emmel, nálam beállt a nirvana. Remélem eltart egy darabig, a fotózással is leálltam egyelőre (értsd: nem kell Photoshop).
Csak gondoltam, közlöm. 10+ éve élek desktop-on dual boot-ot, ezt most elfelejtem egy időre
-
Dißnäëß
nagyúr
válasz
I02S3F #29586 üzenetére
Linux Desktop-ra tértem át egy ideje, de óriási szívfájdalmam a Foobar és annak komponenseinek futtatása. Az alap program már fut, sikerült eddig beröffentenem egy konténerizált mókolással, hogy a Photoshop-al mit kezdek, meg annak n+1 pluginjével, fejvakarós. A Gimp egy bohóckodás hozzá képest sajnos, piszkosul nem intuitív és marha kényelmetlen, logikátlan. (Bár ez mondhatná bárki, ízlés dolga, mégis kicsit úgy érzem magam, mint a német autószerelő egy Honda gyárban)..
Minden egyébre nekem tökéletes a desktop linux is, de tetszik vagy sem, tartok VM-ben windows-t, pont Photoshop miatt például. Úgysem nyer annyit hw-es gyorsításból, pl. VGA kihasználás, hogy érdemben elkezdjek emiatt pampogni, a monitor kalibrálás és ilyesmik már más tészta, de egyelőre hobbi szinten elvagyok vele. Ha újra beszállnék a félprofi ligába, lehet kell majd egy dual boot és natív W10 ismét. Meglátjuk. Egyelőre elvagyok linuxon.
-
Dißnäëß
nagyúr
Hát ezt próbálom mondani, hogy egyáltalán nem, nem láttatok még eleget
(Minden bántás nélkül). Nem infráról beszélek és alapmegoldásokról, hanem egy üzleti részleg teljes számlázója, CRM rendszere, nyilvántartója, marketing eszközei, analitikája, full-fullba úgy az egész. És ha ezen gépeket, legyen az akár virtuális, akár fizikai, beleszámoljuk a nagy egészbe, akkor gyorsan oda a torta egyharmada MS-nek.
Nyilván többet nem szeretnék erről mondani, pláne nem megoldás és cég neve(ke)t, de ez van, ezt jobb elfogadni, mint dobálózni azzal vakon, hogy 99% linux. (5 magyar telco-snál voltam és 2 banknál eddigi pályafutásom során).
De nekem mindegy is, nem hittéríteni akarok itt (pláne nem szívem mélyén Linuxosként), csak a tényeket próbálom a valósághoz közelebb hozni. 1 példa még nem példa, én pedig rálátok mindre, vannak mindenféle megoldások, de meglepően sok MS cucc van szerver oldalon is.
-
Dißnäëß
nagyúr
válasz
kovaax #29584 üzenetére
Jártam banknál is, telco-ban is, utóbbiban csücsülök, hidd el, nem átlag közismert programról beszélek, hanem olyan rendszerekről, amikről még életében nem hallottam addig, míg bele nem futottam, kezdve Big Data, Analytics, meg rahedli olyan adatgyűjtő, feldolgozó, konvertáló és egyéb környezetekről, melyek alá valahogy, valamiért egy mocsok nagy HyperV farm kellett - ugyanis nem *nix alapúak. Ezek jellemzően tényleg vendorspecifikus megoldások, nem 10 filléresek és iszonyú komplex cuccok, de ha valamiért mindegyik valamilyen Windows szerveren fut, függetlenül attól, ki hozza, akkor ott nincs vaker, azt kell beszerezni ...
-
Dißnäëß
nagyúr
válasz
bambano #29581 üzenetére
Nanana. Telco szektorban, de akár banknál is, vagy tkp bárhol, olyan irdatlan megagiga BSS stack-ek vannak Windows alapon, hogy nélkülük azonnal földbe állna az egész cirkusz. A vállalatirányítás csak 1 a listából, amit kiragadtál. Valid, de csak 1, az arányokat még így is eltolja bőven 20-30-50% körülre akár az, amikor jön egy csapat vendor egy kiírásra és röpködnek a négyjegyű CPU mag igények a proprietary cuccuk alá, amik miiiind-mind MS alapú megoldások. A vállalatirányítás Góliátja ezekhez képest szúnyogfing.
-
Dißnäëß
nagyúr
válasz
samujózsi #29464 üzenetére
Én is ipchains, de folytattam kézzel netfilterrel, nem is értettem jópár rajzig, mi van
Ezt is átbújtam töviről hegyire anno.. azért itt sokminden ülepedett.De amúgy ma már annyira komplex a védelem mint olyan, hogy túl időigényes kézzel tolni, absztrakt réteget kényelmesebb nyomkodni, egy ideje ismerkedek az OPNSense-el egy VM-ben, hát GUI ide vagy oda, van egy logikája...
-
Dißnäëß
nagyúr
válasz
samujózsi #29460 üzenetére
Én mai napig iptables-t használok, kézzel, bár az ufw könnyít(het) dolgokon.
Csekkold az iptables-persistent-et(apt install iptables-persistent), /etc/iptables könyvtárba kell és lehet a meglévő ruleset-et kitenni rules.v4 és rules.v6 fájlokba (legalábbis nálam spec, bár v6-ot nem használok sehol, így üres), iptables-save > rules.v4, ip6tables-save > rules.v6 és ezeket utána minden boot-nál tölti szépen be.
Mr. Dini: iptables -Lcsak a filter tábla szabályait mutatja mindig, defaultban a filter-en mókol, Neked pedig a nat táblában is kell ügyködni. Tehát iptables -t nat -L |less és ha az is üres, akkor kvázi nincs se nat, se csomagszűrés, se semmi, feltételezhetően policy-k is ACCEPT-en mindenhol, magyarul nyitott, default tűzfalad van, azaz bocs, nincs.
Gyorsan guglizva egy jó tutorial, a csomagok útja a kernelen keresztül ascii ábrácska arany.
[link] -
Dißnäëß
nagyúr
válasz
a.gabriel #29455 üzenetére
Sok iszonyatosan jól szóló konfig létezik amúgy, de mind natív futtatást igényel, amiket én ismerek. Csak egy zenelejátszónak pedig felesleges PC, de persze mindenkinek szíve-joga azt használni, amit akar.
Aki ragaszkodik PC-hez, az is ki tudja vinni az I2S jelet, a Pink Faun I2S kártyájával, de azt még nem próbáltam. Aki igen, dicséri, miért is lenne rosszabb egy Pi-nél..
-
Dißnäëß
nagyúr
válasz
samujózsi #29446 üzenetére
Ha megmondod, melyik típus, lehet tudok egy jobb formware-t is ajánlani Neked.
Enyémen Padavan becenevű van egy fél éve, toronymagasan veri a gyárit, pedig az sem volt rossz (sőt). Esetleg guglizd körbe. Annyi, hogy ha ASUS-nál regisztált dinamikus DNS-ed van, az ugrik az új firmware-el, nem hajlandó felvenni a gyári fw-el beállítottat. Vagy ASUS Support-al kell töröltetni, vagy elfogadni, hogy elég kretén megoldás. (És a supportot elérni is elég kretén náluk, sajnos). -
Dißnäëß
nagyúr
válasz
a.gabriel #29432 üzenetére
Szia, szerintem eléggé nyűgös konfigba fogtál. Az audiophile linux és társai lényege, hogy spéci kernellel, kicsit más erőforrás-elosztással és latency-kkel próbálják támogatni a hallgatózás élményét. Hogy ezeknek van-e értelme, vagy nincs, én arról nem mennék ölre senkivel, de aki ezeknek (feltételezett) előnyeit úgy gondolja, meghallja és élvezni akarja, az natívban kell, hogy futtassa ezen oprendszereket, nem pedig VM-ben.
Nos, ha már virtualizációnál vagyunk, a Matrix kártyádat a hypervisor-nak először is ki kell tudnia publikálnia a VM-ed felé, hogy az 1:1 lássa és a host egyáltalán ne üljön rajta, ott csak egy buta bypass van. Ez már félmegoldás, más, hogy képes-e erre a VMWare. Csípőből azt mondanám, miért is lenne, de lehet, mákod van. Így látni fogja a VM-be tett OS a karit, MAGÁT A KÁRTYÁT, nem az emulált valamit ... az arra tett külső DAC-ot is, de itt meg is szűnt a móka java, a sztori másik felét az életbe nem pótolod be egy VM-ből (lásd első mondatok).
Sajnos vagy sem, ha hiszel az ilyen audiophile linux dolgokban, natívan kell őket a gépen futtatnod. Tesztelni tesztelhetsz, nyomogathatod, milyen a kezelése, stb stb, tanulni jó a VM, de a végén natívba kell feltenned a zenelejátszásra dedikált vasra.
Én ilyen célra Volumio-zok, Raspberry Pi4-en, I2S kimenetre reclocker és arra balanced HDMI out PS Audio formátumban, így megy az I2S jel a külső DAC-ba, mondjuk egy Matrix Audio X-Sabre Pro-ba, Volumio-ban pedig csak I2S-re állítom a kimenetet, hálózatról pedig a NAS-ról játszik a gép és ollé. Egy ilyen konfig általában.. hogy is mondjam.. büntet.
-
Dißnäëß
nagyúr
válasz
samujózsi #29429 üzenetére
Szia, ha mindent és mindenkit be szeretnél terelni proxy-ba, úgy, hogy ne kerülhessék meg, én úgy csinálnám, hogy:
- transzparent proxy setup, 80, 443 kienged, meg még amit akarsz-akarnak az appok, persze proxy-tól függ, utoljára a tintahallal mókoltam ilyet, annak konfigjában is kellett túrni, hogy ő most transzparens proxy ezentúl
- böngészőkben így semmit nem kell állítani, extra portokhoz kellhet külön SOCKS5 proxy esetleg..
- iptables-el natolva vannak a kliensek gondolom, nat tábla FORWARD láncban tiltani a forgalmat kifele, akár az egészet, akár csak bizonyos portokat, de inkább az egészet és akkor csak lyukat ütni annak, amit elérhetnek a kliensek
- B opció, talán csinosabb is, bár nem annyira paraméterezhető akkor a "szűrés", hogy C osztályú hálón ülnek a kliensek mondjuk, de nincs semmi nat-olás és nincs routing-juk a net irányába, nincs gateway-ük, csak egyetlen gépnek, amit - természetesen - látnak. Ezen fut a proxy, aztán hajrá.
A fix gép lehet egy mondjuk 0.1-0.10-es fix ip tartományú régióból valami, amit "papíron" tudsz követni (MAC cím alapú DHCP által osztott-at szoktam én csinálni amúgy, de ha fontos szerverek, ne függjenek a dhcp szerver leállásától, inkább kézzel állítanám be rajtuk a fix ip-t), 0.10-től felfele meg a DHCP szerver oszt már ip-ket a pool-nak és jónapot.
-
Dißnäëß
nagyúr
válasz
samujózsi #29410 üzenetére
Szerintem már hülyére beszéltétek a témát, olvasom itt fél szemmel, de leginkább az eszköz és a felhasználás határolhatja be szvsz, min ÉRDEMES fejleszteni egy adott dolgot. A múltunk pedig, hogy mit TANULTUNK, ezzel néha nagyon nincs köszönőviszonyban..
.. ragaszkodni viszont szeretünk dolgokhoz. (Ez magyar hiba).
Esetemben például erősítőket tervezek monitorozni Arduino-kkal, amiket egy központi Pi-vel poll-olnék, adatot ide gyűjtenék be, majd lehet egy "csinos"
frontendet is építek az egész elé.
Egy másik konténerben, ugyanezen a Pi-n, meg mondjuk futtatom a teljes házautomatizálásomat akár. De legyen két Pi, köztük pacemaker+corosync és máris megvan a virtuális ip-vel létrehozott HA (high availability), ha egyik elszállna és este nem lenne fűtés.
Ok, túlzok, de értitek.
Eszembe nem jutna azon agyalni, hogy bash-ben mókoljak bármivel is.
(Ezt csak példaként hoztam).Valid dolgokról beszélgettek, csak nagyon elmenve a részletekben sztem.
-
Dißnäëß
nagyúr
válasz
samujózsi #29370 üzenetére
Az ntfs szvsz jó igásló, de annyira nem agyonszofisztikált, még az újabb iterációiban sem, mint a már említettek.
Van automatikus defrag W10-ben, igen, nálam ki is kapcsolva. Épp elég volt nagyjából 22 óráig másolni az adatokat egyikről a másikra, ami többnyire szekvenciális beolvasásra hasonlít (ha nem töredezett) és őrült random seek-elést hoz, ha töredezett. A forrás meghajtón, nyilván. Hát nálam középen volt kb. a dolog, de mindkét HDD tud olyan 150-160 mega körül, ehhez képest volt, amikor 30-50 körülre berogyott a motyó, mert seek-elt az a HDD, amiről épp olvasta az rsync a fájlt. Meg közben én tettem-vettem és csak azt hallom finoman, hogy a Seagate-emnek le akar esni a feje egy szimpla iso mellett is (tartok 1-2 Linux telepítőt is magamnál itthon). Hát mondom uhhh, ideje volt. Ugyanez az újról visszaolvasva /dev/null-ba nyersen gyakorlatilag full tempón megtörténik, seek hang nulla (bár a Purple amúgyis halkabb, de kihallom ha akarom, hát semmi nem volt).
Már 1 tera is nagyon sok. Nagyon
Az ember akkor jön erre rá, mikor egész élete belefér párszáz gigába, sőt, .. és mikor másolsz, másolsz és másolsz és csak vánszorog tetű lassan, uhh ..
4 tera = ~8 óra, szekvenciálisan, lehetőleg nulla nagyobb seek mellett, így tartható a névleges (átlag-)tempó (150MB/s). Ha a matekom nem csal. Egy töredezett HDD-ről, fájlokat másolva, nagyon megcsúszik. (Blokk módban dd-vel átment volna említett idő alatt max tempó mellett, csak akkor ugye a teljes cluster map-et, minden vittem volna, a töredezettséggel együtt). És még mindig jobban jártam így, mintha engedtem volna a Windows-nak, hogy le-defragolja telibe, pici apró blokkonként téve az adatot egyik helyről a másikra, iszonyú sokat bukva seek időn. Sehogy se jó, de a kevésbé rosszat sikerült meglépni.
-
Dißnäëß
nagyúr
válasz
samujózsi #29368 üzenetére
Én ntfs-t, egy hete. Vettem a meglévő 4 terásom mellé egy másikat, hogy na majd jól megnasozom itt a kicsi itthoni életem.
És akkor szembesültem több évnyi fragmentációval az ntfs-en, uh mondom neeee. Végül az lett, hogy btrfs-t kapott az új, áttoltam oda mindent egy rsync-el és most mindkét helyen megvannak az adatok. Az új diszk jó, agyon teszteltem, így bevállalom most azt, hogy egy zfs-t kreálok a régin, lezúzva mindent rajta nyilván, majd arra átteszek mindent az újról, végül az újat is leradírozom, zfs, majd a két zfs-t mirror-ba vágom és elvileg műxik úgy a dolog, hogy adat megmarad.
Mindezt még egy VM-ben kicsiben ledemózom és akkor elvileg jó leszek + fragmentációm sem lesz a fájl szintű másolás miatt. Legalábbis mondjuk úgy, tutira nem.
Megspórolhattam volna egy lépést, ha eleve zfs-t teszek az újra, csak meg akartam még őrizni a btrfs kompatibilitást pár napra, elég aktív zenehallgató vagyok és a W10-em látja a btrfs-t, illetve asszony raplizott, hogy elkésünk vendégségből, NAGYON csúnyán nézett, így nem volt kedvem agyonparaméterezett, jól optimalizált zfs-t kreálni rajta, maradt egy quick&dirty btrfs.
Mára meg letisztultak a dolgok, szóval...
Persze a legfontosabbakról van mentés, külső USB ház ...
Sokmindent mondanak amúgy defrag-ról, de én mostanában rájöttem arra, hogy jobb referenciadoksik alapján menni és ők általában szépen kitérnek arra, mikor igen és mikor nem. Ha jól csináljuk, soha nem kell, én sem tervezem.
-
Dißnäëß
nagyúr
Így van. Általában. (Köszi a pontosítást).
Érdekes amúgy, mert az ext4 még csak nem is CoW fájlrendszer, míg egy btrfs, zfs igen. És még ezeket sem feltétlen kell defrag-olgatni, pedig jobban van bennük az implementálva, hogy ne fragmentálódjanak annyira és ez működni is látszik, míg nincsenek agyon-teleírva (kb. háromnegyede egészséges maximum). -
Dißnäëß
nagyúr
válasz
haddent #29362 üzenetére
Szvsz úgy érdemes DevOps-ot tolni, hogy miközben egy programozási nyelvet tanul az ember, elkezdi alulról a classic IT stack-et is tanulni, az pedig infrastruktúránál kezdődik.
Nem kell CISCO CCNA (de nem ártana)
... de az OSI modellt betéve illik tudni, vagy hogy mi a különbség egy Layer3/4-es illetve Layer7-es load balancer között, amikor 2+ fizikai host-on, egyszerre több VM-ben a legkülönfélébb dolgok futnak HA-ban, mert az az igény ? És akkor jön az Apache, Tomcat, HAProxy, nginx, meg egyéb reverse és normál proxy típusok, egy kis HyperV-zés, fájlrendszer típusok és alap hatásuk (előny, hátrány), némi VMWare-ezés, például affinity group-ok, vCPU-k, aztán storage kapcsán NAS, SAN, vSAN, Fibre Channel, vissza network környékére biztonság, csomagszűrő és application tűzfalak, nat-olgatás, VLAN-ok, QoS, majd egy kis security alapok, PKI, RSA, ilyesmik.. úhhh nagyon hosszú még a lista és egy kurva kódot nem ütött le az ember, nemhogy OS-t telepített volna.
Sokkal inkább mennék DevOps tudás felszívása esetén időrendben inkább, tehát infra, network (néha egybeveszik), DB, OS, APP, middleware, virtualizáció, konténerizáció, aztán jönnek a logikai szerkezetek, mit hol min tároljunk, fájlrendszerek és azok előnye-hátránya, local/distributed, és melyiket mikor mire, minimális SQL és azokra az elérés, konnektorok (ha kell), [... nagylevegő ...]
és még felhőnél sem járunk, microservices & GW-s, messaging queues, .. szóval az egyik agyféltekét full erre a classic stack-re fókuszálnám, ami mára már rendesen bebonyolódott-fejlődött, de azért az alap legó kockákat ismerni illik.
Másik agyfélteke meg mehet python-ra közben, bár ez is érdekes, mert én node.js-en kezdtem és hogy is mondjam.. fasza.
És akkor lehet SOAP-ozni, XML, mert multik azért nem feltétlen tartják az iramot mindig a legújabb motyókkal, majd JSON/REST, API dolgok..
Van egy frontent fejlesztő haverom, fiatal srác, marha komoly guruja több nyelvnek is, kicsit most van fullstack-esedőben, de ahogy megy lefele backend irányba (még nincs a közelében), már bejön az, hogy fogalma sincs, mi az a MySQL Router, mire jó a Ceph, zfs, brtfs, XFS (és mire nem), raid szintek, raid kontrollerek (vagy nemkontrollerek), na meg akkor ismét csak network stack és suricata/zorp/ufw/iptables/routing/portok/socket-ek/vpn módszerek és típusok (pl. OpenVPN-nél nagyon nem mindegy, hogy tap vagy tun), ..
Nem rossz ez a modell szerintem és a 4-es pont nagyon is valid, sőt. Mai világban, ahol minden mindennel össze van kötve, abszolút must-have, sokkal több, mint esti mese, amit lehet csak úgy skip-elni és majd összeszedni wiki-ről, amikor odaér az ember. Pont fordítva gondolom: ha fejlesztés közben kell megoldás valamire, annak utánajárni sokkal kisebb rizikó - remélhetőleg nem refaktor indukáló
- mint egy felépített várnál mikor kiderül, hogy a ZFS alatt a raid kontroller nem IT módban van, vagy storage-ban mekkora legyen egy blokkméret, milyen redundanciát adjunk, vagy hogy mekkora VM kell egy új akárminek, esetleg konténerizálható-e de akkor swap-et ki kéne kapcsolni, ilyesmik + a teljes megoldás monitorozása, nem feltétlen nagios (bár aki szereti).. de akár ELK, akár más.. kinek mi a szájíze .. (vagy egy felhős dashboard és annak elemei), ..
A DevOps szvsz úgy mindenes, hogy ő nem a "mindenes informatikus" aki elvan a sarokban facsén és közben a főnök tudta nélkül csorog le a poresz az üvegen, mert megteheti, hanem az, aki end-to-end képes átlátni egy üzleti igény megvalósításának kihívásait mind programozástechnikai, mind alátett infra szempontból és akkor SOKKAL de sokkal nagyobb esélye van arra a cégnek, hogy egy új gigaprojektet nem kell 2 év múlva kikukázni, mert kiderül, hogy vagy nem skálázódik, vagy szarul, vagy megesz valami erőforrást, holott nem feltétlen kéne, vagy inkonzisztensen tárolódik valami adat, queue, akármi.
Nagy felelősség van egy jó DevOps-oson, ha nekem cégem lenne és menne jól, mocskosul megfizetném, hogy nálam maradjon (ha jó).
-
Dißnäëß
nagyúr
válasz
Frawly #29357 üzenetére
A stream nálunk is megy, torrenten viszont már nem vagyok, valahogy elmúlt az a korszak. Mármint regisztrálós oldalra gondolok.
Régi dal az oda-vissza másolás, bár én még sosem éltem vele, mindig programmal defrag-oltam. Most viszont nagyon jól jön, hogy csak szekvenciálisan kvázi nagyobb fejleszakító seek nélkül ír ki a cél HDD mindent. Gyorsabb is, mert a rengeteg seek idő rengeteg apró olyan idő, amikor épp semmi nem történik, csak várunk, hogy a fej A-ból B-be érjen.
Szóval összességében egy 4 terás, majdnem csurig HDD-t klasszisokkal egyszerűbb úgy defragmentálni, hogy átmásolom egy másik 4 terásra, majd vagy otthagyom, vagy vissza.
Persze ez fájl szinten él, ha nekem spéci dolgaim vannak, spéci rejtett blokkok, amikre szüksége van bárminek is, blokk szintű átvitel kell (pl. dd). De nekem csak fájlokat kell most mozgatnom hálistennek.
Az más, hogy csak ilyenre luxus tartani +1 üres másik 4 terásat. Szóval csak úgy mindennap egy ilyen nem kivitelezhető kényelmesen.
-
Dißnäëß
nagyúr
válasz
Frawly #29354 üzenetére
Kezdesz Te is már vénülni, jössz le a szerről, a sok torrentről meg marhaságról ..
Az urandom amúgy úgy van, ahogy mondod. Gyorsabb, mint a sima random, de annyira nem, hogy nálam a HDD-t kimaxolja, mondom, ilyen 60 Mb/s körülre állt be urandom-os DD-zés egy Ryzen 5 3600-ason (1 szálat 100%-ra pörgetve). Az nem valami rakéta
főleg ekkora HDD-knél. Sebességben pedig kicsivel a gyakorlati 150Mb/s szekvenciális harmada körül-felett és 1M blokkmérettel dolgoztam már, kevesebb overhead-hez. (bs=1M)
Más:
rsync-elek éppen "A" HDD-ről "B"-re, úgy hagytam a gépet reggel. Egy cp-s paranccsal szemben ennek a fájlmásolásnak csak a metódusa más (nyilván sokkal több extrát is tud az rsync), de megőrzöm azt az előnyt rsync-el is, mint cp-nél, hogy a fragmentációt nem hozom át, igaz ?A régi 4 terásom 3.7-ig be van telve, őrült sok adat és marha fragmentált már, nálam Windows automatikus defrag ki van kapcsolva tudatosan. Nem mintha a bekapcsolt sokat segítene, sőt, inkább rizikózok, hogy kinyírja a HDD-t idő előtt.
Most, hogy NAS-ba teszem, célom átmásolni mindent az újra, amire gyorsan kreáltam egy btrfs-t és most is épp csorognak át az adatok. Amit hallok az az, hogy az újnak nincs hangja, a régi pedig néha seek-elget, néha darálgat kicsit egyet, mikor hogy ugye.
Feltételezem, a régi fájlrendszer töredezettségét az átmásolással az újban megúszom, így van ?
(Ha blokkonként, dd-vel másoltam volna a régit az újra, akkor vitte volna magával a töredezettséget is - annak nem láttam értelmét).
-
Dißnäëß
nagyúr
válasz
Frawly #29343 üzenetére
- /dev/zero sebessége a diszk maximuma, esetemben fejpozíciótól függően átlagosan 150Mb/sec.
- /dev/urandom CPU mag 1 szál sebesség függő, nálam úgy 59Mb/sec
- szintén diszk maximumot tudsz randommal teleírva elérni HD Sentinel-el... (Windows alól)...
- és Linux alól úgy, hogy egy cryptsetup luksFormat-al leformázod, titkosított kötetté kvázi, ami tökrandom mintával tölti fel az egész lemezt, a végén pedig le-dd-zed a headert, vagy ha biztosra akarsz menni, 1mp alatt bele-urandomolsz dd-vel az elejébe, pár megába, és jónapot, eladható, randomizáltan, linux alól, diszk max sebességen végrehajtva.
-
Dißnäëß
nagyúr
-
Dißnäëß
nagyúr
válasz
Frawly #29328 üzenetére
Jelszó az USB stick-nek, mivel az is titkosított, GRUB Luks1-es formátumig jó. Ennek kézi jelszavas feloldását követően válik elérhetővé az a kulcs, vagy azok a kulcsok, amik feloldják a többi, Luks2-es HDD-t. Semmi extra. A többit pedig elküldöm kellően okos módon a protonmail-emre, egy veracrypt konténer fájlba téve, zip-elve, meg elrejtem még itt-ott a nagy világhálón, ha az életem akarna múlni rajta.
Így mindkettő teljesül, kellően random és nagy kulcs is a tényleges drive-ok feloldásához, meg a kényelem is és az 1 darab jó erős jelszó, ami lehet Biblia idézet, Wales-i bárdok, vagy női nemi szerv, bármi, amit akarunk
Nyilván semmi ilyen durva cucca nincs senkinek kb, csak elméletben beszélgetni érdekes ezekről.. ennyi "szenvedést" az egész nem ér egyébként, valóban.
-
Dißnäëß
nagyúr
válasz
samujózsi #29331 üzenetére
Amúgy ez érdekes, én eleinte DD-vel gyalultam őket nullásra szintén, legutóbbi 3 Seagate vinyómat pedig eladás előtt HD Sentinel Surface test WRITE módban, random pattern-re állítva. Épp zenét hallgattam Foobar-omon és lusta voltam kikapcsolni és Linuxba át-boot-olni
Ez ekvivalens nagyjából egy dd if=/dev/urandom of=/dev/sdb bs=1M cuccal
-
Dißnäëß
nagyúr
válasz
inf3rno #29327 üzenetére
Enterprise környezetben a titkosítás indokolt és nem szükséges vagy nem érdemes titkolni, hogy egy elhagyott laptop SSD-jén vagy HDD-jén titkosított az adat (Bitlocker jellemzően, de bármi egyéb akár). Tudjuk, hogy így mennek ezek a dolgok.
Ellenben magánemberként ugyanez már egészen más tészta, a biztonságnak a gyanúelterelés a legelső frontvonala (hogy meg se próbáljon nekiesni bármivel is, az agyában se forduljon meg még csak ötlet szinten sem).
Kb ennyi és ebben nincs semmi túlpara
-
Dißnäëß
nagyúr
válasz
sh4d0w #29318 üzenetére
Hát, egyrészt ez így van, másrészt fejléc nélküli luks-ról elég nehéz lenne megmondani, hogy az titkosított, annyira random adat, főleg ha előtte teleírtuk a diszket-diszkeket randommal egy dd-vel, majd arra telepítettünk az első 20-30 gigára egy alap rendszert, amit néha használunk is, csak hogy legyen rajta haszontalan "viheted" kategóriájú adat, mögötte meg mondjuk egy free space-re defragolt NTFS/exFAT partíció végig, quickformat módon létrehozva.
Biztosan van tool, ami bizonyos mintákat követve megpróbálja szektorról szektorra beolvasva a teljes lemezt, megállapítani, hogy az a random adat tényleg random adat-e, de azt mondják tőlem okosabbak, hogy IGEN, az TÉNYLEG rohadtul random, fejléc nélkül.
Az meg úgy szvsz még tanult szemnek is fejtörő akkor, mi lészen tovább. (Hacsak nem tesz a fejemhez egy pisztolyt, de arra még mindig ott a truecrypt/veracrypt és az ezzel kompatibilis dm-crypt extension-ök, plausible deniability és társai, de ez már nagyon para, nemérdekel a gyakorlatban).
-
Dißnäëß
nagyúr
-
Dißnäëß
nagyúr
válasz
sh4d0w #29313 üzenetére
Ezért lesz több belőle, vagy 4... + raw image is fájlba. A detached header-t és key fájlokat is eldugom máshova, így még ha valami csoda folytán mind a 4 USB kütyü + az img is szar lenne, még mindig csak a rendszert bukom max, azaz az OS-t magát, de akár egy Live Linux-al is fel tudom nyitni a konténert.
Illetve ha a /boot nem jó, úgy tudom, be lehet rántani az OS-t még, ennek nem vagyok nagy tudósa még (sosem volt rá szükségem), de .. szóval az OS nem érdekel, az csak úgy elvolna amúgyis. De a storage, amit kezel, legalább megmarad és elérhető és akkor telepítek alá hasonló módon egy új OS-t.
-
Dißnäëß
nagyúr
válasz
Frawly #29310 üzenetére
Az utóbbira van szükségem és ember meg nem mondja a random adatból, hogy mi van rajta, utána. Még egy eneszéj sem. Nem mintha nagyon paráznék bármitől, csak ha betörés lenne, akármi, és viszik a motyót, vigyék.
Van még 1-2 plussz módszer amúgyis, amivel aztán még ezt is lehet fokozni, de az már abszolút overkill. Lehet ez is. De ez még vállalható overkill
Arch passz, de rolling release ha jól tudom, a bug-okat nem szeretem.
Debian meg itt-ott kicsit poros, legalábbis a stable, de legalább beton.
Na, így a két véglet után elmondható, hogy egy Debian Testing-el az arany középutat járom
(Kb. Ubuntu szint, mert Ubuntu is testing-re alapul). Nekem bevált. De ez itt már off.
-
Dißnäëß
nagyúr
Nnnna, még 4 kérdés.
- Hogyan tudok legegyszerűbben úgy Debiant telepíteni egy rendszerre, hogy a /boot az USB-n van ? (LUKS2-znék /dev/sda-n).
- Netinst elég, vagy full DVD iso, vagy Debian Live alól először megkreálom a titkosítást úgy, ahogy szeretném, szépen bekonfigolom, megnyitom a kötetet és majd erre a /dev/mapper-ben lévő megnyitott kötetre telepítek az installer-rel ?
- Reboot után fel fogom tudni oldani ?
- USB boot-olás után unmount-olhatom a /boot-ot ? (És a feloldott LUKS kötet root-jában lévő akármit mount-olnám /boot-ként ?) Természetesen ügyelve arra, hogy bármilyen HDD-s /boot-ba írást követően az USB-t vissza mount-oljam és átvezessem oda a változásokat a HDD /boot-járól. Például egy apt full-upgrade után, hogy csak egy legalapabb dolgot mondjak.
-
Dißnäëß
nagyúr
Kedves Szakik !
Adott egy alkalmazás, RedHat környezet, mely a queue-ját és egyéb hozzátartozó adatokat fájlokba teszeget le, ahonnan egy másik alkalmazás felcsippenti azokat feldolgozásra.
HA-sítanánk, active/active. Létezik valami olyan megoldás, aminek segítségével mindkét aktív instance-be felcsatolható adott SAN storage és mindkét app írhat rá ?
A gond a konzisztencia kérdése, újraírni nem lehet az app-okat, HA viszont kell. NFS néha lebont és döcög, szintén nem opció. Egyéb megoldás esetleg ?
Active/passzív HA-ban a probléma megszűnik, mert egyszerre mindig csak 1 app instance írja adott könyvtárat és ha ez behal, az alatta lévő VMWare indítja azonnal a passzívot és onnantól pedig csak ő ismét.
Teljesítményt akarunk elosztani, ezért aktív/aktív az eddigi elgondolás, bár performancia bővítés nem szükséges, 1 instance is elviszi a motyót.
-
Dißnäëß
nagyúr
Köszi, hasznos. Lehet, nem kezelek letöltő könyvtárat akkor ezzel, csak statikusat.
-
Dißnäëß
nagyúr
Sziasztok,
nem vagyok valami nagy rsync guru, pedig alap eszköz, csak nekem még eddig nem nagyon kellett valahogy az elmúlt években. Szeretném megérteni a működését és ehhez kapcsolódóan lenne pár kérdésem, talán tudtok segíteni:
1. Egyszeri futtatású tool ? Gugliztam ezt a kis gyorstalpalót és nekem annak tűnik, de lehet, tévedek. Tehát lefuttatom, szinkronizál két target-et egymással és jónapot, elengedi őket, tehát miután lefutott a parancs, nem történik semmi ? (Ergo, sync után egyik könyvtárba ha másolok, nem szinkronizálódik le a másikban is, újabb futtatásig). Vagy tévedek ?
2. Van olyan opciója, hogy valami daemon monitorozza a háttérben a változásokat és automatikusan szinkronizál ? (Vagy cronjob-ból oldja meg az ember rendszeres időközönkénti futtatással?)
3. Egy irányú, vagy két irányú ? "A" könyvtár adott, "B" könyvtár üres, majd parancsot futtatva "B" -n is leképezem "A" tartalmát. De ha később "B"-be bemásolok valamit, az átjön "A"-ra ? (Ez oda-vissza irány lenne).
4. Ha van egy megnyitott fájlom (például letöltök épp valamit), azt is át-sync-eli a célkönyvtárba, vagy már csak miután le lett zárva a fájl ? Mondjuk töltök egy 2 Gigás Linux telepítő ISO-t torrent klienssel.
-
Dißnäëß
nagyúr
válasz
samujózsi #29113 üzenetére
Köszi a tippet, ránézek.
Secure boot nincs, semmit nem jelent nekem, pláne már egy csak játékra használt Windows-on majd (az egyébként natívban lesz a Linux mellett, ritkán beizzítom néha, de amúgy nagyjából off).
Az is lehet, hogy virtualizáció + NAS módra átállok az egész asztalimmal, VGA-t eladom, proci RAM HDD SDD marad és egy billentyűzetbe beállítható tablettel megyek rá remote desktop módban (vagy VNC) kódolni, az egész meg elzümmög kint a nappaliban a TV alatt.
Most így ilyenek között billegek. Ha nincs játék és 3D, márpedig ez megszűnt egy ideje, nem látom értelmét tartani egy asztali gépet. Egyelőre kísérletezgetek még, aztán ha megtaláltam a megfelelő szintézist, mit hogyan, milyen módon, milyen beállításokkal, szerintem meglépem.
(Végre akkor a router-em is lehet egy VM-be beizzított OPNSense, a meglévő ASUS-om buta módban bírja az 1000-es netet, de VPN-el már nagyon köhög).
-
Dißnäëß
nagyúr
válasz
samujózsi #29107 üzenetére
VBox tudja, egy beállítás, hogy a virtuális HDD az HDD-nek vagy SSD-nek jelentse magát a guest felé. Utóbbi esetén - most olvastam - működik a móka.
QEmu-nál nem tudom, találtam egy másik cikket arra az előbb, de kicsit mókolós. Ezen még gondolkodom.
Érdekes, hogy vajon szerver környezetben hogy megy ez, ahol a SAN-ok tele vannak rakva SSD-kkel és FC-n megkapva a targeteket egy VMWare farm VM-jeként, vajon ott mi történik mount-olás után
(Muszáj, hogy tudjon ilyet a Hypervisor, különben pillanatok alatt le-ko-zza az ember az SSD-ket).
Mindegy, hangosan elmélkedtem. Köszi a kommenteket.
-------------------------
Arról van tapasztalatotok esetleg, hogy VBox (Linux) vagy QEMU/KVM ? Állítólag előbbi is nagyon jó már Linuxra is, teljesítményben ilyen 5% körüli az overhead elvileg, a gyakorlatban van erről mérése vkinek esetleg ? A QEMU kicsit néha jobb kézzel vakarom a bal fülem esete, bár elvagyok vele..
.. viszont olyat simán csinál, hogy a host-on mind a 12 proci szálam épphogy csak terhelve, miközben egy VM-en belül is elég light-os a CPU kihasználtság, én meg közben elalszok, mire egy apt upgrade végigmegy. Mintha nem tolná full kakaón a két vCPU-t a guest, így a host sincs szétterhelve, én meg rágom a kefét, hogy "most min gondolkodooooooool???" ..Ez annyira nem tetszik, amikor lehetne gyorsabb is, ne pihenjen az a vCPU basszus. És nem az SSD fogja a mókát, nem is az 1000-es optikai net. Ilyen szép lusta komótos minden, guest is és host is. Nem ezt várnám egy Ryzen 5 CPU-s motyótól, ott a pokol CPU erő, használja.
-
Dißnäëß
nagyúr
válasz
sh4d0w #29096 üzenetére
Hát ezért hagyom meg a natív 10-et és a mostani dual boot-ot, BF-re, Starcraft-ra natív 10, minden egyébre Linux.
Keveset játszom mostanában. Még a 1050Ti eladásán is kattogok néha, aztán áhh, ne, tartsuk, jó az ilyen alkalmi bohóckodásra.
Amúgy van jópár Steam title, ami nagyon jól megy, hiszen Steam van Linux alá is és jópár támogatott game. (Mondjuk ezekből a CS: Source ami érint, annak meg nem túl nagy a gépigénye amúgy).
-
Dißnäëß
nagyúr
válasz
samujózsi #29093 üzenetére
10-es elég flexibilis ilyen téren, rengeteg mindenen beindul ugyanaz a telepítés (próbáltam már, még az Intel-AMD-Intel dupla váltásomat is túlélte egy előző install-om, csak teleszemeteltem).
Lehet simán kiköltözök róla akkor és Linux alatt egy VM-es W10-re teszem át azt a keveset, aminek Windows kell.
Arról van infód, hogy host SSD-n ha létrehozok qcow2 default formátumú diszket, TRIM van-e egészen a fizikai SSD-ig kezelve ? A rátett Linuxnak megadhatom a discard-ot, de vajon értelmezi a host OS ezt ?
-
Dißnäëß
nagyúr
Kedves haladó Linuxosok !
Dual boot-os a masinám, az SSD egy részén W10 C: , másik részén pedig egy Debian, utóbbin QEMU-s virtualizácós móka, műxik is gyönyörűen.
Van valami egyszerű mód arra, hogy meglévő W10 installációmat mount-oljam egy QEMU-s VM alá, mint HDD-t, és boot-oljon és használhassam ?
Csak érdekel és nem akarom a W10-et újratelepíteni, hanem csak leinstallálok róla olyanokat, ami nem kell és marad az, ami nem tud Windows nélkül létezni (pl. Battlefield V). Átállnék minden egyebemmel, mindennapos tevékenységeimmel a Linuxra.
-
Dißnäëß
nagyúr
..
-
-
Dißnäëß
nagyúr
Semmi komoly amúgy, csak nálam úgy "kell" archiválni, hogy közben elérhetőek is maradnak az adatok.
Mondjuk az a rahedli saját CD backup, amiket a kilencvenes évek óta gyűjtögettünk anno faterral, meg sokminden egyéb még.
Kitehetem polcra is (kint is van egy 500 GB-sen) ami hiperfontos nekem, a többi ennél mérsékelten fontosabb csak, de annál meg megint fontosabb, hogy egyetlen diszken legyenek.
Nem vagyok egyszerű eset. Na, ilyenekre jó a softraid + btrfs (míg a btrfs saját raid-szerű megoldása nem lesz iszonyú stabil, silent corruption ellen jó). De lehet végül nem tökölök és feldobok egy VM-ben egy BSD alapú NAS-t, alárendelem a diszkeket és jónapot, zfs.
Még agyalok ezen azért.rsync: a tippet köszi, le-man-ozom.
-
Dißnäëß
nagyúr
válasz
samujózsi #29064 üzenetére
DD-zni azért root kell, ha meg mezei user kezdi el tolni ezt, eléggé falba ütközik és én user-ként használom a Linuxot, nem rootként, még sudo-t se adtam a saját user-emnek.
Persze rommá lehet törni bármit.. 100% biztonság nincs.Jött már be nekem ez a softraid, mert SMART szerint az egyik HDD-n lett 1 szem (!) bad sector-om, ami elvileg pótolva lett a tartalék területről (relocated), több nem szaporodott már hónapok óta, de intő jel, hogy sürgős csere, a diszket meg megtartom
porno-ralinux iso-ra -
Dißnäëß
nagyúr
válasz
Dißnäëß #29062 üzenetére
Az már érdekesebb kérdés, hogy szükéges-e mindezt az adatot egyszerre, egyben elérni, vagy elég archiválni őket (az archív redundanciájának biztosításáról beszéltünk már?
) , vagy ahogy Te írod, backup, tehát minimum két helyen van aszinkron módon tárolva ugyanaz az adat, az egyik az élő, a másik meg akkor frissül, mikor úgy gondolja a user.
Ez jó meglátás, de én itt is hiába vannak mondjuk 2014-es képeim, a kényelmet választottam, hogy bárhol, bármikor elérem őket. Raid van, backup nincs. Raid logikai hiba ellen nem véd, viszont szegmentálva a storage-ot vagy fájlrendszereket vagy könyvtárakat (kinek mi), lehet olyat, hogy aktuál évi adat r/w, tavalyi és régebbi adat r/o -ként mount-olva és akkor ez ad némi biztonságot user hiba ellen is.
De amúgy jogos a felvetés.
-
Dißnäëß
nagyúr
válasz
samujózsi #29061 üzenetére
Szerintem nincs kavarodás. Nekem például a softraid egy desktop kategóriájú gépen belefér, nincs igényem olyanra, hogy szünetmentes táp és külön belső akkuval ellátott kontroller kártya és ilyesmi megoldások. Jó, hogy egyben lát az ember logikailag olyan dolgot, ami mind sebességben, mind megbízhatóságban tolerál minimum egy diszk kiesést, még ha minden egyéb feltétel is nemredundáns.
Alaplap SATA vezérlő beszarás és társai ellen nem véd, nyilván. (Bár ha mindegyik alkatrész külön PCIe kontrollerről megy, a softraid ezt már kezelte is, de a többi ellen akkor sem véd, pláne nem memória hiba ellen, stb. De hát a desktop az desktop).
Kérdésedre válaszolva: lehet ezt feketén-fehéren is nézni és akkor semmi értelme az otthoni raid-nek sem, a szoftver raid-nek sem (a sebességen kívül), btrfs-nek meg pláne nem. Viszont lehet szürkén is nézni és akkor oda helyezed a megkötendő kompromisszum-csúszkát, ahova szeretnéd. Van aki feketébe tolja el, szeret kockáztatni egyre nagyobbat és van, aki fehérbe, a szürkén belül, minimalizál 1-2 kockázatot. És ez így jó és szép, hogy van lehetőségünk erre.
Nem túl sok kompromisszum, nem túl sok biztonság, több kompromisszum (enterprise szerverek, pénz, zúgás), több biztonság, ezek egyszerű dolgok, de semmiképp sem egybitesek, mint ahogy az igény sem egybites, ami ezen technológiák létrejöttét indukálta.
Ha NAGYON félsz adatvesztéstől, nyilván tudod a megfelelő védekezést ez ellen, de az tökmás liga, mint egy desktop motyó tele kompromisszummal, épphogy a bare-minimumot adva. Nálam ez a bare minimum tök elég évek óta. Lehet statisztikailag kimutatható lenne, hogy az elkövetkező 80 életévem alatt mekkora az esélye egy újra és újra átmigrált többterás raid5 tömbömön ülő adat részleges, vagy teljes elvesztésének, de nem nagyon rugózom ezt agyon, viszont annak igenis piszok nagy esélye van, ha 1 diszken tárolom mindezt, hogy akár 1 éven belül is bukjam őket. Számomra elégséges ezt a kockázatot mitigálni.
-
Dißnäëß
nagyúr
válasz
OddMan #29051 üzenetére
Bár a kérdésedre nem válasz, én a btrfs raid-jellegű funkcióitól még kicsit félek, nem véletlenül írják sok helyen, hogy inkább zfs-ezzen az ember, vagy klasszik md raid. Viszont az tetszik benne, hogy nincs adat degradation, mert block level checksum-okat használ + még pár olyan funkció, ami hasznos lehet később.
Én azt látom, hogy szimpla egyedülálló fájlrendszerként (1 partícióra) ajánlják, bár mai napig nem stabil a hivatalos státusza az egésznek (ez önmagában kérdőjel ugye, hogy használjuk-e), az extra és vonzó funkciói viszont még ehhez képest is experimental szint.
1-2 hónapon belül építek egy virtualizációs host-ot, ezen lesz egy NAS-ra használt VM is terveim szerint, a host-ba 3db HDD jön az SSD-k mellé és a HDD-ket md raid 5-be teszem, majd erre btrfs-t, így a raid megvalósítás nem a btrfs-re hárul, amiben nem tudnék megbízni, hanem a klasszik softraid. És utóbbi sem tökéletes, de én még mindig kevésbé fázok tőle, mint btrfs ezen funkcióitól. (Vagy zfs, lehet errefele is elkacsintgatok, ott natívan zfs alatt merném csinálni a raidz-t, az sokkal kiforrottabb).
Jópár évig volt Debianon 3x2TB majd 3x4TB md raid 5-öm, meredek dolgokat is csináltam vele, nekem amúgy eléggé bevált, nem láttam indokoltnak a 6-ot, de ez ízlés kérdése, pedig tele voltam mindenféle fontos fotókkal (hobbi fotósként).
Egy olcsó szünetmentes nem árt azért, amit havi 1x kipróbálsz valami más fogyasztóval, akksi idő tekintetében. (Egy dolog, mit jelez magáról és egy másik dolog, hogy ténylegesen kitart-e X terhelés mellett annyi ideig, míg a gép szépen lelövi magát és leáll).
De ez csak én vagyok - 1 óvatos duhaj.
-
Dißnäëß
nagyúr
Sziaszok !
Remélem elfér haladóban, de lehet kezdőben kellene.. mindegy. (Elnézést, ha igen).
Két könyvtár közötti szinkronizációs kérdésem lenne.Van két media fájlokat tartalmazó könyvtáram, A és B. (Legyenek privát képek a DSLR-emből, raw-k).
B könyvtárat apámnak adnám egy külső HDD-n, így őt A-ból képeztem, kb. háromnegyede megvan B-n az A-nak és ez így is marad, nem kell minden.
Viszont kiderült számomra, hogy pár kisebb könyvtárszerkezeti módosítást és "újítást" B-n csináltam meg, A helyett, holott a kettőnek identikusnak illene lennie. Tehát a B-n lévő ~75%-nyi adatot vissza kellene valahogy replikálnom A-ra úgy, hogy:
- B alkönyvtáraiban ugyanazok a RAW fájlok vannak, mint A-n, ezeket skip-elje a másoló, nem kell átvinni őket újra (majdnem 1 tera)
- B alkönyvtáraiban nincsenek újabb alkönyvtárak, mint A-n, így A-n lévő alkönyvtárakat ki kéne gyepálnia a másolónak és teljesen identikusan a B alkönyvtár struktúrát kellene, hogy leképezze A-n is
- a többi alkönyvtárat A-n hagyja érintetlenülVan erre valami tool, parancs, bármi, ami segíthet ? Szinkronizálás lenne a cél, tehát ami megvan B-n már, azt tegye át A-ra úgy, hogy A-ba módosítson bele B-knek megfelelően, ami többlet pedig A-n van, azt hagyja békén.
-
Dißnäëß
nagyúr
válasz
haddent #28607 üzenetére
Az esetek többségében - kivétel mindig lesz, lehet nem is kevés - a mögöttes folyamatok sem mindegy, milyenek.
Például egy ~100+ "gépes" (VM-ek és konténerek vegyesen) teljes IT stack-et Azure-ben felépítve és üzemeltetve az erőforrás igénye sem összemérhető egy on-premise private cloude-éval, a hozzá adott csilliárd analitikáról és automatizálhatóságról meg n+1 nézetről nem is beszélve.
És aki azt mondja, nem tökéletes, meg itt-ott beteg, szar, izé ? Hát én még private cloud-ból sem láttam olyat, amibe nem lehet belekötni.
De a folyamatok mögötte akkoris... private cloud-nál vagy urambocsá, annak "elődjénél", az on-premise (akár DC-ben is) lévő üzemeltetésnél waterfall gigaprojektek verekednek iszonyú hiperdilettáns ITIL-helpdesk-szolgáltatási szinteken és xyz Service Management / Ticketing tool-okon keresztül mind hardver erőforrásért, mind élőember (know-how) erőforrásért, és mire elér valami egy úgy-ahogy értékelhető stádiumba, már újra kéne tervezni lassan a projektet, mert a világ odakint közben fordult kettőt. Egy tényleges public cloud mögött pedig (jó esetben, ha alkalmazható, de nem kötelező) egy agilis csapat valamiféle formája van, relatív nagy sebességű reakciókkal változó üzleti igényekre, amiket rendszerben is le tudnak követni és nem úgy, hogy feladom ticket-be a Change Request-et, vagy L1 felveszi nagylassan-tökhanyagul az incidens ticket-et és onnantól várunk heteket, néhol hónapokat
hogy történjen valami a hülyebuta-erőforráshiányos-nagyájtín a háttérben, hanem kb. behúzza PO a sprintbe, valamilyen prio-val ellátja oszt a devops összeüti neki öt kattintással, mondjuk egy új UAT környezetet, mert (ahogy az lenni szokott) a tesztelők épp elfogytak egy új feature tesztelésére tervezett környezetből, "mert azon még az xy release-be menő akármi egyéb fut " épp a Tosca-val, Katalonnal, vagy kőbaltával fullmanuálban. Ez agilisben egy szó szerint agilisen, gyorsan reagálva történve van lekezelve, hozzá egy ezzel kompatibilis Azure-ös pár kattintásos dologgal, amikor fogom az egyik korábban összeállított template-et (vagy az élest "replikálom", ez a legjobb, konzisztens lesz a teszt, abból pikkpakk beröffen egy újabb környezet (legyen az VM vagy konténer), felkonfigolódik, igény esetén még a frissítések is lejönnek rá, hálózat, környezeti változók, minden fiszfasz kialakul és ready to serve. Ott már nincs az, hogy az üzemeltető alvállalkozó embere túrja egy hétig meg konfigolgatja, aztán úgyis elakad, úgyis hívja Bélát a fő architektet, aki morogva de kisegíti, közben eltelt 7 nap.. Ez élőben úgy néz ki, hogy gomb megnyom, közben kimegyünk kajálni a közeli kínaiba, és mire visszaérünk, az infrás átkurjant az asztal fölött a tesztelőnek, hogy nyomhatjátok, közben JIRA-ban az erre kanban board-on felvett standalone issue-t gyorsba bekommenteli és cső, Done.
Szóval a public cloud szvsz nem CSAK magáról a technológiáról szól, hanem a mögé tett folyamatok gyorsaságról is. Arról nem beszélve, hogy ha a 100 gépből 20-30 teszt és ezek lefutnak és van kis levegő "semmittevés" teszt oldalon, ha épp nem kell az erőforrás, lelövi az ember és a stopper megáll: nem fizet érte az ember. Ha pedig kell, akár csak pár órahosszára is, akkor megint "play gomb" és mehet a boogie, pár plussz dolcsiért.
Összességében a private cloud-ban megoldott public cloud-os tech sima mezei installációként még nem adja mindazt a plusszt, amit tényleg ad egy public cloud. Persze ha nagyon kapálózik az ájtí főfejes, jöhet az MS felajánlani, hogy helybe letelepíti az ezsört az összes funkciójával együtt on-premise, csilingel is a kassza, ez szép megoldás lesz (és mindenki jól jár hehe, szép kis ország).. , csak ha 100 gép helyett 20-ra mondjuk nincs szükséged, mivel Nálad a host, az attól még bekapcsolva marad és fogyaszt, van egy költsége, míg a public cloud-ban a leverage effekt érvényesül, azaz tojsz magasan ezekre, ha nem használod az aktuális gépet pár órára vagy napra, lelövöd és kész, annyival kevesebb a költséged is, a többi meg a provider dolga (PaaS és ház a szilícium völgyben azért előrébb vannak tőlünk pár évvel). Az más, és mindenki döntse el magának, hogy a működő gépekért elkért költségbe beárazza-e a cloud szolgáltató e költségeket szétterítve - hogyne, nem hülye. De azért összességében még mindig van, amikor éves szinten több tíz millióval (!) jobban térül egy fully fledged Azure installáció, legyen az kicsi vagy nehézsúlyú k*sok gépes birkózó, mint egy on-premise private cloud csilliárdért, ami ennek tizedét sem (!!!) tudja... ahol a beszerzéstől az IT vezéren vagy CEO fővezéren át sokak kapnak vastag borítékot a beszállítótól, hogy ugyanmár, vegyétek a mi hardverünket és tessék-lássék supportunkat, segítünk, jóleszaz, egy kis Cisco ide, egy kis F5 oda, egy rack ide, egy EMC amoda, jólvan, buksisimi... A kassza meg csilingel..
Mondom ezt elfogultságmentesen kő linux pártiként és kicsit (de nem vakon) anti M$-esként.
Baszottul csak előre van út, szerintem. Erősen felhasználásfüggő, mi mire kell és megfelelő, nem jó mindenre sem egyik, sem másik megoldás, de azért a public cloud-ot nem tudnám most úgy leírni és lehúzni, mint ahogy akárcsak 2 éve is néztem rá.
A motyók több mint felét már egy ideje cloud szolgáltatóknak gyártják és ők is veszik, illetve lassan ők lesznek abban a helyzetben, hogy keresztbe-kasul bevásárolnak beszállítókból, maguknak ...
Át kell állni fejben, nincs mese.
-
Dißnäëß
nagyúr
válasz
bambano #28582 üzenetére
Egy realtime storage (fájlrendszer) kell nekem, mindenféle különösebb IO megkötés nélkül (tehát lehet lassú)
, programkód, fotók, stb. tárolására és ha én vagyok sznóden és lenne mitől félnem (természetesen nincs), akár magától az eneszéj bekkdóroktól, stb, akkor hogyan csinálnám a tutit.
A Wiki épp le van lőve, de itten ni ezt olvasom épp:
Any block device hard disks, partitions, RAID devices, logical volumes, etc can be mirrored.És ez tök jó, mert ha raid device-okat mirror-olok, akkor elvileg szintén elérhetem vele a célom, hogy 1 geolokáción csak egy értelmezhetetlen adathalmaz legyen avatatlan szemek számára, "natív" módon is akár (tehát nem szükséges titkosítás sem).
Amúgy a fentebbi leírás pont Ubuntu-ra van, ami systemd ekkor már.
Lehet kipróbálom a játékot Devuan-okon
Új hozzászólás Aktív témák
Hirdetés
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- Automata kávégépek
- Elektromos cigaretta 🔞
- PlayStation 1 / 2
- PlayStation 5
- Gaming notebook topik
- Youtube Prémium és ChatGPT
- AMD Navi Radeon™ RX 6xxx sorozat
- Kerékpárosok, bringások ide!
- 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
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Bomba ár! Lenovo IdeaPad V110 - i3-6GEN I 4GB I 128GB SSD I 15,6" I HDMI I Cam I W10 I Garancia!
- BESZÁMÍTÁS! GIGABYTE AORUS ELITE Z790 i7 14700K 64GB DDR5 1TB SSD 7900XTX 24GB be quiet! SB802 1000W
- Dixit 4 Eredet (bontatlan, fóliás kártyacsomag)
- 0% THM 3 havi részlet! Beszámítás, 27% áfa, Sapphire Nitro+ RX 9070XT 16GB készletről
- Corsair Katar Elite WL egér eladó (csak vezetékesen megy)
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest