Debian 9.5 (diskuse)

[xxl]

Při upgradu xen server (Dom0) nenaběhl. Totéž virtuální servery (DomU). Po bootu s předchozím kernelem to zase chodí.

Nový kernel je 4.9.110-1 z balíčku linux-image-4.9.0-7-amd64, starý fungující je 4.9.88-1+deb9u1 z balíčku linux-image-4.9.0-6-amd64. Dál jsem to nezkoumal.

[Lubos Kopecky]

na to jsem tez narazil - prvni verze 4.9.0-7 nebootovala na dom0 vubec, pote udelali update a zacla bootovat a az pak v prubehu nastal crash, domU crash hned; zda se tedy, ze na xen to nikdo nemohl otestovat;

da se nejak nasmerovat pygrub, aby domU bootovalo pres pygrub az z druheho radku a tedy zvolilo 4.9.0-6?

[MP]

Muzete tomu vnutit primo kernel v konfiguraci domU ne (musi pak byt na dom0)? Pochybuju, ze pygrub bude resit poradi radku grubu ve VM.

[GeorgeWH]

pygrub berie grub config z domU, takze sa to da normanle nastavit.

[Lubos Kopecky]

a jakym parametrem pres pygrub reknu, jaky radek ma pouzit? nebo nastavenim se mysli uprava konfigu grubu v domU, aby pouzil az pozdejsi volbu?

[GeorgeWH]

nebo nastavenim se mysli uprava konfigu grubu v domU, aby pouzil az pozdejsi volbu?

ano

[Lubos Kopecky]

ale to pak musim mit na dom0 vsechny potrebny kernely, az moduly se nacitaji primo z vps, pokud si dobre pamatuju, a pri aktualizaci jadra se musi pak aktualizovat tenhle konfigurak a i moduly na serveru + vsechny stroje se musi vypnout a zapnout, aby se natahla nova konfigurace, samotny reboot nestaci, pri vetsim poctu serveru znacna komplikace...

[Lubos Kopecky]

docasne reseni je pridani

pti=off

jako parametr jadru, viz https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1616465.html, ve 4.9.112 to je jiz opraveno (deb instali 4.9.110)

[xxl]

Potrvrzuji, že s pti=off DomU hosty bootují. Dom0 jsem dosud nezkoušel.

[Lubos Kopecky]

ve stretch-proposed-updates/main jiz je nova verze 4.9.110-2 opravujici tuto chybu (testovano zatim jen na domU)

[Lubos Kopecky]

s novou verzi jadra bootuje dom0 take v poradku

[rpajik]

Zrušená podpora http2 v kombinaci s mpm_prefork je taky vtipná.

apache2 (2.4.25-3+deb9u5) stretch; urgency=medium

* Upgrade mod_http and mod_proxy_http2 to the versions from 2.4.33. This fixes - CVE-2018-1302: mod_http2: Potential crash w/ mod_http2 - Segfaults in mod_http2 (Closes: #873945) - mod_http2 issue with option "Indexes" and directive "HeaderName" (Closes: #850947) Unfortunately, this also removes support for http2 when running on mpm_prefork. * mod_http2: Avoid high memory usage with large files, causing crashes on 32bit archs. Closes: #897218 * Make the apache-htcacheclean init script actually look into /etc/default/apache-htcacheclean for its config. Closes: #898563

[trekker.dk]

No, na prvním místě bych se spíš zabýval otázkou, jestli je dobrý nápad používat prefork - spolehlivě nejpomalejší a nejméně efektivní způsob, jak Apache provozovat.

[rpajik]

Třeba kvůli php ?

Jistě, dnes je moderní používat fpm. Ale když si vzpomenu kolikrát jsem už řešil, že fpm s nějakým kódem nebo modulem házelo seqfault, jak se taková věc blbě debuguje a že se ten problém téměř ve 100% vyřešil přepnutím na mod_php .....

[trekker.dk]

No, moderní to je, protože prefork mpm je neefektivní a asi tak šestkrát pomalejší než worker a event. A debuguje se to snadno, stačí PHP nastavit, aby po sobě nechávalo core dump, a ten pak předhodit gdb.

Ale samozřejmě proti gustu žádný dišputát, jak se říká. Akorát se holt nemůžete moc divit, když používáte zastaralé nastavení a jeho podpora by škodila té většině lidí, co už inovovali.

[rpajik]

mod_php vs fpm je z pohledu rychlosti +- nastejno. Ano, pro kvanta statického obsahu je vhodnější worker nebo event. Nebo ještě lépe úplně jiný webserver než apache.

Nemyslím si, že je vhodné takto zásadní zásah do distribuce udělat v minor releasu. Je to hodně proti myšlence samotného fungování této distribuce.

[Leinad]

Debian má hodně vysoko důraz na bezpečnost a z popisu výše vypadá, že by se to nerozbilo nebýt bezpečnostní chyby