#HACKUJBRNO 2024, byly zveřejněny výsledky a výstupy hackathonu města Brna nad otevřenými městskými daty, který se konal 13. a 14. dubna 2024.
Společnost Volla Systeme stojící za telefony Volla spustila na Kickstarteru kampaň na podporu tabletu Volla Tablet s Volla OS nebo Ubuntu Touch.
Společnost Boston Dynamics oznámila, že humanoidní hydraulický robot HD Atlas šel do důchodu (YouTube). Nastupuje nová vylepšená elektrická varianta (YouTube).
Desktopové prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklé sloučením projektů Razor-qt a LXDE bylo vydáno ve verzi 2.0.0. Přehled novinek v poznámkách k vydání.
Nejvyšší soud podpořil novináře Českého rozhlasu. Nařídil otevřít spor o uchovávání údajů o komunikaci (data retention). Uvedl, že stát odpovídá za porušení práva EU, pokud neprovede řádnou transpozici příslušné směrnice do vnitrostátního práva.
Minulý týden proběhl u CZ.NIC veřejný test aukcí domén. Včera bylo publikováno vyhodnocení a hlavní výstupy tohoto testu.
Byla vydána nová verze 3.5.0 svobodné implementace protokolu RDP (Remote Desktop Protocol) a RDP klienta FreeRDP. Přehled novinek v ChangeLogu. Opraveno bylo 6 bezpečnostních chyb (CVE-2024-32039, CVE-2024-32040, CVE-2024-32041, CVE-2024-32458, CVE-2024-32459 a CVE-2024-32460).
Google Chrome 124 byl prohlášen za stabilní. Nejnovější stabilní verze 124.0.6367.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 22 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Byla vydána nová verze 9.3 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Novinkou je vlastní repozitář DietPi APT.
Byl vydán Mozilla Firefox 125.0.1, první verze z nové řady 125. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vypíchnout lze podporu kodeku AV1 v Encrypted Media Extensions (EME). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 125.0.1 je již k dispozici také na Flathubu a Snapcraftu.
Princip je velmi jednoduchý. Systém není uložen na lokálním pevném disku, ale na serveru v síti, a tak všechny stanice sdílejí jeden disk s jedním systémem. Použité protokoly a služby jsou jen DHCP, TFTP a NFS, takže nic složitého.
Etherboot je program, který obsahuje ovladač pro síťovku, DHCP klienta a TFTP klienta. Roste na adrese www.rom-o-matic.net. Je možné ho získat v mnoha variantách - podle toho, odkud bude startovat. Nejdůležitější jsou asi varianty pro floppy disk, LILO/GRUB/SYSLINUX formát a PXE formát. Pro test je nejvhodnější použít obraz pro disketu, stačí ho pomocí
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
dd if=etherboot.zdsk of=/dev/fd0
nahrát na disketu a nabootovat. Později si popíšeme elegantní řešení multibootu s Windows pomocí GRUBu. Na zmíněné webové stránce je potřeba zvolit konkrétní model síťové karty, formát etherbootu podle zvoleného média a je dobré ještě otevřít rozšířené vlastnosti, kde se první políčko ptá na timeout; je vhodné nastavit -1 a timeout vypnout, aby se ihned bootovalo ze sítě bez ptaní. Možnost výběru bootování z HDD/Floppy/Sítě není v etherbootu moc dobrá, protože je čistě textová a to by dnes při snaze prosadit Linux neuspělo. A navíc mi to moc nefungovalo.
Máme tedy etherboot na disketě. Zkuste z ní nabootovat. Etherboot se musí ohlásit, najít síťovku, ukázat MAC adresu a snažit se z DHCP získat IP adresu. Pokud používáte nejrozšířenější DHCP server, tedy linuxový ISC DHCPd, je nutné stanici definovat napevno, tedy svázat MAC a IP. Jinak se bude etherboot tvářit, že DHCP server nefunguje, jakoby stále vyhledává, až skončí na timeoutu. U DHCP serveru na Windows Server 2003 toto není nezbytně nutné: pokud definujeme jméno souboru a kořenovou cestu (probereme za chvíli) jako parametry pro celý obor, etherboot adresu dostane.
Do DHCP musíme přidat 3 informace. První je adresa TFTP serveru, druhá je jméno bootovacího souboru, tedy odkud má etherboot stáhnout linuxové jádro, a poslední je NFS adresa kořenového filesystému. Ukázky vydají za tisíc slov:
host tlustoch1 {
hardware ethernet 00:01:02:B1:43:A3;
fixed-address 192.168.10.10;
next-server 192.168.10.2;
filename "/tftpboot/lts/zavadec.nbi";
option root-path "192.168.10.2:/";
}
Direktiva next-server určuje adresu TFTP serveru pro případ, že by byla odlišná od adresy brány. Filename je jméno NBI jádra a root-path je cesta, odkud si Linux připojí root filesystém. Není nezbytně nutné použít přímo / ze serveru, je možné mít v adresáři připravenou nějakou jinou distribuci.
Jako perličku k samostudiu přikládám rezervaci pro klienta používajícího PXE. Princip je stejný, jen se nejprve stáhne samotný etherboot a ten až potom stáhne NBI jádro.
host xltest {
hardware ethernet 00:04:76:9B:99:2E;
fixed-address 192.168.10.11;
next-server 192.168.1.10;
if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
filename "/tftpboot/lts/etherboot.zpxe";
} else if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
filename "/tftpboot/lts/zavadec.nbi";
}
}
Důležité jsou parametry 17, 66 a 67. Parametr 66 je analogií k next-server. Možnosti je možné definovat jak pro celý obor (ozubená kolečka), tak pro každého klienta zvlášť (ozubený počítač). Já osobně mám celý obor nastaven pro tenké klienty a tlustým klientům přenastavím parametr 17 a 67. Jestli jde pomocí Windows serveru bootovat klienty pomocí PXE, jsem nezjistil, ale podle toho, co jsem naklikal, to zřejmě nejde; nikde není k vidění možnost odesílat různá jména souborů podle toho, kdo se ptá. Případně mě prosím v diskuzi opravte, tenhle systém používám jen z donucení.
Pokud máme konfiguraci DHCP hotovou, etherboot musí dostat z DHCP IP adresu a začít pomocí TFTP stahovat soubor, což se mu ze zjevných příčin zatím nepodaří.
TFTP je věc vcelku jednoduchá. Je potřeba mít TFTP server nainstalovaný a spustit:
in.tftpd -l /tftpboot/lts/ -r blksize
Uvedená cesta definuje adresář, ze kterého lze stahovat soubory. Vzhledem k absenci jakékoliv bezpečnosti u TFTP nedávejte do adresáře zbytečnosti. V konfiguraci DHCP ale musí být absolutní cesta, tedy včetně /tftpboot/lts/. Parametrem -r lze zapnout různé workaroundy pro bugovité implementace TFTP klienta. To sice není problém etherbootu, ale zůstalo mi to tam po testech PXE se síťovkami od Intelu a 3comu.
Zde se již dostáváme k distribučně závislým věcem. Já jedu na Arch Linuxu a jedno z přání při implementaci tlustých klientů bylo použití distribučního jádra bez jakýchkoliv úprav. Jádro z Archu splnilo mé požadavky na výbornou. Neručím tedy za to, že to bude fungovat i s výchozími jádry jiných distribucí. Jak jsem již předeslal, NBI jádro je vlastně běžné linuxové jádro slepené s initramdiskem. Nejprve si tedy vyrobíme initramdisk tak, aby obsahoval ovladače pro všechen možný hardware.
Konfigurace pro mkinitcpio - mkinitcpio-kernel26.conf:
MODULES="" FILES="" HOOKS="base net udev ide scsi sata usbinput raid filesystems"
A initramdisk vytvoříme:
mkinitcpio -c mkinitcpio-kernel26.conf -g init.cpio.gz
Jádro použijeme výchozí z distribuce, tedy /boot/vmlinuz26 a výsledné NBI jádro nasypeme rovnou, kam patří. NBI jádro vytvoříme tímto příkazem:
mkelf-linux /boot/vmlinuz26 init.cpio.gz \ --append="ip=:::::eth0:dhcp vga=773 quiet" \ --output=/tftpboot/lts/zavadec.nbi
Soubor init.cpio.gz můžeme teď klidně smazat. Vysvětlení určitě zaslouží direktiva --append. Především říká jádru, že si má nakonfigurovat síťovku eth0 pomocí dhcp. Zárověň to implikuje snahu o připojení kořenového filesystému přes NFS. Že jádro použije mód s vyšším rozlišením a při bootu nebude ukecané, jsou už věci vcelku podružné. K dalšímu studiu doporučuji soubor /usr/src/linux/Documentation/nfsroot.txt.
V tuto chvíli by mělo jádro na klientech startovat, získat IP adresu (konfigurace se vypíše na monitor) a snažit se připojit kořenový filesystém přes NFS, na čemž dojede. Pokud tedy nedojede poněkud dříve, můžeme přikročit ke konfiguraci NFS.
O připojování NFS oddílů jsem již něco napsal v prvním dílu seriálu o NIS+NFS, takže jen stručně. U tlustých klientů je nesmírně důležitá rychlost komunikace mezi klientem a serverem, protože pomalý disk je katastrofa a pomalé NFS je katastrofa ještě horší.
/etc/exports:
/ 192.168.0.0/255.255.0.0(rw,no_root_squash,sync,subtree_check)
9 z 10 zarytých linuxáků se nyní musí ježit vlasy hrůzou na hlavě a ježí se správně. Pokud by si někdo do sítě připojil počítač s vlastním rootem a připojil se na naše NFS, má roota i na serveru. Pokud pomineme omezení na hardwarové úrovni, tak správným řešením je jednak omezit povolené IP adresy na co nejmenší rozsah, (případně nesdílet kořenový oddíl serveru, ale mít distribuci v adresáři a sdílet ten), squashovat roota a v této distribuci mít roota s UID 65535. Nedokážu si představit, co by se dělo, kdyby se démony pod rootem na stanici nemohly dostat ke svým datům na serveru. Potenciální útočník bude moci zkompromitovat distribuci v adresáři, ale ne hlavní systém. Je možné také adresář nasdílet jen pro čtení, ale to by vyřešilo z části jeden problém a přineslo jiné. Nápady na zabezpečení jsou vítány.
S NFS sice nejsme moc spokojeni, ale funguje. V tuto chvíli by měla již distribuce nabootovat až k loginu, i když je možné, že to během bootu zakřičí několik chyb. To proto, že se teď 2 instance téhož systému perou o adresáře /var/run apod. Jedna na serveru a druhá na klientu. Proto přichází na scénu sada skriptů s názvem ThickScripts.
Obecně platí, že každý linuxový systém musí mít adresář /var připojen i pro zápis a nemůže být sdílený. Toto pravidlo není nutné, ba ani vhodné aplikovat na celý /var, ale jen na některé podadresáře, např /var/log, /var/run atd. Nabízejí se 2 řešení. Jednak můžeme mít soubor obsahující filesystém a ten mít extra pro každou stanici a vždy si ho připojit, nebo použít ramdisk a vždy při startu systému v ramdisku vytvořit potřebnou adresářovou strukturu. Já jsem zvolil řešení s ramdiskem. Výhodou je jednodušší implementace, nevýhodou zase to, že vše v ramdisku se při vypnutí ztratí - ale mrzet by nás mohly leda tak logy. ThickScripts vytvoří ramdisk v adresáři /thickramdisk, uvnitř připraví adresářovou strukturu a jednotlivé adresáře se bindují na svá místa ve /var, kde přebijí sdílené adresáře ze serveru.
Další důležité věci, které ThickScripts řeší, je např. pokus o nalezení SWAP oddílu na HDD a jeho připojení, zkopírování správného xorg.conf do /etc/X11/, nastavení hostname na tvar 192-168-22-33, nastavení zvuku, atd.
ThickScripts v principu není nic jiného než několik málo bashových skriptů. Jako první se zavádí skript all. V něm je právě již zmíněné vytvoření ramdisku, připojení SWAPu atd. Následuje zjištění IP adresy klienta a pokus o nalezení skriptu, který je pojmenován stejně jako zjištěná IP adresa. Pokud ho najde, tak ho spustí. Pokud ho nenajde, spustí skript s názvem default. Já tyto skripty spouštím i na serveru; mám tím zaručené jednotné prostředí a jistotu, že to funguje.
Jak jsem již předeslal, používám distribuci Arch Linux, tak je ThickScripts postaven pro Arch. Ale po drobných úpravách není problém to spustit i na jakékoliv jiné distribuci. Distribučně závislé jsou v podstatě 2 věci. Jednak prvotní skript thickscripts, který je v adresáři /etc/rc.d a chová se jako služba. Systém ho spustí hned po inicializaci sítě. Tam jsou příkazy stat_busy a stat_done, která zajistí obarvení výstupu dle zvyklostí distribuce. Lze je klidně vypustit, stejně tak jako includování konfiguračních souborů Arch Linuxu.
/etc/rc.conf:
... # - prefix a daemon with a @ to start it up in the background # DAEMONS=(syslog-ng network thickscripts portmap ... # End of file ...
/etc/rc.d/thickscripts:
#!/bin/bash
. /etc/rc.conf #arch-specific
. /etc/rc.d/functions #arch-specific
TSPATH="/thickscripts"
case "$1" in
start)
stat_busy "Starting ThickScripts" #arch-specific
echo "ThickScripts: loadings system settings for all hosts"
$TSPATH/all
echo "done"
echo
IP=`ip a s eth0 | grep -m 1 "inet " | cut -d " " -f 6 | cut -d / -f 1`
if [ -f $TSPATH/$IP ]; then
echo "ThickScripts: loading system settings for $IP"
$TSPATH/$IP
else
echo "ThickScripts: system settings for $IP not found, using defaults"
$TSPATH/default
fi
echo "done"
stat_done #arch-specific
;;
stop)
stat_busy "Stopping ThickScripts" #arch-specific
echo "Nothing to stop..."
stat_done #arch-specific
;;
*)
echo "usage: $0 {start|stop}"
esac
exit 0
Druhá distribučně závislá věc je samotný skript all, protože tam je nutné vypsat jaké adresáře se budou připojovat z ramdisku. Pokud si nainstalujete nějaký program a ten bude vyžadovat adresář /var/log/program, je nutné provést změnu v tomto skriptu.
/thickscripts/all:
#!/bin/bash
#do not remove this entry, only edit, please
TSPATH="/thickscripts"
RAMDISK="/thickramdisk"
swapdsk=`fdisk -l | grep -m 1 "Linux swap" | cut -d " " -f 1`
if [ ! $swapdsk == "" ]; then
echo "Activating swap $swapdsk"
/sbin/swapon $swapdsk
fi
IP=`ip a s eth0 | grep -m 1 "inet " | cut -d " " -f 6 | \
cut -d / -f 1 | sed 's/\./-/g'`
hostname $IP
mkdir -p $RAMDISK
mount -t tmpfs none $RAMDISK
cp -f $TSPATH/xorg.conf-default $RAMDISK/xorg.conf
rm -f /etc/X11/xorg.conf
ln $RAMDISK/xorg.conf /etc/X11/xorg.conf -s
mkdir -p $RAMDISK/var/run/
mount -o bind $RAMDISK/var/run/ /var/run/
mkdir /var/run/avahi-daemon
mkdir /var/run/cups
...
...
Nakonec se spustí skript s názvem jako IP adresa, případně skript default. Zde je příklad. Za zmínku stojí nastavení konfiguračního souboru xorg.conf. Skript all vezme výchozí konfigurační soubor (měl by tak nějak fungovat všude) a pod jménem xorg.conf ho nakopíruje do ramdisku, smaže soubor nebo symlink v /etc/X11/ a z tohoto adresáře udělá symlink na právě zkopírovaný soubor. Pokud chceme použít jinou než výchozí konfiguraci, stačí přepsat soubor v ramdisku. Jelikož symlink vede do lokálního ramdisku, není třeba se obávat restartu X na klientovi, použije se vždy správný soubor.
/thickscripts/192.168.3.19:
#!/bin/bash #do not remove this entry, only edit, please TSPATH="/thickscripts" RAMDISK="/thickramdisk" # ### ---insert your own rules bellow this line--- ### /sbin/modprobe floppy cp -f $TSPATH/xorg.conf-nv $RAMDISK/xorg.conf
Domovskou stránku projekt nemá. Balík ThickScripts je ve stavu, jak teď funguje (čili včetně konfigurace mých klientů), ke stažení zde: thickscripts.tar.bz2.
Systém funguje, ale má jednu zásadní nevýhodu, bootuje pořád z diskety, což není vždy ideální; navíc u tlustých klientů lze disketovku normálně používat. Bohužel ve školním prostředí bychom asi tvrdě narazili na nepochopení z řad vedení, kdyby na počítačích nebyl systém Windows, proto nakonfigurujeme multiboot. Přítomnost harddisku v počítači je výhoda, mimo jiné na něm můžeme mít SWAP. Při instalaci Windows stačí myslet a nechat na disku 500 MB volných.
Já jsem si modifikoval SLAX Linux na CD, přidal jsem oficiální balíček s Grubem a ještě vytvořil vlastní balíček, ve kterém byl /boot/grub z Arch Linuxu, včetně konfiguračního souboru. Ten byl pozměněný, aby primárně startoval Windows a na druhém místě byl Linux. Timeout jsem zvolil 20 sekund. Etherboot se startuje stejně jako linuxové jádro, jen nemá žádné parametry ani initramdisk. Po běžné instalaci Windows jsem tedy nabootoval SLAX, s pomocí skriptu vytvořil 50MB ext2 oddíl a zbytek jako swap. Typicky hda1 - Win, hda2 - ext2 a hda3 - swap. Na ext2 oddíl jsem pak nakopíroval /boot/grub a do /boot nakopíroval etherboot. Nezapomeňte, že etherboot musí být vytvořen jako LILO/GRUB/SYSLINUX typ a pro síťovku, která je zrovna v počítači. Nakonec stačilo:
grub-install --root-directory=/mnt/hda2 /dev/hda
Modul pro SLAX obsahující etherboot pro "3c90x" a "tulip" mohu poskytnout. Jinak stačí využít linux-live, kde jsou skripty pro převod adresáře na SLAX balíček a opačně.
Skript pro zjednodušení instalace:
umount /mnt/hda* echo "hda2 - Linux" echo "hda3 - Linux swap" fdisk /dev/hda mke2fs /dev/hda2 mkswap -v1 /dev/hda3 mkdir /mnt/hda2 mount /dev/hda2 /mnt/hda2 mkdir /mnt/hda2/boot mc
V současné chvíli se distribuce ze serveru duplikuje na klienty, ale to v řadě případů nestačí. Museli bychom mít uživatele na serveru, což sice můžeme, ale lze použít i NIS+NFS popsané v odkazovaném seriálu. Prima věc je, že pokud to rozjedeme na serveru, ypbind a připojení /home se bez práce provede i na klientech - ale nezapomeňte, že od teď se na hlavní server bude připojovat ne jeden klient, ale celá řada. Tentýž server lze zároveň použít jako LTSP server a v podstatě bezpracně zlinuxovat jak učebnu se starými počítači, tak i novou od Indoše, což je typická situace na řadě škol.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
PS uznavám, že to bije do očí
).
3.4.2007 21:13
xxx | skóre: 42
| blog: Na Kafíčko
Jj souhlasim. Jakmile ma clovek jednou uzivatele v ldapu, je dobre velmi rychle zapomenout na vsechy ty groupadd atp. Ty totiz pracuji primo se soubory v /etc. Ja si nakonec zvykl na praci s webovym phpldapadminem. Dalsi moznosti je napsat si nejake vlastni skripty.
Co se tyce passwd. Tak to funguje. Pokud je ale potreba pomoci passwd menit hesla jinym uzivatelum, je nutne v nastaveni LDAP modulu pro PAM, rict, aby se root bindoval s jinou "identitou" a to s takovou, ktera ma pristup k posixPasswordu ostatnich useru. Normalne je user bindlej jako on sam, tudiz smi menit jen sam sebe.
Jinak LDAP je hezkej, ale obcas je to velkej boj s nastavenim. Hlavne s pravama
2.4.2007 11:41
m$ lipo $m | skóre: 19
| blog: čaj o páté
| Redmond
2.4.2007 18:23
freshmouse | skóre: 42
| blog: Bruno Banány
< / žádný flame>
Když použijeme NFS pro připojení celého /home adresáře, má to jednu zásadní chybu: adresář se připojí ještě před tím, než se někdo k počítači vůbec přihlásí, navíc jsou připojeny (a potenciálně přístupné) adresáře všech uživatelů, ne jen toho jednoho, který s počítačem bude pracovat. To je IMHO architektonicky špatně a je to velká bezpečnostní mezera* Server neví, kdo u počítače (klienta) sedí, prostě jen slepě poskytuje data a věří klientskému počítači, že se o autorizaci postaral.
Za správné bych považoval to, že by se nepřipojoval celý /home, ale pouze adresář jednoho konkrétního uživatele, a to na základě jeho jména a hesla. Jenže když si domácí adresář bude připojovat sám uživatel, musí být přihlášený, jenže háček je v tom, že ve chvíli kdy je přihlášený, už musí být domácí adresář dostupný, tedy připojený.
Chtělo by to tedy, aby se po zadání jména a hesla v GDM/KDM připojil domácí adresář daného uživatele a potom mohlo naběhnout uživatelovo oblíbené KDE/Gnome.
Napadá mne použít SSHFS pro připojení ~/ Používám ho třeba pro on-line editaci www stránek a je to docela použitelné. Výkonnostně je to někde jinde než NFS nebo SAMBA, ale bezpečnostně taky Navíc "velká data" by si mohl uživatel zpracovávat na nějakém lokálním disku a až nakonec je nahrát do svého síťového domácího adresáře. Pro ty ostatní věci (nastavení programů, textové dokumenty...) by i tenhle FS měl stačit.
Takže pár otázek nakonec: Je SSHFS příliš pomalý nebo by šel použít? Víte o něčem lepším? Jak nacpat skript pro připojení disku mezi správce přihlášení a start KDE/Gnome (skript musí mít k dispozici heslo uživatele)? Neexistuje už nějaké hotové řešení tohohle všeho?
*) asi řeknete, že se mají počítače zabezpečit fyzicky, nebo že NFS serveru má být povolený přístup jen z některých IP adres. Ale to je podobně děravé řešení, jako když ve windows šlo shodit zaheslovaný spořič obrazovky vložením zvláštního CD.
2.4.2007 22:49
2.4.2007 23:52