Administrace komentářů

Ohledně PXE bootu: třeba u Debianu (a Ubuntu a spol) stačí na distribučním mirror serveru najít (naklikat) příslušný podadresář, z něj vzít soubory "linux" a "initrd.gz", a do /tftpboot/pxelinux.cfg/default přidáte něco jako

label jessie
  kernel jessie/linux
  append initrd=jessie/initrd.gz priority=low vga=normal  --

(což jsem tuším kdysi oprásknul z ISO instalačky Debianu z isolinux.cfg).

Debian netinstall bootne z initial ramdisku minimální prostředí, řekne si o cestu na distribuční server, a dál už tahá potřebné součástky přes FTP nebo HTTP do ramdisku.

Pokud máte něco s instalačkou ve formátu .ISO (image CD/DVD) tak samozřejmě i image CDčka se dá loadnout do ramdisku a bootnout, a to skrz pxelinuxova pomocníka zvaného "memdisk". Ten pak zajistí emulaci CD-ROM skrz služby BIOSu. Třeba instalačku DOSu takhle bootnete bez problému a dalšího zařizování. Problém nastane ve chvíli, kdy z toho CD nastartuje nějaký trochu schopný kernel, který kašle na služby BIOSu (Linux s CD instalátorem, NT kernel + Win32) a začne se pídit, kde má to CDčko připojeno k hardwaru. A protože kašle na INT13h BIOS services, tak ten disk nenajde.

I k tomuto problému existují workaroundy, bohužel pod Windows to každopádně znamená minimálně vsunout speciální driver do instalačního média = upravit ISO obraz, případně si hrát s WIM obrazy u moderních Windows, případně si poskládat vlastní Windows PE image... Není to špatná vychytávka, mít své vlastní PXE-bootable Windows PE s pár základními vyprošťovacími a klonovacími utilitami pro Windows

Jenom mám trochu obavu, jak bootování tlustých ISO obrazů pojede skrz VPNku - záleží, jak tlustou máte konektivitu mezi pobočkami. Nastartovat Windows PE loadnutím ISO image (desítky až stovky MB) do RAMdisku přes PXE+TFTP trvá docela dlouho i v LANce. TFTP je docela otravný protokol v tom ohledu, že tuším ACKuje každý UDP paket = visí to na latenci per-packet odezvy, tzn. na ping round tripu. V tomto ohledu má jednoznačně navrch netbootable instalátor Debianu, který si vše potřebné tahá over TCP (pomocí FTP nebo HTTP) a navíc selektivně jenom to, co potřebuje. BTW, ještě mě napadá, že gPXE/iPXE snad umí jako transport použít i FTP/HTTP... tzn. napadá mě třeba chainloadnout iPXE skrz primitivní PXE+TFTP a teprve pak rozpoutat pravé HTTP netboot inferno A i bez tohoto "dvoufázového PXE" by asi šlo zařídit, že by se do RAMdisku loadnul jenom relativně minimální image Windows PE, který by obsahoval driver nikoli pro RAMdisk, ale pro iSCSI (nebo AoE), a ten by mountnul na dálku blokové zařízení (třeba plný ISO image = instalačku) - takže by se to nemuselo tahat celé nastojato do RAMdisku. Nebo bootnout z RAMdisku PEčka s "podporou sítě" (včetně CIFS) a instalátor spustit ze síťového disku, ale to už si hodně vymejšlím a vidím v tom mnohá úskalí... každopádně na backup/restore třeba skrz gimagex to stačí. (Jenom ten PE image "se vším potřebným" je už docela tlustý.)

Jinak na "deployment" = hromadnou instalaci má Microsoft své vlastní oficiální/kanonické netbootable nástroje, dřív se to tuším jmenovalo RIS, běží to na Windows Serveru. Něco podobného bych čekal od Symantecu (modernější generace Ghostu).

...k tomu DNS pro OpenVPN remote klienty: Windowsum servíruju z OVPN "serveru" cca toto (kráceno, ale je to vlastně učebnicový příklad):

push "ip-win32 dynamic"
push "dhcp-option DNS 192.168.5.6"
push "dhcp-option DOMAIN mydomain.com"

Odhadem na OpenWRT "klientovi" bude ještě nějaká konfigurační práce s tím, aby si ty pseudo-DHCP opšny od OpenVPN klienta převzal a zapracoval ("up" script). Na druhou stranu je to myslím poměrně běžný a logický požadavek, čekal bych, že je to v OpenWRT "hotové".