Oficiálně byl vydán Android 14. Detaily na blogu a stránkách věnovaných vývojářům.
Google na akci Made by Google '23 (YouTube) představil novinky v kolekci produktů Pixel: hodinky Pixel Watch 2 a telefony Pixel 8 a Pixel 8 Pro s čipem Tensor G3, Androidem 14 a 7letou softwarovou podporu.
Byla vydána nová verze 9.5 sady aplikací pro SSH komunikaci OpenSSH. Nově ve výchozím stavu ssh-keygen generuje Ed25519 klíče. Do ssh byla přidána možnost obfuskace časováním stisknutí kláves (keystroke timing obfuscation).
Konference OpenAlt 2023 proběhne o víkendu 11. a 12. listopadu v Brně. Přihlásit přednášky lze do neděle 8. října 23:59.
V X.Org v libX11 do 1.8.7 a libXpm do 3.5.17 bylo nalezeno a v upstreamu opraveno 5 bezpečnostních chyb (CVE-2023-43785, CVE-2023-43786, CVE-2023-43787, CVE-2023-43788 a CVE-2023-43789). Dvě nejstarší jsou s námi 35 let. Obsaženy byly již v X11R2 vydaném v únoru 1988.
Byly publikovány informace o bezpečnostní chybě Looney Tunables aneb CVE-2023-4911 v glibc ld.so. Útočník ji může využít k lokální eskalaci práv. Vyzkoušeno na výchozích instalacích linuxových distribucí Fedora 37 a 38, Ubuntu 22.04 a 23.04 a Debian 12 a 13. Chyba byla do glibc zavlečena v dubnu 2021. Detaily v txt.
Na Kickstarteru byla spuštěna crowdfundingová kampaň na podporu telefonu Murena 2 s /e/OS. Telefon má 2 hardwarové přepínače. Prvním lze jednoduše vypnout kamery a mikrofony. Druhým se lze odpojit od sítí.
Společnost Qualcomm publikovala říjnový bezpečnostní bulletin. V úvodu informuje, že bezpečnostní chyby CVE-2023-33106, CVE-2023-33107, CVE-2022-22071 a CVE-2023-33063 jsou cíleně využívány útočníky. O CVE-2022-22071 se píše už v loňském květnovém bulletinu. Detaily o zbylých chybách jsou k dispozici OEM partnerům. Veřejně budou k dispozici až s vydáním prosincového bulletinu.
Byla vydána nová verze 5.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 12.5.6. Tor na verzi 0.4.8.6.
Šifrovací nástroj VeraCrypt v menším vydání 1.26.7 nejen opravuje chyby a aktualizuje podporované algoritmy (podrobnosti v poznámkách vydání), ale také přestává podporovat původní svazky TrueCrypt.
Ahoj, prosím o radu s následujícím problémem.
Na serveru jsem měl httpd (Apache) verze 2.x. (Nevím už přesně, která verze to byla.) Server bez problémů fungoval, včetně PHP a přístupu k databázi.
Po aktualizaci (balíčkovacím systémem ArchLinuxu) na verzi 2.2.6 přestal fungovat. Jakýkoliv dotaz způsobí zatuhnutí démona se 100% využitím CPU.
Web tedy samozřejmě nefunguje a každý další pokus o načtení www stránky spustí další proces httpd, který opět využívá CPU, jak nejvíc může.
Po zamrznutí jsou procesy httpd nesmrtelné. Nelze je zabít žádným způsobem kromě restartu. Zdůrazňuji, že nejde o zombie procesy. Tyto využívají procesor velmi náruživě.
V logu nic podezřelého není. Možná bych měl zapnout jinou úroveň logování... Ale kterou?
Googlem jsem našel desítky odkazů o zamrzajících procesech httpd, ale vždy šlo o zombie nebo chybný PHP skript. Toto je zjevně jiný případ. Nemám ponětí, čím to může být.
17.9.2007 13:05
frEon | skóre: 40
| Praha
Zkusím tedy LogLevel debug. Zatím to vypadá, že se do logu nepíše absolutně nic, ale třeba se tam při vyšším LogLevelu stihne ještě něco zapsat, než to zamrzne.
Týká se to všech virtual hostů. I těch, u kterých není PHP.
Tak teda fakt nevím, čím by to mohlo být. Zapnul jsem LogLevel debug. Tvrdilo to jedinou podezřelou věc - že vypršela platnost CRL. Tedy jsem vygeneroval nový CRL a hláška tam už pak není.
Ale zamrzá to dál přesně stejně. Do access_log se vůbec nic nezapíše, resp. nestihne zapsat. V error_logu taktéž nic zajímavého není. Jediná hlášení typu error vznikají ve chvíli, kdy se při restartu server vypíná a nemůže žádným způsobem zabít své zaseknuté potomky.
Takže co s tím? Přece nemůžu být jediný, kdo má tenhle problém... To by byla moc velká náhoda.
df cat /etc/hosts cat /etc/resolv.confNebude tam někde bordel? Zkoušel jste nedistribuční apache?
Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 3937220 1763492 1973724 48% / none 144108 0 144108 0% /dev/shm /dev/hda2 15314684 11207300 3329440 78% /home /dev/hdc1 5699964 1153176 4257244 22% /var
127.0.0.1 localhost.localdomain localhost charon
nameserver 127.0.0.1
Pro úplnost ještě dodám, že nastavení je přesně stejné jako u původní verze Apache, která fungovala. Na tom serveru zároveň běží named pro mou doménu, proto je sám sobě name serverem. (DNS funguje bez potíží.)
Jakmile ale přijde jakýkoliv http požadavek - bez ohledu na to, zda z vnitřní sítě nebo zvenčí - celý Apache se zasekne a nepomůže nic jiného než restart.
Už jsem měl podobný problém dvakrát. Jednou šlo (matně si vzpomínám) o problém s interpretem PHP (vyřešeno). Podruhé byl problém s šifrovacím enginem - špatný název souboru s klíčem (vyřešeno). Jenže v obou případech tam zůstávaly jen zombie, které nevyužívaly procesor. Tento případ je naprosto ojedinělý a asi kvůli němu brzy přijdu o nervy...
Nedistribuční apache jsem nezkoušel. (Kdysi ano, ale tuto verzi nikoliv.) Je poměrně složité to správně nakonfigurovat a v tuto chvíli na to nemám čas ani kuráž. Kdybych jenom převzal konfiguraci z PKGBUILDu, získal bych stejný Apache... Jedině bych mohl někde splašit starší verzi, ale tím ten problém nezmizí.
Jste si opravdu jist, že to není chybný PHP skript nebo nějaký problém s přepisováním adres?
Aktualizoval jsem pouze software. Skripty zůstaly navlas stejné. Fungovaly předtím cca půl roku. Pokud jde o mod_rewrite, nic takového nepoužívám.
Odhadoval bych, že problém je v tom, že se Apache pokouší rekurzivně vkládat do sebe jednu a tu samou stránku, nebo se přesměrovává neustále na jednu a tu samou adresu (případně navzájem mezi více adresami v kolečku).
To si nemyslím. Ani LogLevel debug neukazuje nic podezřelého nebo snad cyklického... Kdyby třeba narůstala spotřeba paměti nebo kdyby se hodně logovalo, dá se z toho kdeco usoudit. Jenže ono nic. Jen procesor je zatížený na maximum. Jednou se mi hromadily instance httpd proto, že selhal jeden z harddisků a nešlo zapisovat do logu. Ale toto není ten případ.
Neaktualizovalo se s Apachem i PHP? Konfigurační soubory se změnily, nebo jsou tam stále ty samé?
PHP se aktualizovalo taktéž. PHP (prostě přímo příkaz php) funguje - nechybí žádné knihovny nebo tak něco. Konfigurační soubory jsou původní. Časem se chystám provést nějaký merge, ale to bude dlouhá a nepříjemná procedura...
Zkusil bych nejprve vyloučit problém se skriptem nebo přesměrováním – vypnout všechny rewrite a zkusit načíst nějakou statickou stránku.
Provedeno. Přepisování nepoužívám. Mám hned několik virtuálních hostů se statickými stránkami. Bohužel taktéž nefungují. Dopadne to stejně, ať přistupuju ke stránce s PHP nebo bez něj.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
Aktualizoval jsem pouze software. Skripty zůstaly navlas stejné. Fungovaly předtím cca půl roku. Pokud jde o mod_rewrite, nic takového nepoužívám.To by něco znamenalo, pokud by to nebylo PHP. S PHP si ale člověk nemůže být nikdy jistý, bohužel. Zvlášť když jste aktualizoval i PHP, tam co verze, to originál…
Provedeno. Přepisování nepoužívám. Mám hned několik virtuálních hostů se statickými stránkami. Bohužel taktéž nefungují. Dopadne to stejně, ať přistupuju ke stránce s PHP nebo bez něj.Nemůžete mít zapnuté nějaké include nebo něco podobného? I z toho, že jsou všechny procesy ve stavu R bych tipoval, že ty procesy na nic nečekají, ale opravdu se snaží něco (cyklicky) načítat. Zkusil jste se připojit k serveru přímo telnetem a podívat se, jestli alespoň něco odpoví?
telnet server 80 GET / HTTP/1.0 Host: virtualhost.example.com <Enter> <Enter>
Jádro jsem updatoval až po Apache. (Právě kvůli takovému podezření.) Jenže před updatem i po něm to bylo stejné. Příkaz top ukazuje, že zamrzlé procesy jsou ve stavu R. Z nějakého důvodu je ovšem nelze zabít ani pomocí kill -9.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4035 nobody 25 0 21228 8372 2276 R 99.4 2.9 0:25.39 httpd
S každým dalším HTTP dotazem přibude další httpd. (Až do maximálního počtu procesů, které smí httpd vytvářet.) Procesor si mezi sebou dělí spravedlivě, avšak bezúčelně.
Předejdu i další možné otázce: Memtest jsem nechal běžet 9 hodin. Nenašel žádnou chybu.
R a nezlikviduje ho 'kill -9', pak IMHO není problém v tom procesu.
Možná není problém v procesu, ale pořád nevím, v čem by být mohl. Ty procesy jsou potomky jednoho httpd - nejspíš toho, který se spustil první. Ten se nezablokuje. Při restartu napřed zkouší zabít své zablokované potomky a zapisuje to do logu. Třikrát pošle SIGTERM. Když to nepomůže, pošle SIGKILL. Jenže ani ten nepomůže. (Tak prostě zůstanou běžet a přežijí dál.) (Zabíjení pomocí kill samozřejmě taky nepomáhá.)
Je to pravda. Týká se to i Courier-MTA, jak jsem zjistil. Problém není v Apachi, ale v novém distribučním kernelu. Vždy o důvod víc, proč si zkompilovat vlastní. Teprve během dneška jsem našel tohle. (Jinak bych tu s tím neotravoval.)
Zkusím zkompilovat vlastní kernel nebo sehnat starší a pak se uvidí. Předpokládám, že tím problém prostě zmizí.
Chyba v kernelu je to poslední, na co bych býval vsadil, ale asi už to tak bude...
Problém není v Apachi, ale v novém distribučním kernelu. Vždy o důvod víc, proč si zkompilovat vlastní.
To není tak jednoznačné. Distribuční jádra jsou obecně testována více než vanilla a při současném vývojovém modelu řady 2.6 to platí dvojnásob (zejména u 2.6.x). Samozřejmě se může stát, že distribuční patche zavlečou do jádra chybu, která ve vanilla stromu nebyla, ale obráceně je to pravděpodobnější.
Konkrétně u ArchLinuxu bych nesázel na to, že distribuční jádra budou lepší než Vanilla...
Násilně vypnut byl mnohokrát. Pak byl vždy nabootován z CD a proveden e2fsck na všechny oddíly.
PHP skripty neobsahovaly nic nekompatibilního nebo zastaralého. Kromě toho nefungují ani statické stránky.
Asi ten downgrade budu muset udělat, i když se toho poněkud děsím... Nic jiného prostě nezbývá. Jenže kdyby to byl opravdu nový problém s Apachem, už by toho byl plný Google... Jenže ono pořád nic.
18.9.2007 12:46
cooler | skóre: 19
| Medzilaborce
Tiskni
Sdílej:
