Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Základním pojmem v Kerberu je principal. Principal v podstatě představuje identitu uživatele. Nemusí se však vždy jednat pouze o fyzického člověka, který se někam přihlašuje. Může se jednat i o identitu počítače nebo o identitu služby. Principal se skládá ze tří částí: primary, instance a realm. Zapisuje se ve formátu primary/instance@REALM.
Část primary představuje buď uživatelské jméno v případě, že se jedná o uživatele, nebo jméno služby, pokud se jedná o službu. Část instance má různý význam pro různé typy principalů. V případě uživatele se jedná o rozšiřující část, která může blíže specifikovat účel, ke kterému se identita používá nebo může být i nulová. Jedná-li se o principal počítače, pak tato část obsahuje jeho plné doménové jméno. Část REALM obsahuje překvapivě jméno realmu. Realm je logická entita, ve které se naše účty nacházejí. Její význam je prakticky totožný s významem pojmu doména ve světě Windows. V praxi se používá jméno realmu totožné se jménem DNS domény převedeným na velká písmena.
Řekněme, že máme v naší testovací síti DNS doménu se jménem firma.local, pak se náš Kerberos realm bude jmenovat FIRMA.LOCAL. Naše principaly mohou vypadat podobně jako v následující tabulce.
user0@FIRMA.LOCAL |
pricipal běžného uživatelského účtu uživatele user0 |
administrator/admin@FIRMA.LOCAL |
pricipal speciálního uživatelského účtu uživatele administrator |
host/srv-file1.firma.local@FIRMA.LOCAL |
principal počítače srv-file1.firma.local |
nfs/srv-file1.firma.local@FIRMA.LOCAL |
principal služby NFS na počítači |
Předběhněme teď trošku a představme si, že již máme správně nakonfigurovanou klientskou i serverovou část. Dříve než uživatel může použít nějakou službu v naší síti, musí být nejprve řádně autentizován. Autentizace proběhne ve čtyřech krocích:
Kroky 1 a 2 mohou proběhnout již při přihlášení uživatele k PC pomocí PAM modulu nebo mohou být výsledkem příkazu kinit spuštěném na klientském PC. Vzhledem k tomu, že se v průběhu komunikace kontrolují časová razítka v authenticatorech, neměly by se hodiny na zúčastněných strojích příliš rozcházet. Použití synchronizace času v síti pomocí NTP je nanejvýš vhodné. Maximální velikost povolené odchylky je konfigurovatelná. Služby AS a TGS spolu tvoří tzv. Key Distribution Center (KDC) – server Kerbera. Teď, když alespoň mlhavě tušíme, jak celá věc funguje, můžeme si s ní začít hrát. Nakonfigurujeme si náš první KDC v realmu FIRMA.LOCAL.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
urpmi krb5-server
Server, na němž KDC poběží, se bude jmenovat srv-infra1.firma.local. Protože v naší síti zatím nepoužíváme DNS, upravíme si soubor /etc/hosts tohoto serveru následovně:
# Soubor /etc/hosts na stroji srv-infra1.firma.local 127.0.0.1 localhost.localdomain localhost 172.16.51.10 srv-infra1.firma.local srv-infra1
Upravíme soubor /etc/krb5.conf, ve kterém konfigurujeme knihovny Kerbera. Tento soubor najdeme s mírnou obměnou obsahu jak na KDC, tak na klientu. Ovlivňuje chování serverových i klientských programů Kerbera, včetně pomocných nástrojů.
# Soubor /etc/krb5.conf na stroji srv-infra1.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
[kdc]
profile = /etc/kerberos/krb5kdc/kdc.conf
[logging]
default = FILE:/var/log/kerberos/krb5libs.log
kdc = FILE:/var/log/kerberos/krb5kdc.log
admin_server = FILE:/var/log/kerberos/kadmind.log
[realm] definujeme, kde běží naše KDC. Dále říkáme, kde běží služba admin serveru, který nám umožní spravovat Kerbera vzdáleně pomocí řádkového nástroje kadmin.[domain_realm] říká, jak se převádí jméno tohoto počítače na jméno Kerberos realmu. Kdybychom tuto sekci vynechali, nic by se nemělo stát. Automaticky by se použila doménová část jména převedená na velká písmena.[libdefaults] nastavíme výchozí realm pro klientské programy (včetně admin nástrojů) na FIRMA.LOCAL.[kdc] uvedeme, kde leží konfigurace KDC. Tou se budeme zabývat za chvilku.Ostatní sekce a položky konfiguračního souboru, které jsme nepopsal, nejsou pro nás v tuto chvíli důležité, ale myslím, že jejich názvy jsou dostatečně vypovídající. Další informace můžeme nalézt v manuálové stránce k souboru krb5.conf.
KDC se konfiguruje pomocí souborů v adresáři /etc/kerberos/krb5kdc/. Vlastní konfiguraci KDC najdeme v souboru kdc.conf a v souboru kadm.acl najdeme konfiguraci přístupových oprávnění k databázi Kerbera.
# Soubor /etc/kerberos/krb5kdc/kdc.conf na stroji srv-infra1.firma.local
[kdcdefaults]
kdc_ports = 88
acl_file = /etc/kerberos/krb5kdc/kadm5.acl
dict_file = /usr/share/dict/words
admin_keytab = /etc/kerberos/krb5kdc/kadm5.keytab
[realms]
FIRMA.LOCAL = {
master_key_type = des3-hmac-sha1
supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal
profile = /etc/krb5.conf
database_name = /etc/kerberos/krb5kdc/principal
admin_database_name = /etc/kerberos/krb5kdc/kadm5_adb
admin_database_lockfile = /etc/kerberos/krb5kdc/kadm5_adb.lock
admin_keytab = FILE:/etc/kerberos/krb5kdc/kadm5.keytab
acl_file = /etc/kerberos/krb5kdc/kadm5.acl
dict_file = /usr/share/dict/words
key_stash_file = /etc/kerberos/krb5kdc/.k5stash
kdc_ports = 88
kadmind_port = 749
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
}
Sekce [kdcdefaults] obsahuje výchozí hodnoty pro KDC jako celek. Sekce [realms] obsahuje konfiguraci specifickou pro jednotlivé realmy. Důležitou položkou je supported_enctypes, jež obsahuje seznam typů šifrování, které bude KDC podporovat. To má zásadní vliv na kompatibilitu s klienty. Určité klienty podporují pouze určité typy šifrování. Dále nastavíme port, na kterém má KDC běžet, na 88/udp a port, na kterém poběží admin server, na 749/tcp. Důležitá je také maximální doba platnosti tiketu.
Nastavením administrátorských oprávnění k databázi se moc zabývat nebudeme. Uvádím zde pouze minimalistické nastavení souboru kadm.acl, které umožňuje všem principalům s instancí admin spravovat databázi Kerbera.
# Soubor /etc/kerberos/krb5kdc/kadm.acl na stroji srv-infra1.firma.local
*/admin@FIRMA.LOCAL *
Spuštěním příkazu kdb5_util podle následujícího příkladu vytvoříme databázi Kerbera. Na výzvu zadáme master key.
[root@srv-infra1 kerberos]# kdb5_util create -s
Loading random data
Initializing database '/etc/kerberos/krb5kdc/principal' for realm 'FIRMA.LOCAL',
master key name 'K/M@FIRMA.LOCAL'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:
Vytvoříme principal krbadmin/admin@FIRMA.LOCAL, pod kterým budeme databázi administrovat. Použijeme k tomu příkaz kadmin.local. Ten nám umožňuje spravovat Kerbera pouze lokálně, avšak bez autentizace, což se nám teď hodí.
[root@srv-infra1 kerberos]# kadmin.local -q "addprinc krbadmin/admin"
Authenticating as principal root/admin@FIRMA.LOCAL with password.
WARNING: no policy specified for krbadmin/admin@FIRMA.LOCAL; defaulting to no policy
Enter password for principal "krbadmin/admin@FIRMA.LOCAL":
Re-enter password for principal "krbadmin/admin@FIRMA.LOCAL":
Principal "krbadmin/admin@FIRMA.LOCAL" created.
Nejprve nastartujeme admin server, poté nastartujeme vlastní KDC.
[root@srv-infra1 kerberos]# service kadmin start
[root@srv-infra1 kerberos]# service krb5kdc start
Ověříme, zda se služby startují automaticky při startu počítače.
[root@srv-infra1 ~]# chkconfig --list | grep kadmin kadmin 0:off 1:off 2:off 3:on 4:on 5:on 6:off
[root@srv-infra1 ~]# chkconfig --list | grep krb5kdc krb5kdc 0:off 1:off 2:off 3:on 4:on 5:on 6:off
Pokud by náhodou automatický start nebyl nastaven, opravíme to.
[root@srv-infra1 ~]# chkconfig kadmin on
[root@srv-infra1 ~]# chkconfig krb5kdc on
Administrační nástroj Kerbera spustíme příkazem kadmin s identitou uživatele krbadmin/admin@FIRMA.LOCAL.
[root@srv-infra1 etc]# kadmin -p krbadmin/admin
Nyní se nacházíme v příkazové řádce kadmin a můžeme začít administrovat databázi.
Vypíšeme obsah databáze příkazem listprincs z příkazové řádky kadmin.
kadmin: listprincs
K/M@FIRMA.LOCAL
kadmin/admin@FIRMA.LOCAL
kadmin/changepw@FIRMA.LOCAL
kadmin/history@FIRMA.LOCAL
kadmin/srv-infra1.firma.local@FIRMA.LOCAL
krbadmin/admin@FIRMA.LOCAL
krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
Povšimněme si, že databáze obsahuje principal krbadmin/admin@FIRMA.LOCAL. Ten jsme vytvořili v kroku 6. Dále obsahuje několik systémových principalů vytvořených automaticky při inicializaci databáze v kroku 5.
Stále se nacházíme v příkazovém řádku kadmin. Chceme vytvořit principal testovacího uživatele user0. Použijeme příkaz addprinc.
kadmin: addprinc user0
WARNING: no policy specified for user0@FIRMA.LOCAL; defaulting to no policy
Enter password for principal "user0@FIRMA.LOCAL":
Re-enter password for principal "user0@FIRMA.LOCAL":
Principal "user0@FIRMA.LOCAL" created.
Příkazovou řádku kadmin opustíme příkazem quit.
kadmin: quit
Vyzkoušíme, zda jsme schopni od Kerbera získat TGT pro uživatele user0.
[root@srv-infra1 etc]# kinit user0
Password for user0@FIRMA.LOCAL:
Pokud vše proběhne správně, měli bychom být schopni zobrazit získaný TGT pomocí příkazu klist.
[root@srv-infra1 etc]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user0@FIRMA.LOCAL
Valid starting Expires Service principal
03/31/08 22:00:10 04/01/08 08:00:10 krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
renew until 04/01/08 22:00:10
Při pokusech se nám bude hodit možnost získané tikety smazat. To můžeme provést příkazem kdestroy.
Zdá se, že vše běží jak má; můžeme přistoupit ke konfiguraci klientského PC.
Jako první klientský stroj vytvoříme stroj s názvem pc1.firma.local.
[root@pc1 ~]# urpmi krb5-workstation
Ze stejného důvodu jako u serveru nastavíme /etc/hosts.
# Soubor /etc/hosts na stroji pc1.firma.local 127.0.0.1 localhost.localdomain localhost 172.16.51.10 srv-infra1.firma.local srv-infra1
Opět upravíme /etc/krb5.conf, tentokrát však na klientském PC.
# Soubor /etc/krb5.conf na stroji pc1.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
[logging]
default = FILE:/var/log/kerberos/krb5libs.log
Vyzkoušíme, zda jsme od Kerbera schopni získat TGT pro uživatele user0 na stroji pc1.
[root@pc1 ~]# kinit user0
Password for user0@FIRMA.LOCAL:
Pokud vše proběhne dobře zobrazíme si získaný TGT.
[root@pc1 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user0@FIRMA.LOCAL
Valid starting Expires Service principal
03/31/08 22:39:01 04/01/08 08:39:01 krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
renew until 04/01/08 22:38:18
Na pc1 vytvoříme lokálního uživatele user0. Bude se nám hodit pro testování.
root@pc1 ~]# adduser user0
[root@pc1 ~]# urpmi pam_krb5
Konfiguraci provedeme v souboru /etc/pam.d/system-auth.
#Soubor /etc/pam.d/system-auth na stroji pc1.firma.local auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so account sufficient pam_unix.so account required pam_deny.so password sufficient pam_unix.so nullok use_authtok md5 shadow password sufficient pam_krb5.so password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session required pam_unix.so
Pokusíme se přihlásit jako user0 k pc1.firma.local. Můžeme to provést buď z testové konzole nebo v grafickém prostředí pomocí Display Manageru. Při svých pokusech jsem narazil na určité chyby v XDM a KDM, které vedly k tomu, že po úspěšné autentizaci byl získaný TGT smazán. Pro experimenty doporučuji GDM.
Pokud se úspěšně přihlásíme, zkontrolujeme získaný TGT příkazem klist.
[user0@pc1 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_501_esGeeF
Default principal: user0@FIRMA.LOCAL
Valid starting Expires Service principal
04/12/08 20:56:54 04/13/08 06:56:54 krbtgt/FIRMA.LOCAL@FIRMA.LOCAL
renew until 04/13/08 20:55:25
Uživatel může změnit své heslo pomocí příkazu kpasswd. Máme-li však správně nakonfigurovaný PAM modul pro Kerbera, lze změnu hesla provést i standardním příkazem passwd.
[user0@pc1 ~]$ passwd
Změna hesla uživatele user0.
Změna hesla pro user0.
(současné) UNIX heslo:
New Kerberos 5 Password:
Repeat New Kerberos 5 Password:
passwd: všechny autentizační tokeny byly úspěšně změněny.
Základní konfiguraci klienta i serveru jsme zvládli. Mít centrální databázi hesel a přitom zakládat uživatelské účty lokálně není asi moc užitečné. Příště si ukážeme, jak sdílet uživatelské účty v síti pomocí LDAPu. Kerberos a LDAP jsou silná dvojka. Místo LDAPu bychom mohli použít třeba NIS, ale to už by dneska asi nikoho nezajímalo.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Velmi dobrý článek