[Eisfair] Bericht v. grossen Update, paar Unpaesslichkeiten, manche sind behebbar, andere nicht

[D. Oezbilen]

Hallo @all,

ich gebe mit Bezug auf mein vorheriges Posting

	Ein Hoch auf die Entwickler, Bericht v. grossen Update, > 1000 Pakete, 
 > 2,6 GB an Dateien

hier wieder, was mir nach diesem Update auffiel, was leicht unrund war 
und wie man diese Meldungen weg kriegt, bereinigt.

*1) gkrellmd*
Hier war ein Bezug auf

	/usr/lib64/libsensors.so.4.4.0: cannot open 
`/usr/lib64/libsensors.so.4.4.0' (No such file or directory)

diese aber deinstalliert wurde. Dafuer kam eine

	/usr/lib64/libsensors.so.5.0.0

Ein

	ln -s /usr/lib64/libsensors.so.5.0.0 /usr/lib64/libsensors.so.4

hat wieder einen funktionalen Zustand geschaffen.
Marcus hat das Paket schon ueberarbeitet.

*2)* Invalid or unreadable path specified for ssl_ca_path. at 
/usr/lib/perl5/vendor_perl/5.30.1/XML/Stream.pm line 641.

Das kann ich *nicht* einordnen, auch nicht, ob etwas (was?) 
dysfunktional wird/wurde.

*3) capi2text*
+
*4)  Starting php7-fpm ...*

sind wohl beide v. libgcrypt.so abhaengig.

Denn capi2text war die u.a. Meldung aus, php7-fpm wollte gar nicht starten.

ibgcrypt selftest: binary  (0): No such file or directory 
(/usr/lib64/.libgcrypt.so.20.hmac)
Ohhhh jeeee: ... this is a bug (global.c:150:global_init)

Also suchte ich diese Datei. Abgelegt war eine solche Datei unter 
/usr/lib auf der alten Maschine. Obwohl beide Pakete

    3. i  S: 3.0.2      libgcrypt20-hmac - GCrypt-HMAC for FIPS-140-2 
integrity                                     2021-04-10
    4. i  S: 3.0.2      Library: gcrypt - 20 - Crypto library 
                                            2021-04-10


installiert waren und auch *nochmal* ich nachinstallierte, der Zustand 
war immer noch dysfunktional bei php7-fpm, folglich auch fuer Roundcube.

capi2text zeigte die Anrufe auf dem S0 Bus an.

Mit set -x in /etc/init.d/php7-fpm
konnte ich erkennen, dass auch php7-fpm eine Abhaengigkeit gen 
libgcrypt20 hatte.

Gestartet wird php7-fpm so:

loadproc /usr/sbin/php7-fpm --daemonize --fpm-config 
/etc/php7/php7-fpm.conf -c /etc/php7/fpm/php.ini --pid /run/php7-fpm.pid

Wenn .libgcrypt.so.20.hmac nicht vorhanden ist, ist halt nix mit Starten.

Da die Nachinstallation der Pakete bei  mir nicht half, suchte ich, 
was/warum.

.libgcrypt.so.20.hmac wird mit fipshmac errechnet, fipshmac schreibt die 
*.hmac im selben Verzeichnis wie die lib, also unter /usr/lib64.

fipshmac usr/lib64/libgcrypt.so.20 legt die fehlende Datei an. So 
einfach. :-)

Danach waren die o.a. Meldungen v. capi2text weg, php7-fpm startete, 
ebenso war dann auch RC wieder funktional.

*5) logger*: socket /dev/log: No such file or directory
BFB verursacht das mit/auch?

/etc/init.d/brute_force_blocking stop
logger: socket /dev/log: No such file or directory

*6) udevd*[2904]: specified group 'plugdev' unknown

Holger schrieb dazu:
bekannt, unbedenklich, wird mit dem naechsten updatew von libfido2
behoben

7) bind9 ist zeimlich traege, manche Webseite, die vorher im Nu im 
Borwser waren (heise.de) kann man zuschauen, wie der Browser die 
Webseite aufbaut, manche (zdf.de) gehen in einen timeout.

Und es werden viele

08-May-2021 13:22:50.816 lame-servers: timed out resolving 
'ns01.zdf.de/AAAA/IN': 141.1.1.1#53
08-May-2021 13:22:50.816 lame-servers: timed out resolving 
'ns02.zdf.de/AAAA/IN': 141.1.1.1#53
08-May-2021 13:22:50.880 lame-servers: timed out resolving 
'ns7-66.akam.net/AAAA/IN': 141.1.1.1#53
08-May-2021 13:22:50.880 lame-servers: timed out resolving 
'ns1-240.akam.net/AAAA/IN': 141.1.1.1#53
08-May-2021 13:22:50.880 lame-servers: timed out resolving 
'ns7-66.akam.net/A/IN': 141.1.1.1#53
08-May-2021 13:22:50.880 lame-servers: timed out resolving 
'ns5-65.akam.net/AAAA/IN': 141.1.1.1#53

Meldungen ausgegeben, die confgi erlaubt nur,diese Meldungen 
auszublenden, doch das Probelm laesst sich so nicht beheben. Ebenso ist 
die dig-Ausgabe mehr als kastriert, dauert lange und ist viel geringer 
im Umfang als zuvor, auf der alten Maschine.
Wer mir hier helfen kann, pls.,

Mehr ;-) war nicht. Sprich, man kann (fast) unbesorgt ein update all 
anstossen und nach ca. 40 min bei einem Umfang v. 2,6 GB und > 1000 
Pakete hat man eine umgedrehte Einheit, die bis auf kleine 
Unpaesslichkeiten Ok ist.

Die Bind9-Problematik will ich nicht kleinreden, doch wahrscheinlich ist 
das doch beherrschbar, we will see.

Natuerlich sollte man als Feigling ;-) (noch dazu in der virt. Umgebung) 
eine Komplett-Sicherung (ausser evtl. /home und natuerlich einem 
abgestelltem mail-Paket, zumindest dann /var/spool/mail mitsichern, wenn 
nicht OK laeuft) der virt. HD haben.

Gruss
Oez.

PS: Unter Linux hat man noch eine Chance auf diese Ansagen zu reagieren, 
weil asugegeben wird, was net funkt. Bei win32/x64 hat meinen einen 
ominoesen Errorcode, der auch im Eventlog nicht besser dargestellt wird.