-
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
-
bambano
titán
válasz #40935168 #13055 üzenetére
az alapkérdés az, hogy a vm-ekben futó szervereknek látni kell egymás fájljait? mert ha nem, akkor az egész kérdéskör felesleges.
azt én nem tartom jó megoldásnak, hogy egy webszerver fájlszerverről töltse a fájlokat.
debianok között fájlmegosztásra egyébként az nfs való.
szerk: gondolom most partíciókon vannak a guestek adatai, ha osztani kell a szervert, akkor a partíciót kell másolni és kész.
[ Szerkesztve ]
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#40935168
törölt tag
válasz #40935168 #14009 üzenetére
Ez lenne jó, vagy van más, amit inkább ajánlotok ?
NFSv4
Version 4 (RFC 3010, December 2000; revised in RFC 3530, April 2003), influenced by AFS and CIFS, includes performance improvements, mandates strong security, and introduces a stateful protocol.[3] Version 4 became the first version developed with the Internet Engineering Task Force (IETF) after Sun Microsystems handed over the development of the NFS protocols.
NFS version 4.1 (RFC 5661, January 2010) aims to provide protocol support to take advantage of clustered server deployments including the ability to provide scalable parallel access to files distributed among multiple servers (pNFS extension).
-
Jester01
veterán
válasz #40935168 #16425 üzenetére
Nekem már évek óta van USB gépösszekötő kábelem, igaz abban van egy kis filléres elektronika és csak USB2.0-ás.
Úgy látszik van ilyesmi USB 3.0 változatban is.
[ Szerkesztve ]
Jester
-
-
rt06
veterán
válasz #40935168 #16559 üzenetére
nalam hasonlo kornyezetben ez ugy van megoldva, hogy az eth0-t beken hagyom (szinten van neki egy statikus ip-je, amin keresztul kapcsolodik az internetre), s e mellett van egy bridge a xen altal letrehozott virtualis eszkozoknek
debian-on nem tudom, hogy ezt hogyan tudod config file-okban megadni, de elvileg a brctl addbr br0 ott is kell, hogy mukodjon
szoval ezzel letrehozol egy bridge-et, majd adsz neki egy 192.168.0.1-es cimetha tippelnem kellene, valami ilyesmi kell a /etc/network/interfaces file-ba az eth0 beallitasain kivul:
iface br0 inet static
bridge_ports eth0 eth1
address 192.168.0.1
broadcast 192.168.0.255
netmask 255.255.255.0ezzel megvan a dom0 halozati beallitasa (felteve, hogy a net eddig is mukodott), meg majd egy kis iptables kell a vegen
kovetkezo lepes, hogy a domU-k config-jaban megadod a vif-nek, hogy:
vif = [ "bridge=br0,mac=00:00:bc:e3:e1:3d,ip=192.168.0.2" ]
vagy valami hasonlot, attol fuggoen, hogy minek nevezted el a bridge-et, milyen mac es ip cimet szeretnel
fontos, hogy ha 4.2-es, vagy ujabb xen-t hasznalsz xl toolstack-kel, akkor az ip e modon torteno megadasa nem fog mukodni, mindenkepp a domU-n belul kell azt beallitania domU halozati beallitasa igy kell, hogy kinezzen (ha debian):
auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
mas rendszeren ertelemszeruen az ott megfelelot, de a lenyeg, hogy az ip, az alhalozati maszk es az atjaro mellett nem kell mas (ez igaz win-re is, ott is csak par kattintas es kesz)vegezetul meg arra van szukseg, hogy a dom0-an beallitsd az ip forward engedelyezeset es a nat-ot:
echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
echo 1 > /proc/sys/net/ipv4/conf/default/forwarding
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEha nem felejtettem ki semmit, akkor ezt kovetoen mukodnie kell az interneteleresnek a domU-kon belul, es amennyiben beallitasz megfelelo forwarding szabalyokat, ugy a domU-k elerhetoek lesznek a kulvilag felol is
szerk.: amit fentebb rendre kihagytam, az a nevszerverek beallitasa, enelkul ugye nem lesz nevfeloldas
legegyszerubb a megfelelo nevszervert kezzel beallitani a /etc/resolv.conf-ban (ha van a dom0-an bind, vagy hasonlo, akkor akar annak a cime is lehet, vagy ha nincs, akkor azok a cimek, amik a dom0-an vannak beallitva)[ Szerkesztve ]
Politikailag korrekt, valamint munkahely- és gyermekbarát aláírás, amiben egyáltalán nincsen p*na.
-
rt06
veterán
-
bambano
titán
válasz #40935168 #16649 üzenetére
X nem kontárkodik semmilyen network scriptbe. Az, hogy startx-re megfagyott, hardverközeli probléma lesz szerintem.
Az összes problémát megoldaná szerintem, ha nem ragaszkodnál a windowsos felfogáshoz, hogy távoli asztal elérés meg hasonló özönvíz előtti ócska megoldások, hanem használnád a rendes linuxos grafikus módszert. Felraksz egy X szervert a desktopodra (windowsra is van), és azzal éred el a gépen a grafikus cuccokat.
az ilyen vnc nevű betegséget egy esetben tudom hasznosnak elfogadni, amikor a xen virtualizál egy videokártyát a guesteknek és azt a videokártyát akarod elérni.
A linuxban még mindig fullextrás hálózat-transzparens grafikus felület van. Kb. három nagyságrenddel értelmesebb, mint bármi más.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
válasz #40935168 #16652 üzenetére
ebben az esetben javaslom, hogy otthon a desktopodon rakj össze egy ugyanolyan cuccot, azon grafikusan faragd meg a konfigokat és azokat másold át a szerverre.
másik verzió: megkérdezed a konkrét xen-es problémádat, van itt egy-két kolléga, aki xen-nel alszik-kel, és segít megoldani grafika nélkül.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
-
rt06
veterán
válasz #40935168 #16652 üzenetére
ekkor en is azt tudom javasolni, amit bambano, miszerint tegy fel egy xserver-t (windoze-ra pl xming, lehet van mas is, en ezt szoktam hasznalni), es azzal kapcsolodj
itt talalsz egy reszletesebb leirast arrol, hogy ez mikent is valosithato meg
es lehet erre nem jol emlekszem, de a linux-os rendszeren ehhez nem kell futnia az x szervernek, nem kell startx, elegendo, ha megvannak a lib-ek (enelkul nem is indulnanak a programok
a vnc - mint bambano is irta - leginkabb arra jo, hogy mar a boot folyamat alatt (amikor meg nincs beallitva a halozat sem, nem hogy az xserver, vagy az rdp) kapcsolodni tudsz egy-egy domU-hoz, igy akar cd-rol is telepithetsz (windoze-t maskent nem is nagyon lehet), vagy egy boot kozben felborulo rendszert is megprobalhatsz helyretenni (grub piszkalas, initramfs-bol utasitgatas, etc)
bambano: ugy remlik, hogy putty es kming hasznalataval nincs szukseg semmilyen egyeb port kinyitasara egyik oldalon sem (sosem neztem, de gondolom megoldja tunnel-ekkel)
[ Szerkesztve ]
Politikailag korrekt, valamint munkahely- és gyermekbarát aláírás, amiben egyáltalán nincsen p*na.
-
rt06
veterán
válasz #40935168 #16660 üzenetére
virt-manager-t sosem hasznaltam, en igy eloszor a /etc/init.d konyvtarban neznek szet, van-e ott hozza tartozo initscript, es ha van, akkor kilonem a boot/default runlevel-bol
Politikailag korrekt, valamint munkahely- és gyermekbarát aláírás, amiben egyáltalán nincsen p*na.
-
őstag
-
őstag
válasz #40935168 #20496 üzenetére
Persze, én értem, bár hogy mi lesz a default ajánlás, az egy másik kérdés, tény, hogy egyes fícsőreivel jobb, mint az ext4, főleg backupként. Gondolva itt a transzparens tömörítésről, vagy arról, hogy 1 adatot csak 1 helyen tárol, vagy csak a különbségek kiírása...stb. Bár éppen ez utóbbi fícsörje egy szép nagy drawback is, rendesen tud kattogni a winyó a töredezettségtől, ha erről programok / OS fut.
Másfelől, mivel épp Debian alól használod, ami nem arról híres, hogy a latest kernel fut rajta, így nem is gondolnám, hogy a latest BTRFS driver mellett fogsz dolgozni, így azért több buggal szembesülhetsz, persze backportból keresgélhetsz frissebb kerneleket.Azt, hogy mennyire hájp az instabilitása, azt nem tudom felmérni, saját tapasztalataim igazából egy szobával arrébbról szereztem, neki volt, hogy napokig várnia kellett a fixelő toolokra a fejlesztőtől, mert összeomlott a fájlrendszer. Azért szép volt látni, hogy winre kényszerült egy hétre a hülye bétafájlrendszer-mániája miatt.
De, azt nem tudom neked megmondani, hogy mitől seekel be az ext4. Lehet az is valami kernel bug, de nem hinném, hogy ezt senki ne vette volna észre... ilyen problémába még nem ütköztem.
[ Szerkesztve ]
Tegnap még működött...
-
őstag
válasz #40935168 #20498 üzenetére
FAT32
Én csak felhívtam a figyelmet, hogy instabil fájlrendszer sosem nagy ötlet, főleg, ha azokon vannak a "mentéseink", és pótolhatatlan dolgaink.
Nem tudom, hogy mennyire kényszer vagy sem, hogy ext4 is csak valami bugot talált, lehet idővel megoldódott volna, vagy újraformázás... vagy új kernel. Tényleg nem tudom.
Egyébként van azért még fájlrendszer, XFS, JFS, ZFS (bár ezt a kernel licenc okok miatt nem támogathatja).Tegnap még működött...
-
Vladi
nagyúr
válasz #40935168 #20498 üzenetére
Nem csak elvből lenne morbid.
ext3 nem jáccik? xfs is van. Úgyhogy válogathatsz még. ext4nél meg lehet valami bug lett, ilyen fejlesztői levlistáknál próbálkozhatnál, ha van kedved.
Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!
-
Jester01
veterán
-
#40935168
törölt tag
válasz #40935168 #22137 üzenetére
Istenem, de megagyökér ez az Intel Rapid Storage Raid vezérlőszoftver..
- 3 vinyómból egyiken vannak adatok, másik kettő töküres. (A rendszer külön SSD-n van).
- Port 0 - üres vinyó
- Port 1 - 98% tele vinyó
- Port 2 - üres vinyóHa őket az RST szoftverrel be akarom tenni raid5-be, felajánlja - amennyiben Port0 vagy Port2-es vinyón van adat - hogy mentse őket. A Port 1-en lévő tényleges adatokat meg nem látja, nem ajánlja fel rá a raid5 migrálás előtt, hogy tartsuk meg az adatokat és a másik két vinyót felülírhatja.
Istenem, de kőbuta. De megcsináltam azt, hogy elkezdtem Port2-es vinyóra átmásolni Port1-es tartalmát, feléig jutottam a türelmem miatt. És arra bezzeg felajánlja, érzékelve, hogy van rajta adat, hogy azt tartsuk meg, vagy Port0-t, ha arra is csináltam egy bitnyi adatot, tökmindegy mit. De Port1-es majdnem tele vinyó dataira tojik..
Áááá hagyom én ezt a szenvedést a picsbe, komolyan, ...
Odaadom a 3 HDD-t direct access-be egy Virtualbox-os Debian VM-nek és mdadm-el megcsinálom. Nem gondoltam volna, hogy ezek az alaplapi megoldások ennyire de ennyire mocsok faék egyszerű kőbuta dolgok..
Ja és amikor abort-oltam 0-ás és 2-es diszkekből egy raid1 kreálást, offline-ba lőtte a Winfos a 2-es diszket, mondván, hogy azonosító conflict van a 0-ás HDD-vel Omg.. mert ugye a raid1-el elkezdte tükrözni egyiket a másikra.. Na mondom oké, akkor keressünk valami kinullázást.. ja, hogy itt nincs dd .. lássuk csak lássuk csak .. áhh, HD Sentinel felület teszt.. desktruktív .. indít.. enged menni 10mp-ig ..
.. és lám, már nincs is conflict, initialize, GPT és ollé.
Istenverte barom MS, Intel, mindenki
Linuuuux óhb*meg, I LOVE LINUX.
-
Vladi
nagyúr
válasz #40935168 #22143 üzenetére
Naugye.
Egyébként pont nemrég volt itt szó arról, hogy hardveres vagy szoftveres raid. A tied hardveres? Vagy ez ilyen fake hardver, hogy valójában még egy szoftveres réteged is van?Nem félünk! Nem félünk! Itthon vagyunk e földön. Nem félünk! Nem félünk! Ez nem maradhat börtön!
-
őstag
-
őstag
-
-
őstag
-
őstag
-
#40935168
törölt tag
válasz #40935168 #24453 üzenetére
Illetve még egy kérdés: ha teljes boot meghajtót akarok titkosítani - ilyet nem tud a rendszer ? Kéri a Debian installer most tőlem, hogy ha a root fájlrendszert titkosítom, akkor egy titkosítatlan /boot-ot adnom kell neki azért, az induláshoz. Itt gondolom ügyeltek Linuxék arra, hogy érzékeny adat ne legyen még csak véletlen sem.
-
devin77
csendes tag
válasz #40935168 #24453 üzenetére
Az SSD-n lesz a rendszer, a két diszk pedig RAID1-ben, ami valahová fel lesz csatolva?
Először mindenképp a RAID-et hoznám létre, utána a LUKS, tetejére LVM.
Így az LVM csak akkor hozzáférhető, ha a titkosításhoz való hozzáférésen sikeresen túl vagyunk.
Erre jön a fájlrendszer.Egyébként lehet RAID-LVM-LUKS is a sorrend, például ha az a cél, hogy az LVM -en belül ne mindegyik partíció legyen titkosított.
-
bambano
titán
válasz #40935168 #24453 üzenetére
ha a titkosítást a raid alá teszed, duplán fogod erőltetni a prociban a titkosító programrészt.
ha a legtetejére teszed a titkosítást, akkor lehetőséged van eldönteni, hogy minden lvm kötetet ugyanazzal titkosítasz vagy mindegyiket mással, esetleg nem titkosítod egyiket-másikat.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Új hozzászólás Aktív témák
- Telekom mobilszolgáltatások
- Gaming notebook topik
- Milyen TV-t vegyek?
- Politika
- gban: Ingyen kellene, de tegnapra
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Micro Four Thirds
- Eredeti játékok OFF topik
- Samsung Galaxy S21 FE 5G - utóirat
- Milyen cserélhető objektíves gépet?
- További aktív témák...
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Bitdefender Total Security 3év/3eszköz! - "Tökéletes védelem most kedvező áron..."
- AKCIÓ! - STEAM kulcsok /Anuchard, Aragami, Children of Morta, stb. - 2024.04.17.
- Steames kulcsok jó áron eladóak!
- Adobe Creative Cloud - 2024. 04. 05 - 2025. 04. 05-ig