Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Dzavy 12. 12. 2015, 01:52:01
-
Potřebuju úplně jednoduchou věc - nabootovat ze sítě a pokud možno automaticky naimigovat lokální disk obrazem ze sítě. To je to taková exotika? Našel jsem jenom řešení s Clonezillou a zatím s ní mám problémy (zbytečně velká, zoufalá dokumentace, plno chyb)...tak jsem se chtěl zeptat jestli to někdo neřešil. Psát si pro to vlastní "distribuci" mi přijde zbytečný a komplikovaný.
Stačí aby to umělo základní typy ATA/SATA a síťovek, konfigurace ideálně v DHCP nebo TFTP, image z NFS, nic víc.
-
Pro jake mnozsrvi pocitacu to resis? Je to jednorazova akce? Pokud pro vice nez se Ti oplati obihat s instalacnim mediem a pravidelne, pak se podivej po OPSI. Jinak TFTP, PXE, nfsroot nastavit rucne. Na to je navodu dost.
-
Klonovat pomocí dd je při současných velikostech disků dost hloupost. Navíc takový image nemůžeš nahrát na libovolný disk, musel bys dodržet velikost disku. Určitě chceš použít ntfsclone (Windows) nebo tar/dump (unixoidní systémy).
Nejpohodovější PXE bootování, který jsem zatím viděl, má FreeBSD. Potřebuješ:
1. přidat 3 řádky do konfigurace DHCP serveru
2. na TFTP server umístit jeden soubor (pxeboot)
3. přes NFS vyexportovat root (nemusíš FreeBSD instalovat, stačí rozbalit distribuční soubory base a kernel z ftp://ftp.cz.freebsd.org/pub/FreeBSD/releases/amd64/amd64/10.2-RELEASE/)
4. při prvním bootu mít ten NFS share rw a doinstalovat potřebné balíky (viz freshports.org - ve tvém případě to asi bude jeden příkaz "pkg install fusefs-ntfs")
5. nastavit spuštění ntfsclone po startu (nejspíš budeš chtít upravit /etc/ttys nebo /etc/rc.local)
6. pokud chceš i vytvářet partitiony, FreeBSĎácký gpart je příjemný, dobře skriptovatelný a nejspíš umí všechno, co bys mohl potřbovat (GPT i MBR, zapisování bootsektorů)
Pokud bys FreeBSD chtěl použít, rád poradím s detaily. Pokud bys chtěl Linux, celkem bych se přimlouval za TinyCore, ten je rozumně velký, celkem čistý a pochopitelný a dá se docela slušně upravit.
-
Tak me napada, ze kdyz v tech strojich je lokalni disk, jestlipak umi umet bootovat ze site? Ze by tam jako vyrobce prihodil bootrom, protoze mel dobrou naladu?
-
Tak me napada, ze kdyz v tech strojich je lokalni disk, jestlipak umi umet bootovat ze site? Ze by tam jako vyrobce prihodil bootrom, protoze mel dobrou naladu?
Bootování ze sítě přes PXE umí úplně každý současný počítač a úplně každá současná síťovka má PXE rom.
-
Image bude mit cca 40MB (je to OpenWRT) a po prvnim startu si sam zvetsi root partition podle velikosti disku :) takze dd by melo stacit, ale urcite se podivam i na jiny moznosti. Mam to ted primarne na jednodussi vyvoj - nez muset porad kopirovat novej build na flashku atd.
OPSI jsem neznal, dik, i kdyz to fakt vypada trochu jako overkill.
Mirek Prymek: dik moc za tip, cekal jsem ze to budu muset udelat takhle, ale nevypada to zas tak hrozne. Asi nejdriv zkusim AlpineLinux (ten trochu znam), ale tomu BSD se urcite branit nebudu.
-
Image bude mit cca 40MB (je to OpenWRT) a po prvnim startu si sam zvetsi root partition podle velikosti disku :) takze dd by melo stacit,
Aha, tak to je jiná, v tom případě je určitě dd správná volba. Pak to teda asi chceš hrnout na nějaký kdovíjaký zařízení s kdovíjakou platformou, tak to by BSD nemusela být dobrá volba.
Pokud bys z nějakýho důvodu cestou FreeBSD nakonec chtěl jít, tak se mi určitě ozvi - už jsem to používal, takže vím, jak na to, a potřebuju to tak jako tak kvůli čemusi oživit, takže přesnej návod můžu sepsat, případně i dát ke stažení všechny potřebný soubory. Akorát to teď pro mě není úplně priorita číslo jedna, takže nemůžu slíbit, že by to bylo zítra ;)
-
na GNU/Linux server isc-dhcpd-server + tftpd-hpa + pxelinux (nebo ipxe)
pro stanice pak priprav kernel + initramfs s moduly pro nfs a sitovku co nems v jadre, das si tam busybox s dd appletem a pridas skript co pripoji nfs share a pusti dd...
-
Klonovat pomocí dd je při současných velikostech disků dost hloupost. Navíc takový image nemůžeš nahrát na libovolný disk, musel bys dodržet velikost disku.
To neni tak uplne pravda, on se ten image da namountit a pak si s tim delat cokoli treba na urovni FS ;)
sudo fdisk -l ddImage.img
sudo mount -o loop,offset=partitionOffset ddImage.img ~/temp/tmpmnt/
-
Tazatel: libovolná distribuce, u které rozchodíš bootování ze sítě, a do init skriptů si dáš příkaz, který ti systém zkopíruje (dd, bmaptool, tar, rsync…).
sudo fdisk -l ddImage.img
sudo mount -o loop,offset=partitionOffset ddImage.img ~/temp/tmpmnt/
kpartx
-
To neni tak uplne pravda, on se ten image da namountit a pak si s tim delat cokoli treba na urovni FS ;)
Jo, můžeš třeba pak na úrovni FS použít ten ntfsclone, co's mohl použít rovnou :)
-
OPSI jsem nastřelil protože jsi nenapsal přesné potřeby. Pokud se jedná o jednotky počítačů, tak to rozhodně nemá cenu. Zajímavé zacíná být od okamžiku kdy máš učebnu, nejlépe však více. V práci nám obhospodařuje cca 1000 stanic na spoustě lokalit a je to zlatá věc.
Jinak to, co psal Mirek Prýmek ohledně *BSD, tak platí víceméně s mírnýma obměnama i pro Linux. V podstatě na to můžeš použít i to OpenWRT. Nestavený DHCP server, TFTPD (obojí umí zastat Dnsmasq) plus NFS export root-u toto OpenWRT. A můžeš zkoušet. Až odladíš OpenWRT přes NFS export, tak vyzkoušíš image na disku a je to...
Image bude mit cca 40MB (je to OpenWRT) a po prvnim startu si sam zvetsi root partition podle velikosti disku :) takze dd by melo stacit, ale urcite se podivam i na jiny moznosti. Mam to ted primarne na jednodussi vyvoj - nez muset porad kopirovat novej build na flashku atd.
OPSI jsem neznal, dik, i kdyz to fakt vypada trochu jako overkill.
Mirek Prymek: dik moc za tip, cekal jsem ze to budu muset udelat takhle, ale nevypada to zas tak hrozne. Asi nejdriv zkusim AlpineLinux (ten trochu znam), ale tomu BSD se urcite branit nebudu.
-
Jinak to, co psal Mirek Prýmek ohledně *BSD, tak platí víceméně s mírnýma obměnama i pro Linux. V podstatě na to můžeš použít i to OpenWRT. Nestavený DHCP server, TFTPD (obojí umí zastat Dnsmasq) plus NFS export root-u toto OpenWRT. A můžeš zkoušet. Až odladíš OpenWRT přes NFS export, tak vyzkoušíš image na disku a je to...
Velký rozdíl je v tom, že:
1. FreeBSD ani pro pxe boot nepoužívá initrd, který způsobuje problémy, zvlášť pokud chci nějak zasahovat do bootovacích skriptů
2. má přímo v initscriptech zabudovanou podporu pro bezdiskové fungování - pokud root mountnu rw, můžu normálně věci měnit na NFS serveru, pokud mountnu ro, automaticky se mi vytvoří ramdiskové /tmp, /var apod.
3. (tohle se v tomhle případě nevyužije) má bezvadně vyřešenou možnost customizace konfgurace při diskless fungování - stačí adresář /conf, v něm adresář default a pak adresáře podle mac adres pro různé speciální stroje. Cokoli je v nich, se automaticky sloučí s default konfigurací, vytvoří stejnojmenný ramdisk a namountuje na stejné místo v rootu. Takže tímhle způsobem můžeš třeba u některých strojů překrýt klidně /bin, kdybys to potřeboval :)
Nevýhodou je pomalejší boot (zvlášť oproti systemd) a menší podpora hw.
-
Potřebuju úplně jednoduchou věc - nabootovat ze sítě a pokud možno automaticky naimigovat lokální disk obrazem ze sítě. To je to taková exotika? Našel jsem jenom řešení s Clonezillou a zatím s ní mám problémy (zbytečně velká, zoufalá dokumentace, plno chyb)...tak jsem se chtěl zeptat jestli to někdo neřešil. Psát si pro to vlastní "distribuci" mi přijde zbytečný a komplikovaný.
Stačí aby to umělo základní typy ATA/SATA a síťovek, konfigurace ideálně v DHCP nebo TFTP, image z NFS, nic víc.
mozna se chces kouknout na: http://kadeploy3.gforge.inria.fr/, ale mozna to je to take kladivo na vrabce.
Kdybych to resil ja, tak si nastavim diskless boot z RO partisny me oblibene distribuce (je to celkem jedno jake, jen u centosu a spol. musis mit spesl kernel image ktera v sobe ma moznost sitoveho bootu, ale je na vsech mirrorech), a do rc.local diskless FS nebo tak nekam naskriptuju vytvoreni partisen, data prenesu rsyncem - rsync over ssh ma i jakousi kompresi, tak to neni takovy sitovy load jako raw dd.
Jediny nad cim se budes muset zamyslet je jak menit preferenci bootu po naliti image - aby se preimagovani disku nedelalo dokola. Da se resit pomoci ipmitool-u, zmenou konfiguraku dhcp zasahem do souboru v tftp a urcite x dalsimi zpusoby.
-
Jediny nad cim se budes muset zamyslet je jak menit preferenci bootu po naliti image - aby se preimagovani disku nedelalo dokola. Da se resit pomoci ipmitool-u, zmenou konfiguraku dhcp zasahem do souboru v tftp a urcite x dalsimi zpusoby.
Imho nejlíp automatizovatelný řešení jsou dvě:
1. konfigurace DHCP v LDAPu - pro nabootování klonovacího image je potřeba změnit v LDAPu jenom jeden záznam, potom smazat
2. bootovat vždycky přes PXE, přičemž defaultní konfigurace pxelinuxu je nabootovat z disku. Pokud chci nabootovat něco jiného, vytvořím v pxelinux.cfg symlink konfigurace bootující daný image na MAC daného stroje. Po nabootování ho smažu.
BTW, u PXE je docela oříšek bezpečnost. DHCP server se dá snadno podvrhnout a bránit se tomu dá jenom DHCP snoopingem, který mají jenom dražší switche.
-
bránit se tomu dá jenom DHCP snoopingem, který mají jenom dražší switche.
Podpora je uz nastastie aj na lacnejsich switchoch - TL-SG2008 za cca. 60 € podporu DHCP snoopingu ma. Osobne povazujem tento switch za vynikajuci na rozlicne male testovacie siete - podporuje VLANy, link aggregation, QoS, ACL na urovni MAC adresy, IP adresy alebo portu, SNMP, authentikaciu cez 802.1X/Radius, okrem web rozhrania ma command line s Cisco syntaxou, ...
-
1. konfigurace DHCP v LDAPu - pro nabootování klonovacího image je potřeba změnit v LDAPu jenom jeden záznam, potom smazat
2. bootovat vždycky přes PXE, přičemž defaultní konfigurace pxelinuxu je nabootovat z disku. Pokud chci nabootovat něco jiného, vytvořím v pxelinux.cfg symlink konfigurace bootující daný image na MAC daného stroje. Po nabootování ho smažu.
On první bezpečnostní problém je, že pokud to má být plně automatizovaný, je potřeba aby tuhle změnu (PXE->HDD) udělal skript na závěr partisnovani a rsyncovaní (nebo dd..) . A pokud si člověk nechce udělat díru do server-side (viz níže) , nejjednoduší je přes nějaké API zatahat za místní BIOS/IPMI/ilo/idrac, protože skript bude mít stejně místního roota a tím plný přístup k HW.
Ale ten LDAP, který navrhuješ, je IMHO dost zajímavý tím, že se v něm dají poměrně dobře nastavit oprávnění, a asi by si s tím šlo vyhrát a udělat to taky dost bezpečně. (jednorázové oprávnění per session jen k danému objektu)
BTW, u PXE je docela oříšek bezpečnost. DHCP server se dá snadno podvrhnout a bránit se tomu dá jenom DHCP snoopingem, který mají jenom dražší switche.
+1.
další bezpečnostní problém je síťový FS pro root. Většinou to bývá NFSv3 = žádné zabezpečení -> v image nesmí být žádné "tajemství" (priv. klíč atd.)
-
jose_d: jednu dobu jsem si trochu lámal hlavu s tím, jestli by to celé šlo udělat opravdu bezpečně za rozumných nákladů a dospěl jsem k tomu, že nešlo (netvrdím, že to je správný závěr, jenom mě prostě nenapadlo nic, co by nemělo nějaký háček) - že to prostě vždycky bude nějaký kompromis, který má díry, a je potřeba jenom v dané situaci zvážit, jestli jsou to díry akceptovatelné...
Zásadní problém mám s tím, že stroj vůči serveru vystupuje jako tabula rasa, takže nemá žádné dostatečně silné tajemství pomocí kterého by se mohl autentizovat. Takže jsem se rozhodl přijmout jako fakt, že je potřeba mít aspoň ve chvíli instalace fyzicky zabezpečenou linku mezi strojem a serverem + DHCP snooping. Když tohle přijmu, tak už to dál není tak těžký (viz níž).
On první bezpečnostní problém je, že pokud to má být plně automatizovaný, je potřeba aby tuhle změnu (PXE->HDD) udělal skript na závěr partisnovani a rsyncovaní (nebo dd..) . A pokud si člověk nechce udělat díru do server-side (viz níže) , nejjednoduší je přes nějaké API zatahat za místní BIOS/IPMI/ilo/idrac, protože skript bude mít stejně místního roota a tím plný přístup k HW.
To mi přijde zbytečný. Stroj nemusí konfiguraci PXE ovládat, stačí když bude umět odeslat (jakýmkoli kanálem) zprávu "už je to hotové". Logika může být pak už umístěná v bezpečí na serveru. Jelikož následná akce (smazání symlinku) nemá moc žádné bezpečnostní důsledky, nemůže ovlivnit konfiguraci jiných strojů atd., myslím, že tuhle zprávu není ani potřeba jakkoli autentizovat - stačí případně ověřit, že přišla jenom jednou...
Ale ten LDAP, který navrhuješ, je IMHO dost zajímavý tím, že se v něm dají poměrně dobře nastavit oprávnění, a asi by si s tím šlo vyhrát a udělat to taky dost bezpečně. (jednorázové oprávnění per session jen k danému objektu)
LDAP je dobrý na to, že se na něj dá dobře strojově šahat (líp než na soubor) a jsou knihovny pro různé jazyky. Nějaké zvláštní šaškování s právy není potřeba, pokud záznam v LDAPu mění software na serveru (jak jsem psal v předchozím odstavci).
další bezpečnostní problém je síťový FS pro root. Většinou to bývá NFSv3 = žádné zabezpečení -> v image nesmí být žádné "tajemství" (priv. klíč atd.)
Jasně, to je základ - na TFTP serveru ani na NFS nesmí být žádné tajemství. Otázka ale pak je, jak ho tam dostat, když nemá, jak by se autentizoval ;) Myslím, že pro většinu běžných situací je dostatečně bezpečný ten princip, co jsem psal výš - tajemství vydám na dotaz, jenom ve chvíli, kdy vím, že se instaluje, a kontroluju si, že o něj bylo požádáno jenom jednou.
Takže celý by to mohlo vypadat nějak takhle:
1. serverový SW nastaví v konfiguraci PXE "stroj A teď má nabootovat klonovací image"
2. stroj A nabootuje ne-tajný klonovací image z TFTP, popř. veřejné RO NFS
3. skript na klonovacím imagi stáhne ne-tajný připravený image chtěného OS
4. skript požádá server o tajemství (token)
5. server mu ho dá a nějakou chvíli čeká, jestli nedostane druhou žádost o token
6. pokud ne, zašifruje tokenem všechno tajné
7. klonovací skript si ze serveru stáhne tajné věci zašifrované tokenem a nainstaluje
- slabina je v tom, že kdyby útočník uměl stroj A od sítě odstřihnout, může se za něj vydávat. Ale jak říkám: nic lepšího se mi vykoumat nepodařilo :) Pokud někdo máte návrh, jak to s rozumným úsilím a prostředky* udělat líp, sem s ním! ;)
* samozřejmě by to šlo přes nějaké TPM apod., ale to je imho ve většině "normálních" nasazení zbytečná otrava. Požadavek fyzického zabezpečení je imho realističtější, protože tak jako tak je pro běh toho systému dál potřeba...