Disklessová pracovní stanice
Výsledný operační systém disklessové pracovní stanice je výsledkem sloučení několika vrstev do jednoho sendviče.
Anatomie vrstev
Především si musíme si uvědomit že pořadí, v jakém se vrstvy sestaví do sendvičeChybná citace: Chyba v tagu <ref>
; citace bez názvu musí mít vlastní obsah, je důležité.
Specifika sendviče překrytého overlayem
Lokální kešování
/etc/fstab
Soubor /etc/fstab
nemá žádný obsah, protože full-diskless ke své existenci lokální blokové zařízení nepotřebuje a připojení tmpfs na adresář /tmp
je zbytečné, protože stejně všechno překrývá overlay, který už v paměti je.
Připojení tmpfs
U disklessového stroje který nemá overlay, se pracuje přímo s obsahem adresáře nasdíleného z NFS serveru – např. disklessové servery. V takovém případě je naopak vysoce žádoucí tmpfs na adresář /tmp připojit – bez toho by se dočasně vytvořené soubory zbytečně honily po síti sem a tam a zatěžovaly NFS server (zamykání, odemykání, rušení, …). V takovém případě se hodí do souboru /etc/fstab
přidat následující řádek:
tmpfs /tmp tmpfs nodev,nosuid 0 0
Do adresáře /tmp
může zapisovat každý. Parametry nosuid a nodev zabra%nují jeho případnému zneužití. Pokud by do něj někdo nakopíroval upravenou aplikaci, která má nastaven tzv. suid bit, tak byl získal práva uživatele root. Parametr nodev pro změnu zabraňuje v tom, aby by si zde někdo vytvořil internetový soket, nebo jiné zařízení, přes které by mohl škodit. Bylo by možné použít ještě parametr noexec, který by způsobil, že by soubor nakopírovaný do tohoto adresáře nešel spustit, ale to už je možná v prostředí laboratorního disklessu příliš restriktivní, protože se stejně veškerý obsah RAM při restartu zahazuje.
Připojení lokálního diskového oddílu
Nicméně se za určitých okolností je připojení lokálního blokového zařízení potřeba. Kupř. u half-disklessových serverů, co startují kompletně z NFS, bez komunikace s DHCP je na virtuálním blokovém zařízení umístěn GRUB s linuxovým jádrem včetně ramdisku a pokud chceme, nebo potřebujeme udělat jeho aktualizaci, potřebujeme, aby byl jeho obsah dostupný.
Jsou to virtuály, do kterých se propaguje virtuální disk jako blokové zařízení /dev/sda
. Protože firmware QEMU při zavádění nepočítá s UEFI, je zbytečné aby na něm byla GPT tabulka a víc než jeden diskový oddíl. Navíc jde o velmi malý virtuální disk, bohatě stačí max. velikost kolem 200MB, proto je na něm MS-DOS tabulka, s jedním primárním diskovým oddílem, formátovaným na ext4. GRUB se instaluje do MBR sektoru, a na jeho přečtení diskového oddílu mu stačí relativně malé moduly part_msdos a ext2.
LABEL=boot /boot ext4 noauto 0 0
Parametr noauto v tomto případě preventivně brání neúmyslnému poškození ramdisku. Pokud chceme hrabat na konfigurační soubor grub.cfg
, nebo aktualizovat ramdisk, musíme si tento virtuální disk na adresář /boot
připojit.
Je lepší mountovat zařízení přes návěští souborového systému (LABEL) než přes cestu k blokovému zařízení, protože tím pádem nemusíme řešit další bloková zařízení ani jiné diskové oddíly. |
V laboratořích Katedry kybernetiky se – na rozdíl od laboratoří Katedry řídící techniky – lokálně instalované MS Windows nepoužívají. Ale diskless SSD disky s nimiž byly stroje dodány využívá automaticky, pokud na nich najde swapovací oddíl.
Kromě toho se ale využívají také jako lokální úložiště pro velké soubory virtuálních strojů, s nimiž se pracuje přes VMWare. Proto /etc/fstab
u laboratorního disklessu Katedry kybernetiky obsahuje následující záznam:
LABEL=local /local ext4 defaults,noauto,users 0 2
Pokud diskless, na lokálním disku stroje kde byl spuštěn, nalezne diskový oddíl formátovaný na ext4 s názvem 'local', tak ho má přihlášený uživatel možnost připojit. Aby se o to nesnažil automaticky je uvedena volba noauto – bez ní by totiž zůstal při zavádění systém viset v ramdisku, pokud by takový diskový oddíl na stroji při startu nenašel.
A bez volby users, by to mohl pro změnu udělat pouze uživatel root
.
Přihlašování uživatelů
Základní rozdíl mezi disklessovými pracovními stanicemi katedry DCE (Katedra řídící techniky) a DC (Katedra kybernetiky) je ve způsobu ověřování uživatelů. Zatím co stroje DCE jsou opřené o ČVUT AD (které spravuje VIC), laboratorní stroje DC jsou opřeny o laboratorní LDAP server.
Ověřovací proces sestává z několika fází:
Získání UID
Během první fáze se systém pokusí na základě uživatelského jména získat UID uživatele.
Stará se o to nslcd démon, který při tom postupuje podle nastavení v souboru /etc/nsswitch.conf
:
passwd: compat ldap systemd group: compat ldap systemd
To říká, že nejprve se má podívat do lokálního souboru /etc/passwd
(resp. /etc/groups
), a teprve pokud v něm uživatelské jméno (skupinu) nenajde, má zkusit ldap.
Lokální uživatelé
U disklessových strojů s overlayem je doporučeno mít k dispozici minimálně dva lokální uživatele:
- root
- Lokální administrátor. Změny v jeho domovském adresáři /root se ukládají pouze na tmpfs v RAM, tzn. že se při restartu zahodí. Zůstane jen to co je v podkladové vrstvě – ssh klíče a soubor authorized_keys s naimportovaným veřejným klíčem, aby bylo možné mezi stanicemi procházet přes SSH. Pozor na sudo! I když je to pouze lokální administrátor, jehož UID je na NFS serveru squashovaný, není žádoucí, aby se na něj mohl dostat každý uživatel.
- guest
- Je lokální uživatel, s jednoduchým heslem a zcela prázdným domovským adresářem, který je mimo standardní adresář
/home
. Používá se pouze k dočasnému přihlášení a veškeré změny jsou uloženy pouze v paměti a tudíž se po restartu zahodí. - guest00 – guest??
- Kromě výše uvedených uživatelů lze použít také lokální uživatelé guest00 až guest?? (otazníky zastupují čísla, záleží totiž na tom, kolik je potřeba účtů). Od uživatele guest se tyto účty liší tím, že se jejich domovský adresář mountuje z NFS serveru – stejně jako domovské adresáře uživatelů ověřených přes LDAP či AD.
- Využívají se pouze při různých vícedenních kurzech, pro uživatele co nemají řádný účet ČVUT a potřebují aby jim vytvořené soubory zůstaly zachovány i po restartu pro další dny. Tyto uživatelské účty jsou nevhodné, pokud potřebujete zpracovávat citlivá data – např. přistupovat na svůj účet v bance atp. – v takovém případě použijte raději uživatele guest, u kterého je jistota, že se veškerá data při restartu zahodí.
- Tyto adresáře se také čas od času z NFS serveru odstraňují.
Uživatelé z LDAPu (AD)
Jednoduché ověření, zda-li je uživatel znám, lze při nakonfigurovaném LDAPu provést pomocí příkazu id:
# id neznamy id: 'neznamy': no such user # id guest uid=1000(guest) gid=1000(guest) groups=1000(guest) # id znamyuser uid=32911(znamyuser) gid=32911(znamyuser) groups=1000(guest),1003(stud),32911(znamyuser)
Pokud se při ověření uživatele 'znamyuser' objeví stejná chybová z práva jako v případě id 'neznamy', pak to znamená, že:
- buď není v LDAPu
- nebo není LDAP správně nakonfigurován
- nebo z nějakého důvodu přístup na LDAP nefunguje
Nastavení LDAPu na DC
Je třeba nainstalovat instalační balík nslcd
a buď v dialogu při instalaci, nebo následně v souboru /etc/nslcd.conf
nastavit výchozí URL k LDAP serveru:
uri ldap://<ldap>.felk.cvut.cz
a výchozí bázi, aby se UID vyhledávalo ve správném kontextu:
base dc=<ldap>,dc=felk,dc=cvut,dc=c
Všechny ostatní volby lze zakomentovat. S výjimkou jediné:
tls_reqcert never
Místo řetězce <ldap> se uvádí hostname LDAP serveru, vůči kterému je stroj opřený
|
Nastavení ČVUT AD na DCE
Active Directory (AD) je implementace LDAP serveru od fy. Microsoft. Nastavuje se tudíž obdobně jako LDAP na DC. Zásadní rozdíl je ale v použitém schématu.
Zatím co LDAP server na DC používá jednoduché schéma, které nabízí UID uživatele prakticky hned na první úrovni (jako hodnotu atributu … ). Je schéma ČVUT AD komplikované. Proto je komplikovaný i konfigurační soubor /etc/nslcd.conf
:
uid nslcd gid nslcd uri ldaps://ms.cvut.cz base ou=IDM,dc=ms,dc=cvut,dc=cz binddn <agent>@cvut.cz bindpw <heslo> filter passwd (&(objectClass=user)(uidNumber=*)) map passwd gidNumber "10000" map passwd homeDirectory "${homeDirectory:-/home/$uid}" map passwd loginShell "${loginShell:-/bin/bash}" # SSL options ssl on tls_reqcert never tls_cacertfile /etc/ssl/certs/ca-certificates.crt scope sub
Je to dáno tím, že ČVUT AD (které spravuje VIC) zahrnuje veškeré uživatele a organizační složky ČVUT a navíc bylo primárně vytvořeno k ověřování strojů s OS MS Windows. Proto je připojení na server ms.cvut.cz šifrované přes SSL (Volba ssl on
a ldaps://
v uri), a vyhrazené pouze pro agenta, jehož uživatelské jméno <agent>@cvut.cz
a heslo <heslo>
musí být součástí tohoto konfiguračního souboru.
Kromě toho se využívá pro ověření komunikace ještě řetězec certifikátů v souboru /etc/ssl/certs/ca-certificates.crt
Ověření uživatele
Ověření zajišťují PAM moduly, na základě konfiguračních souborů v adresáři /etc/pam.d
. Konfigurační soubory v tomto adresáři by se ale nikdy neměly editovat přímo, protože se generují na základě konfiguračních souborů v adresáři /usr/share/pam-configs
pomocí utility pam-auth-update.
Tyto konfigurační soubory se instalují zároveň s příslušnými PAM moduly:
- capability
- gnome-keyring
- krb5
- ldap
- mkhomedir : zbytečný?
- pam_script
- systemd
- unix
Až na jednu výjimku je můžeme nechat na pokoji. Tou výjimkou je pam_script
.
Původní obsah souboru:
Name: Support for authentication by external scripts Default: yes Priority: 257 Auth-Type: Primary Auth: sufficient pam_script.so Account-Type: Primary Account: sufficient pam_script.so Password-Type: Primary Password: sufficient pam_script.so Session-Type: Additional Session: optional pam_script.so
Nahradíme tímto:
Name: Support for authentication by external scripts Default: yes Priority: 10 Session-Interactive-Only: yes Session-Type: Additional Session: optional pam_script.so dir=/etc/pam-scripts
Prakticky vše, s výjimkou posledních třech řádků můžeme s klidnou duší vyhodit, protože chceme skripty z adresáře /etc/pam-scripts
volat pouze při zahájení a ukončení interaktivní session. Důležitá je také priorita. Volané skripty totiž provádějí operace, které musí proběhnout ihned poté, co dojde k úspěšnému ověření uživatele.
Menu
~/.config/menus/xfce-applications.menu
Odkud se berou položky v menu?
$ env | grep XDG_CONFIG_DIRS