Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »Francouzský výrobce kabelů Nexans upozornil na napjaté dodávky elektrických kabelů. Výstavba nové výrobní linky pro některé typy kabelů může trvat přibližně tři roky. Datacentra potřebují rozsáhlé nízkonapěťové a středněnapěťové rozvody. Poptávka roste současně s modernizací elektrických sítí. Někteří odběratelé proto uzavírají výrazně delší dodavatelské smlouvy [Reuters].
Představena byla (𝕏) virtuální platforma FLYBENCH FPV, která nováčky provede zapojením a konstrukcí dronů.
Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
Dobrý den,
na SLES10 mi přestal startoval LDAP server: hlásí chybu:
supr nscd: nss_ldap: could not search LDAP server - Server is unavailable
Konfigurace se snad nezměnila. Kde bych měl hledat chybu? Následkem toho pak nejde ani pošta, Samba, nic co se přes LDAP ověřuje.
Podle jednoho doporučení jsem zkusil:
netstat -plutn | grep slapd
ale nevypsalo to nic.
Děkuji za jakékoliv postrčení. Škola nám stojí... 
Řešení dotazu:
Váš popis je velmi strohý ... jste začátečnik ? SLES jsem tedy nikdy nepoužíval, ale snad každé distro má logy (to moje ve /var/log/ ). zde lze snadno - dělám to pomocí midnight commanderu (esc -> ? tuším) prohledat soubory na výskyt slova slapd a tím se dopracovat k lepšímu popisu chyby.
Také lze (u mne) spustit slapd z konzole a sledovat co se bude dít. množství vypisovaných informací lze řídit buď z /etc/ldap/slapd.conf (u mne) nebo z příkazové řádky ( u mne spuštěním "slapd -d 16383" - to číslo udává, co vše se má vylogovat a myslím, že s tímto číslem jsem dostal tak 5 obrazovek hlášek). Více je v man slapd.conf (u mne).
Jak říkám, Vaše distro neznám, ale snad nebude tak moc odlišné.
Jen doufám, že jste si "nehrál" s nastavením, kterému nerozumíte a řešení brzy naleznete.
S pozdravem
Uhrák
Ano jsem začátečník.S konfigurací nikdo nic nedělal.
Dále je v logu toto:
supr slapd[12136]: bdb_db_open: Database cannot be opened, err -30974. Restore from backup!
Jun 15 09:31:24 supr slapd[12136]: ====> bdb_cache_release_all
Jun 15 09:31:24 supr slapd[12136]: bdb(dc=domena,dc=cz): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
Jun 15 09:31:24 supr slapd[12136]: bdb(dc=domena,dc=cz): txn_checkpoint interface requires an environment configured for the transaction subsystem
Jun 15 09:31:24 supr slapd[12136]: bdb_db_close: txn_checkpoint failed: Invalid argument (22)
Jun 15 09:31:24 supr slapd[12136]: backend_startup_one: bi_db_open failed! (-30974)
Jun 15 09:31:24 supr slapd[12136]: slapd shutdown: initiated
Jun 15 09:31:24 supr slapd[12136]: ====> bdb_cache_release_all
Jun 15 09:31:24 supr slapd[12136]: bdb_db_close: alock_close failed
Jun 15 09:31:24 supr slapd[12136]: slapd destroy: freeing system resources.
Jun 15 09:31:24 supr slapd[12136]: slapd stopped.
Jun 15 09:31:24 supr slapd[12136]: connections_destroy: nothing to destroy.
supr:/var/lib/ldap #
To vypadá na poškozenou databázi LDAP?
Ano, pravdepodobne poskodena databaza (vypadok elektriky?) . LDAP vacsinou pouziva standardne databazu berkeley-db (BDB), ktora je sice fajn, ale lahko sa poskodi vplvyom napr zleho vypnutia. Je preto dolezite robit pravidelne zalohy (dumpy) databazy v pripade ze by takato situacia nastala. Pokial ziadna zaloha nie je, je mozne existujucu databazu este skusit opravit pomocou "dbX" utilit (kde X je verzia pouzivanej BDB)... konkretne pomocou dbX_recover (alebo mozno aj rovno db_recover, treba zistit). Zo slapd.conf si zistite, kde je presne ulozena databaza (direktiva "directory") a pouzite nasledujuci prikaz:
db_recover -h /cesta/k/databaze
Prikaz by nemal vypisat nic a po jeho dokonceni mozte skusit nastartovat LDAP cez init skript. Ak tato recovery nepomoze, skuste pouzit este catastrophic recovery (ten isty prikaz s parametrom -c):
db_recover -c -h /cesta/k/databaze
drzim palce.
Ani nevíte, jak jste mi pomohl, díky moc. Zabrala až ta druhá možnost, poprvé se zobrazila chyba
db_recover: unable to join the environment
A o té druhé možnosti jsem nevěděl.
Výslechy bylo zjištěno, že skutečně došlo k výpadku napájení, bohužel jistá osoba vytáhla nesprávný kabel z UPS.
Děkuju všem za rychlé reakce. JR
supr nscd: nss_ldap: could not search LDAP server - Server is unavailableTohle není chyba LDAP serveru, ale LDAP klienta NSS (tj. správa a ověřování unixových účtů v LDAPu). Pokud tohle skutečně najdete v logu LDAP serveru, znamená to, že ke startu LDAP serveru potřebujete účty, které jsou v LDAPu – což by byl poněkud problém. Účty potřebné pro start LDAPu musíte mít v lokální databázi (
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
/etc/passwd a /etc/groups) a NSS musíte mít nastavené tak, aby nejprve zkoušel soubory a pak až LDAP, nebo aby při nedostupnosti LDAPu pokračoval v ověřování dál přes soubory.
Dobrý den,
mám to chápat tak, že pokud mám v slapd.conf:
database bdb
suffix "dc=domena,dc=cz"
rootdn "cn=Administrator,dc=domena,dc=cz"
rootpw "{ssha}A55YdUvtLY5v/6phETq5INaLlLpYWlpTTA=="
tak to znamená, že LDAP server vyžaduje pro svůj start účet administrator a tento účet musí být také v /etc/passwd?
ldap (pod rootem asi neběží, resp. po startu a zahájení naslouchání se asi práv roota zbaví), tj. vlastníkem datových souborů je uživatel ldap apod. Uživatele ldap pak musí být nutné ověřit i bez běžícího LDAP serveru – tj. uživatel musí být v lokální databázi (v souboru /etc/passwd) a tato databáze se musí prohledávat i při nedostupnosti LDAP serveru (nejlepší je, když se soubory prohledávají jako první – zpravidla jsou tam systémové účty, a nejspíš chcete, aby nebylo možné ani omylem tyto účty v LDAPu předefinovat).
Tiskni
Sdílej:
