Zen je webový prohlížeč vycházející z Firefoxu. Vývoj probíhá na GitHubu. Instalovat lze také z Flathubu.
Organizace Apache Software Foundation (ASF) vydala verzi 23 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Ve čtvrtek 3. října se v Red Hat Labu (místnost Q305) na FIT VUT v Brně uskuteční další Fedora Installfest. Od 10 do 16 budou v labu připravení odborníci na Fedoru ze společnosti Red Hat, kteří vám můžou pomoct nejen s instalací, ale taky pomoct s dalšími problémy a dotazy ohledně Fedory. Akce je primárně zaměřená na studenty FIT VUT, ale vítáni jsou i lidé, kteří tuto školu nenavštěvují.
Byla vydána nová verze 9.9 sady aplikací pro SSH komunikaci OpenSSH. Z novinek lze vypíchnout podporu hybridní post-kvantové výměny klíčů založené na FIPS 203 ML-KEM (Module-Lattice Key Enapsulation mechanism) v kombinaci s X25519 ECDH, tj. nový výchozí algoritmus "mlkem768x25519-sha256". Počátkem roku 2025 bude z OpenSSH odstraněna podpora DSA.
Interaktivní monitor zdrojů btop++, tj. C++ verze a pokračování monitorů bashtop a bpytop, byl vydán v nové verzi 1.4.0. Přináší podporu monitorování Intel GPU a NetBSD.
Byl vydán Nextcloud Hub 9. Představení novinek tohoto open source cloudového řešení také na YouTube.
Americký výrobce čipů Qualcomm se v minulých dnech obrátil s nabídkou na převzetí na konkurenční firmu Intel, která nyní prochází jednou ze svých největších krizí. Uvedl to list The Wall Street Journal s odvoláním na informované zdroje. Tržní hodnota Intelu se nyní pohybuje kolem 87 miliard amerických dolarů. Tržní hodnota firmy Qualcomm se pohybuje kolem 185 miliard dolarů.
Byla vydána beta verze Ubuntu 24.10 s kódovým názvem Oracular Oriole. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 24.10 mělo vyjít 10. října 2024.
Linux na 4bitovém mikroprocesoru Intel 4004 z roku 1971? Ale jistě: Linux/4004 (YouTube).
Většina nasazení technologie LDAP se odehrává uvnitř firem a jiných organizací, tedy obvykle na jediné doméně. Někdy je ale potřeba (i v těchto případech, ale třeba i pro využití LDAP u webhostingu, byť to není až tak obvyklé) obsluhovat domén více. Strom LDAP může být zhruba stejný, je však záhodno přidat jednu úroveň (zde ou=domains
), aby byla prohledávaná část stromu samostatná a „netloukla“ se s dalšími informacemi uloženými ve stromě.
První věc, kterou je potřeba řešit, jsou dotazy na domény. Lze mít samozřejmě domény nadefinovány jinde, ale pokud už se LDAP používá na jednu věc, bylo by nesmyslné udržovat ještě nějaká data jinde. Potíž je ale v tom (a podobné to bude i v dalších případech), že nelze nijak jednoduše nadefinovat prohledávání po jednotlivých složkách celého doménového jména (po jednotlivých úrovních, od TLD až po koncovou doménu).
Proto nezbývá, než to udělat méně efektivně a do nějakého atributu každého z objektů „koncových“ domén (tedy těch, které poštovní server obsluhuje) vložit celý název domény. Tedy pro doménu moje.domena
bude objekt s dc=moje,dc=domena
obsahovat v nějakém atributu (lze zvolit opět například physicalDeliveryOfficeName
) celý název, tedy moje.domena
. V souboru main.cf
se potom změní jeden řádek:
virtual_mailbox_domains = ldap:/etc/postfix/ldap/vdomains.cf
Soubor vdomains.cf
je určen pro dotazování na domény a bude mít tuto podobu:
server_host = ldap.moje.domena search_base = ou=domains scope = sub query_filter = (&(physicalDeliveryOfficeName=%s)(objectClass=domain)) result_attribute = physicalDeliveryOfficeName result_format = %s bind = no
Oproti předchozí situaci se změnila vyhledávací báze (search_base
), která zde odpovídá kořeni stromu domén. Prohledávat se bude podstrom (scope = sub
; je to výchozí hodnota, ani by tu nemusela být uvedena). Filtr nyní testuje na název domény onen atribut physicalDeliveryOfficeName
, ale současně ještě filtruje na typ objektu domain
, aby šlo skutečně o informace o doménách. Formát výsledku je prosté přenesení textu.
Podobným způsobem je třeba upravit také vmailboxes.cf
. Pro správnou funkci je třeba vyplnit atribut mail
, podle kterého se nyní bude hledat.
server_host = ldap.moje.domena search_base = ou=domains scope = sub query_filter = (&(preferredDeliveryMethod=physical)(mail=%s)(objectClass=inetOrgPerson)) result_attribute = mail result_format = %d/%u/ bind = no
Jak si můžete všimnout, hledá se nyní právě podle atributu mail
(celé e-mailové adresy) a objekty se filtrují podle třídy inetOrgPerson
. Vrácený atribut se přeformátuje tak, aby tvořil správnou relativní cestu k úložišti. Soubor virtual.cf
pro aliasy pak bude mít tuto podobu:
server_host = ldap.moje.domena search_base = ou=domains scope = sub query_filter = (&(preferredDeliveryMethod=mhs)(mail=%s)(objectClass=inetOrgPerson)) result_attribute = physicalDeliveryOfficeName result_format = %s bind = no
Zde je odchylka od původní podoby ještě menší. Změnila se vyhledávací báze, rozsah prohledávání a přibyla filtrace podle třídy objektů.
Kdo pochopil jádro problému u konfigurace Postfixu, jistě nyní dokáže správně nakonfigurovat i Dovecot. Rozdíl bude prakticky jen v syntaxi konfiguračního souboru. Tady je jedna z možných podob souboru ldap.conf
(hlavní konfigurační soubor dovecot.conf
se samozřejmě nemění):
hosts = ldap.moje.domena tls = yes dn = uid=dovecot,ou=users dnpass = nejakeheslo scope = subtree base = ou=domains user_attrs = =home=/var/mail/virtual/%d/%n user_filter = (&(preferredDeliveryMethod=physical)(mail=%u)(objectClass=inetOrgPerson)) default_pass_scheme = PLAIN pass_attrs = mail=user, userPassword=password pass_filter = (&(preferredDeliveryMethod=physical)(mail=%u)(objectClass=inetOrgPerson))
Asi to ani nepotřebuje komentář. Soubor je dokonce jednodušší než ten pro jedinou doménu. Vyžaduje (stejně jako konfigurace pro Postfix) ale samozřejmě vyplněný atribut mail
u každého uživatele, především je ale operačně dost náročný. Jak tomu čelit? Jednou z možností je rezignovat na plně stromovou strukturu a umístit všechny domény do jedné úrovně. Případně lze strukturu zachovat a samostatně do ploché struktury umístit jejich aliasy (to ale znamená, že se tyto aliasy musí také spravovat). Našla by se asi i další řešení, která ale přesahují rámec tohoto článku a lépe by se k nim vyjádřili znalci protokolu LDAP.
Toto byl poslední článek v řadě těch, které se věnovaly uložení informací o poštovních schránkách, uživatelích, aliasech atd. (sice není nadobro konec, některé záležitosti se znovu objeví v pozdějších článcích, ale prozatím je to všechno). Nyní přijde čas pro neméně důležité věci, mezi které patří ochrana proti nevyžádané poště čili spamu. Postfix sám o sobě i s pomocí dalších nástrojů má mnoho možností, jak se spamem úspěšně bojovat, proto by bylo chybou tyto nástroje náležitě nevyužít.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Jen bych se chtel zeptat, zdali bude take uvedena konfigurace dovecotu jako LDA ( treba se Sieve ci procmail pro presun SPAMU do adresare ci automaticke promazavani SPAM adresar)?Samozřejmě bude.
Pak taky, zda-li byste mohl dokoncit tu vsuvku o podadresarich kvuli pluginum. Co vsechno se zmeni (user_attrs?).Teď jen ve stručnosti. Jde o to, že pokud se například využívá Sieve a nad domovským adresářem pracuje ManageSieve (ať už jako součást Dovecotu nebo jako samostatný program, např. PySieved), budou se v klientovi zobrazovat i soubory, které nemají. A obráceně, Dovecot bude adresář vytvořený pro účely Sieve (kam se budou ukládat Sieve skripty) považovat za poštovní složku (pokud bude název začínat tečkou, jak je obvyklé), čili ji bude klientům nabízet společně s jinými složkami. To není stav, o který by člověk zrovna stál. Ale znovu říkám, ve všech příkladech dosud používaných v seriálu využití "domovského adresáře virtuálního uživatele" nijak nevadilo, proto jsem také nevytvářel další adresářovou úroveň. Při použití se samozřejmě user_attrs nezmění, protože tam je právě domovský adresář, který zůstane stejný. Změní se naopak mail_location (například na maildir:/var/mail/virtual/%d/%n/Maildir, pokud bude pošta v adresáři Maildir pod domovským adresářem). U Postfixu by se změnil result_format (v tomto případě na %d/%u/Maildir/).
vůbec nechápu princip jeho činnostiCo na tom nechápeš? Základní princip je naprosto triviální. Je to prostě strom objektů a každý objekt může mít atributy (jaké přesně a které jsou povinné atd., to záleží na schématu). Ten strom může vycházet třeba z hierarchie DNS nebo být úplně jiný, podle potřeby. Představ si to třeba jako XML strom nebo něco takového (třeba registry ve Windows ), je to jedno. Jak si to server vnitřně reprezentuje (třeba klidně jako nějaký XML soubor, databázi nebo jako objekty v C++, které se pak binárně zapisují na disk), to už je čistě implementační záležitost. K jednotlivým objektům a atributům lze pak nastavovat práva.
ani jej neumím nainstalovatInstalace je taktéž triviální. Netriviální může být u některých implementací počáteční konfigurace (např. u OpenLDAP). Ale jsou implementace, kde je to také jednoduché (třeba Apache Directory Server; pro něj existuje také klikátko Apache Directory Studio, kterým lze jak pracovat se stromem, tak i konfigurovat server).
Pokud je to ovšem celé, tak pak nechápu smysl samotného LDAPu , resp. napadají mě technologie, které zvládnou totéž co si myslím, že má být LDAP (nasazení LDAPu tak jak jej máme u nás by šlo snadno přepsat do SQL).LDAP je především komunikační protokol. O to jde v první řadě. A protože tento protokol má poměrně širokou podporu, lze ho využívat v mnoha programech. Lze měnit klientský i serverový software podle potřeby, aniž by se musel měnit zbytek celku.
Pokud o tom někdo napíše srozumitelný článek včetně příkladů nasazení (od nejjednodušších, řekněme pro ověřování uživatelů na jedné mašině (místo /etc/passwd)), rád si jej přečtu. A jistě nebudu sám.Jo, k tomu článku pro blbé se také přidávám S (open)LDAP jsem se dostal do fáze, kdy běží (jakože se jen samoúčelně spustí bez použitelných dat), ale nejsem tam schopen nic rozumného nasáčkovat tak, abych to mohl jakkoliv použít. Většina návodů se spoléhá na nějaké skripty, které udělají většinu práce (ale tyto skripty v Archu nejsou). Chtěl jsem začít zdrojem adres pro mailové klienty, ale nějak jsem se neprokousal k výsledku. Pro Lukáše: kdyby se ti chtělo napsat knihu o LDAP, určitě bys měl jistého minimálně jednoho kupce
Pro Luka - pokud budeš psát knihu, dobře si to rozmysli, moc čtenářů mít nebude.Knihu psát nebudu - viz níže
Pro Lukáše: kdyby se ti chtělo napsat knihu o LDAP, určitě bys měl jistého minimálně jednoho kupceZaprvé nejsem odborník na LDAP (proto píšu v článku, že "lépe se vyjádří znalec LDAP" - a to já bohužel nejsem), zadruhé teď dokončuji zapracování odborné korektury do knihy na úplně jiné téma, takže o psaní knih zase nějakou dobu nebudu chtít ani slyšet
Zaprvé nejsem odborník na LDAP (proto píšu v článku, že "lépe se vyjádří znalec LDAP" - a to já bohužel nejsem), zadruhé teď dokončuji zapracování odborné korektury do knihy na úplně jiné téma, takže o psaní knih zase nějakou dobu nebudu chtít ani slyšetTo je škoda. Píšeš pěkně "čitelně" :)
Čemu by tak hrozně vadilo to, kdybychom si vytvořili vlastní schema ?Nevadilo by. Tedy aspoň v tomto případě (u některých programů by vadilo, protože ty napevno počítají s objekty určitých tříd). Akorát že by se muselo vymýšlet a muselo by se nainstalovat. Pokud se použije hotové schéma, toto celé odpadá.