Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Pro účely testování vytvoříme nový server srv-file1.firma.local, který bude plnit roli souborového serveru na bázi NFS4. Základem konfigurace tohoto stroje bude stejná konfigurace klienta našeho Kerberos/LDAP řešení jako u strojů pc1.firma.local a srv-hpc1.firma.local v předchozích dílech tohoto seriálu.
Než začneme s NFS4 experimentovat, ověříme, zda jej náš systém vůbec podporuje.
[root@srv-file1 ~]# mount
...
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
Pokud vaše distribuce NFS4 "bezbolestně" podporuje, měly by být tyto souborové systémy přimountovány automaticky bez uvedení v /etc/fstab
(některé starší návody na Internetu tuto "ruční práci" uvádějí). Souborový systém nfsd slouží pro ovládání démona nfsd
. Komunikace mezi jaderným modulem a démony běžícími v uživatelském prostoru probíhá přes souborový systém rpc_pipefs.
Protože jsme zatím nezapojili DNS, opět musíme vyřešit překlad jmen a IP adres lokálně.
# Soubor /etc/hosts na stroji srv-file1.firma.local
127.0.0.1 localhost.localdomain localhost
172.16.51.10 srv-infra1.firma.local srv-infra1
172.16.51.12 srv-file1.firma.local srv-file1
[root@srv-file1 ~]# urpmi krb5-workstation
[root@srv-file1 ~]# urpmi nss_ldap
[root@srv-file1 ~]# urpmi nfs-utils-clients
[root@srv-file1 ~]# urpmi nfs-utils
I souborový server potřebuje znát informace o uživatelích z našeho LDAP. Nejdůležitější jsou samozřejmě informace o UID, GID a členství ve skupinách. Konfigurace stroje je z pohledu LDAP naprosto stejná jako v předchozích případech. Následující konfigurační soubory uvádím pouze pro úplnost.
[root@srv-file1 ~]# cat /etc/nsswitch.conf
# Soubor /etc/nsswitch.conf na stroji srv-file1.firma.local
passwd: files ldap
shadow: files
group: files ldap
...
# Soubor /etc/ldap.conf na stroji srv-file1.firma.local
host srv-infra1.firma.local
base dc=firma,dc=local
Určitě nic nezkazíme, když si zkontrolujeme, zda souborový server účty v LDAPu vidí.
[root@srv-file1 etc]# getent passwd
...
frantisek_hnipirdo:*:10001:20001:Frantisek Hnipirdo:/home/frantisek_hnipirdo:/bin/bash
josef_vosahlo:*:10002:20001:Josef Vosahlo:/home/josef_vosahlo:/bin/bash
[root@srv-file1 etc]# getent group
...
firma_users:*:20001:frantisek_hnipirdo,josef_vosahlo
vyroba:*:20003:frantisek_hnipirdo
finance:*:20002:josef_vosahlo
Základní konfigurace souborového serveru jako Kerberos klienta je opět zcela stejná jako v předchozích případech.
# Soubor /etc/krb5.conf na stroji srv-file1.firma.local [realms] FIRMA.LOCAL = { kdc = srv-infra1.firma.local:88 admin_server = srv-infra1.firma.local:749 default_domain = firma.local } [domain_realm] .firma.local = FIRMA.LOCAL firma.local = FIRMA.LOCAL [libdefaults] default_realm = FIRMA.LOCAL dns_lookup_realm = false dns_lookup_kdc = false forwardable = yes [logging] default = FILE:/var/log/kerberos/krb5libs.log
Tím to však nekončí. Služba NFS bude pro svůj provoz potřebovat principal. Ten vytvoříme, jako obvykle, pomocí nástroje kadmin
.
[root@srv-file1 ~]# kadmin -p krbadmin/admin
Couldn't open log file /var/log/kerberos/krb5libs.log: No such file or directory
Authenticating as principal krbadmin/admin with password.
Password for krbadmin/admin@FIRMA.LOCAL:
kadmin:
Vytvoříme principal nfs/srv-file1.firma.local@FIRMA.LOCAL
s náhodným klíčem.
kadmin: addprinc -randkey nfs/srv-file1.firma.local@FIRMA.LOCAL
WARNING: no policy specified for nfs/srv-file1.firma.local@FIRMA.LOCAL; defaulting to no policy
Principal "nfs/srv-file1.firma.local@FIRMA.LOCAL" created.
Klíč tohoto principalu vyexportujeme do systémového keytabu na souborovém serveru...
kadmin: ktadd nfs/srv-file1.firma.local@FIRMA.LOCAL
Entry for principal nfs/srv-file1.firma.local@FIRMA.LOCAL with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab
WRFILE:/etc/krb5.keytab.
Entry for principal nfs/srv-file1.firma.local@FIRMA.LOCAL with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab
WRFILE:/etc/krb5.keytab.
...a obsah systémového keytabu pro jistotu ověříme.
[root@srv-file1 ~]# klist -ke /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 4 nfs/srv-file1.firma.local@FIRMA.LOCAL (Triple DES cbc mode with HMAC/sha1) 4 nfs/srv-file1.firma.local@FIRMA.LOCAL (DES cbc mode with CRC-32)
V návodech na Internetu se můžeme setkat s exportováním pouze klíče pro šifrování des-cbc-crc
. Stávající implementace NFS4 v Linuxu ani jiné typy šifrování nepodporuje. Nemusíme si dělat hlavu, máme-li v keytabu o nějaký ten klíč navíc.
NFS4 přichází s něčím, čemu se říká pseudo filesystem. Všechny exportované (sdílené) adresáře jsou pro klienta viditelné pod jedním kořenovým adresářem (fsid=0). My na našem testovacím serveru budeme pro klienty exportovat adresář /nfs4exports
jako kořen pseudo filesystému. Vytvoříme v něm adresář data
, který bude obsahovat adresářovou strukturu odpovídající organizační struktuře fiktivní firmy. Protože nechceme, aby zvědaví uživatelé "lezli" do adresářů jiných útvarů, nastavíme příslušná oprávnění. V praxi by zřejmě bylo vhodnější použít ACL.
V návodech dostupných na Internetu je zhusta využíván postup, ve kterém jsou další souborové systémy exportovány tak, že se pomocí příkazu mount --bind ...
připojí do adresáře podřízeného kořeni pseudo filesystému. Z důvodu jednoduchosti se nyní tomuto postupu raději vyhnu. Pokud budete tento postup používat, nezapomeňte na direktivu nohide
, jako se to stalo mě. Tomu, co následovalo, jsem se nestačil divit.
[root@srv-file1 ~]# mkdir -m 755 /nfs4exports
[root@srv-file1 ~]# mkdir -m 755 /nfs4exports/data
[root@srv-file1 ~]# mkdir -m 2770 /nfs4exports/data/vyroba
[root@srv-file1 ~]# chown root.vyroba /nfs4exports/data/vyroba
[root@srv-file1 ~]# mkdir -m 2770 /nfs4exports/data/finance
[root@srv-file1 ~]# chown root.finance /nfs4exports/data/finance
[root@srv-file1 ~]# ls -l /nfs4exports/data/
celkem 2
drwxrws--- 2 root finance 1024 kvě 12 22:34 finance/
drwxrws--- 2 root vyroba 1024 kvě 12 22:32 vyroba/
Adresář /nfs4exports
vyexportujeme pro klienty konfigurací v souboru /etc/exports
. Pro autorizaci přístupu k adresáři bude vyžadována autentizace Kerberem, což udává direktiva gss/krb5
.
# Soubor /etc/exports na stroji srv-file1.firma.local
/nfs4exports gss/krb5(fsid=0,rw,insecure,no_subtree_check)
Místo gss/krb5
můžeme použít gss/krb5i
nebo gss/krb5p
. Pokud použijeme gss/krb5i
, bude kontrolována integrita přenášených dat. Použijeme-li gss/krb5p
, budou přenášená data navíc šifrována. V mém případě gss/krb5p
nefungovalo a pokud je mi známo, tak šifrování v Linuxu podporováno zatím není.
Na rozdíl od předchozích verzí NFS, které používaly samostatné protokoly pro "mountování" a zamykání souborů, NFS4 řeší tyto operace přímo uvnitř NFS4 protokolu. Změnila se tedy standardní sada démonů, které pro provoz potřebujeme.
nfsd.o
, démon rpc.nfsd spouští příslušný počet kernelových vláken. Tohoto démona tedy spouštíme pouze na serveru.uživatel@doména
, která jsou pomocí tohoto démona mapována na lokální UID a GID. Démon musí běžet jak na straně serveru, tak na straně klienta.Startovací skript /etc/init.d/nfs
je univerzální jak pro NFS4, tak pro NFS3, tudíž startuje i démony portmap
, rpc.lockd
a rpc.mountd
, které pro NFS4 (údajně) nepotřebujeme. Faktem je, že bez bežícího portmaperu se mi nfsd
nepodařilo spustit. To je zřejmě způsobeno tím, že nfsd
slouží jak pro NFS4, tak pro NFS3, které portmaper vyžaduje.
V souboru /etc/sysconfig/nfs
nastavíme, aby startovací skript /etc/init.d/nfs
automaticky startoval démona rpc.idmapd
volbou USE_NFS4=yes
a démona rpc.svcgssd
volbou SECURE_NFS=yes
. Volba SECURE_NFS_MODS="rpcsec_gss_krb5"
zajistí automatické natažení nezbytného jaderného modulu.
# Soubor /etc/sysconfig/nfs na stroji srv-file1.firma.local
..
USE_NFS4=yes
SECURE_NFS=yes
SECURE_NFS_MODS="rpcsec_gss_krb5"
RPCGSSD_OPTIONS="-m"
RPCIDMAPD_OPTIONS=""
RPCSVCGSSD_OPTIONS=""
Ověříme, že existuje soubor /etc/gssapi_mech.conf
s následujícím obsahem. Soubor je obvykle přítomen. V mojí distribuci (Mandriva Linux 2007.1) je součástí balíku nfs-utils-clients
.
# Soubor /etc/gssapi_mech.conf na stroji srv-file1.firma.local
...
/usr/lib/libgssapi_krb5.so.2 mechglue_internal_krb5_init
...
Démona rpc.idmap
nastavíme v souboru /etc/idmap.conf
. Nastavit je třeba zejména doménu (Domain = firma.local
).
# Soubor /etc/idmap.conf na stroji srv-file1.firma.local
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = firma.local
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
Jak již jsem se zmínil dříve, démoni portmap
, rpc.idmap
a rpc.rpcsvcgssd
se startují automaticky ze startovacího skriptu /etc/init.d/nfs
, přesto však mají svoje spouštěcí skripty v /etc/init.d/
. Spouštění démonů proto nastavíme následovně:
[root@srv-file1 ~]# chkconfig portmap off [root@srv-file1 ~]# chkconfig nfs on [root@srv-file1 ~]# chkconfig rpcidmapd off [root@srv-file1 ~]# chkconfig rpcsvcgssd off [root@srv-file1 ~]# chkconfig rpcgssd off [root@srv-file1 ~]# chkconfig --list| grep portmap portmap 0:off 1:off 2:off 3:off 4:off 5:off 6:off [root@srv-file1 ~]# chkconfig --list | grep nfs nfs 0:off 1:off 2:on 3:on 4:on 5:on 6:off nfslock 0:off 1:off 2:off 3:off 4:off 5:off 6:off [root@srv-file1 ~]# chkconfig --list | grep rpc rpcgssd 0:off 1:off 2:off 3:off 4:off 5:off 6:off rpcidmapd 0:off 1:off 2:off 3:off 4:off 5:off 6:off rpcsvcgssd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@srv-file1 ~]# service nfs start Startuji služby NFS: [ OK ] Starting NFS mountd: [ OK ] Starting rpc.idmapd: [ OK ] Starting rpc.svcgssd: [ OK ] Starting NFS daemon: [ OK ]
Jako klienta použijeme stroj pc1.firma.local z předchozích dílů seriálu. Kerberos a LDAP jsou na něm již zkonfigurovány a fungují, tudíž se jimi nemusíme zabývat.
I na klientu nejprve ověříme podporu NFS4.
[root@pc1 ~]# mount
...
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
[root@pc1 ~]# urpmi nfs-utils-clients
# Soubor /etc/hosts na stroji pc1.firma.local 127.0.0.1 localhost localhost.localdomain 172.16.51.10 srv-infra1.firma.local srv-infra1 172.16.51.11 srv-hpc1.firma.local srv-hpc1 172.16.51.130 pc1.firma.local pc1 172.16.51.12 srv-file1.firma.local srv-file1
Stejně jako u serveru je soubor /etc/gssapi_mech.conf
vyžadován i na klientu.
# Soubor /etc/gssapi_mech.conf na stroji pc1.firma.local ... /usr/lib/libgssapi_krb5.so.2 mechglue_internal_krb5_init ...
Nejinak je tomu se souborem /etc/idmap.conf
.
# Soubor /etc/idmap.conf na stroji pc1.firma.local
[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = firma.local
[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup
Na rozdíl od předchozího dílu, kde jsme vytvářeli principal pouze pro službu, u NFS4 musíme vytvořit principal i pro každý klientský stroj. Ke slovu přijde opět nástroj kadmin
.
[root@pc1 ~]# kadmin -p krbadmin/admin@FIRMA.LOCAL
Authenticating as principal krbadmin/admin@FIRMA.LOCAL with password.
Password for krbadmin/admin@FIRMA.LOCAL:
kadmin:
Vytvoříme principal s náhodným klíčem...
kadmin: addprinc -randkey nfs/pc1.firma.local
WARNING: no policy specified for nfs/pc1.firma.local@FIRMA.LOCAL; defaulting to no policy
Principal "nfs/pc1.firma.local@FIRMA.LOCAL" created.
... a klíč přidáme do systémového keytabu
kadmin: ktadd -e des-cbc-crc:normal nfs/pc1.firma.local@FIRMA.LOCAL
Entry for principal nfs/pc1.firma.local@FIRMA.LOCAL with kvno 4, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab.
...jehož obsah následně ověříme.
[root@pc1 ~]# klist -k /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- ---------------------------------------------- 4 nfs/pc1.firma.local@FIRMA.LOCAL
Podívat se, zda věci opravdu fungují, není nikdy naškodu. Pustíme na zkoušku démona rpc.gssd
ručně tak, aby zůstal na popředí a vypisoval na konzoli podrobný výpis. Můžeme vidět, jak používá klíč uložený v keytabu k získání ticketu.
[root@pc1 ~]# rpc.gssd -fvvv
Using keytab file '/etc/krb5.keytab'
Processing keytab entry for principal 'nfs/pc1.firma.local@FIRMA.LOCAL'
We will use this entry (nfs/pc1.firma.local@FIRMA.LOCAL)
Using (machine) credentials cache: 'FILE:/tmp/krb5cc_machine_FIRMA.LOCAL'
WARNING: gssd_obtain_kernel_krb5_info: Unable to open '/var/lib/nfs/rpc_pipefs/krb5_info'. Unable to determine Kerberos encryption types supported by the kernel; using defaults (1,3,2).
Ticket ukládá do cache, jejíž obsah si zobrazíme (pozor: při ukončení démona se cache smaže). Pokud nám toto funguje, jsme na dobré cestě.
[root@pc1 ~]# klist /tmp/krb5cc_machine_FIRMA.LOCAL Ticket cache: FILE:/tmp/krb5cc_machine_FIRMA.LOCAL Default principal: nfs/pc1.firma.local@FIRMA.LOCAL Valid starting Expires Service principal 05/17/08 19:05:45 05/18/08 05:05:45 krbtgt/FIRMA.LOCAL@FIRMA.LOCAL renew until 05/18/08 19:05:45
Nastavíme automatické spouštění nezbytných démonů na klientu.
[root@pc1 ~]# chkconfig portmap on
[root@pc1 ~]# chkconfig rpcidmapd on
[root@pc1 ~]# chkconfig rpcgssd on
Proč potřebujeme portmaper a ještě ke všemu na klientu, je mi stále poněkud záhadou. NFS4 komunikuje přes vyhrazené porty 2049/tcp, 2049/udp a portmaper údajně nepoužívá. Metodou pokus omyl jsem zjistil, že to bez něj opravdu nefunguje. Na klientu také potřebujeme jaderný modul rpcsec_gss_krb5
. Jeho zavedení zajistí startovací skript démona rpc.gssd
(etc/init.d/rpcgssdrpcgssd
).
Služby ručně spustíme.
[root@pc1 ~]# service portmap start Startuji portmap: [ OK ] [root@pc1 ~]# service rpcidmapd start Starting rpc.idmapd: [ OK ] [root@pc1 ~]# service rpcgssd start Starting rpc.gssd: [ OK ]
Vytvoříme adresář, kam budeme adresáře exportované serverem na klientu mountovat.
[root@pc1 ~]# mkdir -m 755 /mnt/nfs4
Upravíme /etc/fstab
tak, aby uživatel mohl na klientu připojit kořen pseudo filesystému ze serveru.
# Soubor /etc/fstab na stroji pc1.firma.local ... srv-file1.firma.local:/ /mnt/nfs4 nfs4 rw,noauto,users,soft,sec=krb5 0 0
Přihlásíme se jako josef_vosahlo
a připojíme exportovaný adresář ze serveru, zkontrolujeme úspěšnost operace a vypíšeme obsah připojeného souborového systému. Pokusíme se také "vlézt" do adresáře, kde nemáme co dělat, a nakonec vytvoříme na vzdáleném disku soubor příkazem touch
.
[josef_vosahlo@pc1 ~]$ mount /mnt/nfs4/ [josef_vosahlo@pc1 ~]$ mount ... srv-file1.firma.local:/ on /mnt/nfs4 type nfs4 (rw,noexec,nosuid,nodev,users,soft,sec=krb5,addr=172.16.51.12) [josef_vosahlo@pc1 ~]$ ls -l /mnt/nfs4/data/ celkem 2 drwxrws--- 2 root finance 1024 kvě 17 19:52 finance/ drwxrws--- 3 root vyroba 1024 kvě 12 22:44 vyroba/ [josef_vosahlo@pc1 ~]$ ls -l /mnt/nfs4/data/finance/ celkem 0 [josef_vosahlo@pc1 ~]$ ls -l /mnt/nfs4/data/vyroba/ ls: /mnt/nfs4/data/vyroba/: Přístup odmítnut [josef_vosahlo@pc1 ~]$ touch /mnt/nfs4/data/finance/pokus [josef_vosahlo@pc1 ~]$ ls -l /mnt/nfs4/data/finance/pokus -rw-r--r-- 1 josef_vosahlo finance 0 kvě 17 20:06 /mnt/nfs4/data/finance/pokus
NFS se nám podařil úspěřně nakonfigurovat s podporou Kerbera. Pokud si budete s NFS4 hrát, zkuste například připojit vzdálený filesystem a následně pomocí příkazu kdestroy
smazat vaše tickety. Myslíte, že přístup k datům přestane fungovat? Další zajímavý test je připojit vzdálený souborový systém pod uživatelem (např. josef_vosahlo
) a zkoušet jej procházet jako root
a poté z roota pomocí su
změnit (lokálně) identitu na jiného uživatele (např. frantisek_hnipirdo
). Myslíte, že se k datům na serveru dostanete?
NFS4 pod Linuxem mi nepřijde ještě zcela zralý. V příštím díle seriálu si ukážeme, jak si s Kerberem poradí Samba.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: