Apache Fehlermeldung beim Booten/Konfigurtaions aktualisieren

[B. Sprenger]

Hallo zusammen,
ich muss gerade nach einem Plattenschaden den Eisfair neu aufsetzen.
Der Schaden war grösser, so dass auch die letzten Backups korrupt sind.
Also komplette Neuinstallation.
Bin gerade dabei die Pakete neu zu installieren.

Dabei bekomme ich jetzt folgende Fehlermeldung:

failed to start Disk Cache Cleaning Daemon for Apache HHTP-Server
see systemctl ...

Das ergibt folgendes:
systemctl status apache2-htcacheclean
× apache2-htcacheclean.service - Disk Cache Cleaning Daemon for Apache
HTTP Server
Loaded: loaded
(/usr/lib/systemd/system/apache2-htcacheclean.service; enabled; preset:
disabled)
Active: failed (Result: exit-code) since Wed 2024-01-24 12:21:37
CET; 4min 52s ago
Docs: https://httpd.apache.org/docs/2.4/programs/htcacheclean.html
Process: 440 ExecStart=/usr/sbin/htcacheclean -d
$HTCACHECLEAN_DAEMON_INTERVAL -p $HTCACHECLEAN_PATH -l $HTCACHEC>
CPU: 1ms

Jan 24 12:21:37 Sprengerserver htcacheclean[440]:
status, entity version, date, expiry, request time,
Jan 24 12:21:37 Sprengerserver htcacheclean[440]:
response time, body present, head request.
Jan 24 12:21:37 Sprengerserver htcacheclean[440]:
Should an URL be provided on the command line, the URL will be
Jan 24 12:21:37 Sprengerserver htcacheclean[440]:
deleted from the cache. A reverse proxied URL is made up as follows:
Jan 24 12:21:37 Sprengerserver htcacheclean[440]:
http://<hostname>:<port><path>?[query]. So, for the path "/" on the
Jan 24 12:21:37 Sprengerserver htcacheclean[440]:
host "localhost" and port 80, the URL to delete becomes
Jan 24 12:21:37 Sprengerserver htcacheclean[440]:
"http://localhost:80/?". Note the '?' in the URL must always be
Jan 24 12:21:37 Sprengerserver htcacheclean[440]:
specified explicitly, whether a query string is present or not.
Jan 24 12:21:37 Sprengerserver systemd[1]:
apache2-htcacheclean.service: Failed with result 'exit-code'.
Jan 24 12:21:37 Sprengerserver systemd[1]:
Failed to start Disk Cache Cleaning Daemon for Apache HTTP Server.


Letztlich bringt mich das auch nicht weiter.
Der Daemon startet wohl nicht.
Wie kann ich jetzt die Ursache herausfinden und den Fehler beheben?
Liegt das an der Apache-Konfiguration? Die habe ich nämlich aus dem
Backup übernommen.
Aber eigentlich kann ich da keinen Fehler finden.
Idden?
LG
Boris

[B. Sprenger]

Am 24.01.2024 um 12:31 schrieb B. Sprenger:
>
> Hallo zusammen,
> ich muss gerade nach einem Plattenschaden den Eisfair neu aufsetzen.
> Der Schaden war grösser, so dass auch die letzten Backups korrupt sind.
> Also komplette Neuinstallation.
> Bin gerade dabei die Pakete neu zu installieren.
>
> Dabei bekomme ich jetzt folgende Fehlermeldung:
>
> failed to start Disk Cache Cleaning Daemon for Apache HHTP-Server
> see systemctl ...

OKay, konnte den Fehler selbst beheben.
Ganz banal:
Ich hatte die Festplatten noch nicht komplett eingebunden.
Irgendwo ist da anscheinend ein Pfad definiert, denn es noch nicht gab.
Jetzt gibt es ihn und der Daemon startet..

[Marcus Röckrath]

Haööp Boris,

B. Sprenger wrote:

> OKay, konnte den Fehler selbst beheben.
> Ganz banal:
> Ich hatte die Festplatten noch nicht komplett eingebunden.
> Irgendwo ist da anscheinend ein Pfad definiert, denn es noch nicht gab.
> Jetzt gibt es ihn und der Daemon startet..

Benutzt du eine vom Standard abweichende Partitonierung?

Welcher Pfad war nicht eingebunden?

--
Gruß Marcus
[eisfair-Team]

[B. Sprenger]

Hallo Marcus,> Haööp Boris,

Der Fehler ist wieder da...
Apache funktioniert irgendwie auch nicht richtig (Eror 404 im Browser).

Eigentlich Standard-Konfiguration, ausser dass ich bei der Installation
keine Datenpartition angelegt habe, da die Daten auf anderen Platten
verteilt sind.
Ist das der Fehler?

Mach jetzt erst mal Schluss.
Der Rest scheint erst mal zu wieder zu funktionieren.

[Marcus Röckrath]

Hallo Boris,

B. Sprenger wrote:

>> Benutzt du eine vom Standard abweichende Partitonierung?
>>
>> Welcher Pfad war nicht eingebunden?
>>
> Der Fehler ist wieder da...
> Apache funktioniert irgendwie auch nicht richtig (Eror 404 im Browser).
>
> Eigentlich Standard-Konfiguration, ausser dass ich bei der Installation
> keine Datenpartition angelegt habe, da die Daten auf anderen Platten
> verteilt sind.
> Ist das der Fehler?

Ich habe auch zwei von 3 Installationen ohne Datenpartition oder mit
sonstwie weiteren eingebundenen Platten.

Bitte poste mal die Ausgabe von

mount

Gibt es das Verzeichnis /var/lib/apache/diskcache?

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Boris,

Marcus Röckrath wrote:

> Bitte poste mal die Ausgabe von
>
> mount
>
> Gibt es das Verzeichnis /var/lib/apache/diskcache?

Wenn der nicht startet, kannst du auch auf der Kommandozeile

/usr/sbin/htcacheclean -d 120 -p /var/lib/pache/diskcache -l 300M -n

ausführen. Entweder kommt sofort wieder der Prompt (erfolgreich gestartet;
müsste man dann mit kill wieder stoppen) aus eine längere Ausgabe an deren
Anfang der Fehler beannt werden müsste.

--
Gruß Marcus
[eisfair-Team]

[B. Sprenger]

Hallo Marcus,
es ist sehr merkwürdig: nach einem Reboot heute morgen hat es
funktioniert und auch der Apache läuft.

Am 24.01.2024 um 18:16 schrieb Marcus Röckrath:

>
> Bitte poste mal die Ausgabe von
>
> mount

Bitteschön:
Sprengerserver # mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs
(rw,nosuid,size=4096k,nr_inodes=499560,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs
(rw,nosuid,nodev,size=804596k,nr_inodes=819200,mode=755)
cgroup2 on /sys/fs/cgroup type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
configfs on /sys/kernel/config type configfs
(rw,nosuid,nodev,noexec,relatime)
/dev/sda3 on / type ext4 (rw,relatime,errors=remount-ro)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=740)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
none on /run/credentials/systemd-sysctl.service type ramfs
(ro,nosuid,nodev,noexec,relatime,mode=700)
fusectl on /sys/fs/fuse/connections type fusectl
(rw,nosuid,nodev,noexec,relatime)
none on /run/credentials/systemd-tmpfiles-setup-dev.service type ramfs
(ro,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /var/lock type tmpfs
(rw,nosuid,nodev,size=804596k,nr_inodes=819200,mode=755)
tmpfs on /var/run type tmpfs
(rw,nosuid,nodev,size=804596k,nr_inodes=819200,mode=755)
/dev/vdb on /home type ext4 (rw,relatime,errors=remount-ro)
/dev/vda on /data/hd type ext4 (rw,relatime,errors=remount-ro)
/dev/sdb on /data/ssd type ext4 (rw,relatime,errors=remount-ro)
/dev/sda1 on /boot type ext4 (rw,relatime,errors=remount-ro)
none on /run/credentials/systemd-tmpfiles-setup.service type ramfs
(ro,nosuid,nodev,noexec,relatime,mode=700)
none on /var/run/credentials/systemd-tmpfiles-setup.service type ramfs
(ro,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=402296k,nr_inodes=100574,mode=700)
tmpfs on /var/run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=402296k,nr_inodes=100574,mode=700)
Sprengerserver #

>
> Gibt es das Verzeichnis /var/lib/apache/diskcache?

Nein!
>

Ich habe auch festgestellt, dass die Samba-Freigaben zunächst nicht
erreichbar waren.
Das hat etwa 10 Minuten gedauert.
Heute morgen nach dem Reboot waren sie schneller (ca. 30 Sekunden)
wieder da, aber nicht unmittelbar nach dem Start von Samba.
Ping auf den Server geht natürlich, aber die Freigaben sind nicht
erreichbar.
Wenn ich mir auf der Konsole den Verzeichnisinhalt der Mountpoints
anzeigen lasse ist alles in Ordnung.
Das ist auch irgendwie merkwürdig.

Also im Moment geht es und ich möcht gerade keinen Reboot zum testen machen.
Soll ich das Verzeichnis /var/lib/apache/diskcache anlegen?
Macht in meinen Augen keinen Sinn, da es ja gerade funktioniert....
Das scheint es nicht zu sein.

Andere Ideen?
Oder kann man das ignorieren?

LG
Boris

[Marcus Röckrath]

Hallo Boris,

B. Sprenger wrote:

> Also im Moment geht es und ich möcht gerade keinen Reboot zum testen
> machen. Soll ich das Verzeichnis /var/lib/apache/diskcache anlegen?
> Macht in meinen Augen keinen Sinn, da es ja gerade funktioniert....

Verzeichnis muss vorhanden sein; wird bei einer Apache2-Erstinstallation -
neben weiteren wichtigen Verzeichnissen und anderen Dingen (Rechtevergabe
etc) - angelegt. Bei einem Update wird der Code übersprungen.

Ich denke, wo dein Installationsfehler liegt.

Du hast die aus dem Altsystem "geretteten" Konfigurationsdateien
nach /etc/config.d/ kopiert und erst dann die entsprechenden Pakete
installiert. Korrekt?

Das ist so nicht gut und kann z. B. zu dem festgestellten Fehlverhalten
führen.

Sowohl das Apache2- als auch das Samba-Paket gehen bei Vorhandensein dieser
Konfigurationsdateien davon aus, dass es ein Update und keine
Erstinstallation ist, und unterlassen dann gewisse Dinge!

Das erklärt dann auch deine Beobachtungen, dass sich die Dienste merkwürdig
Verhalten.

Korekterweise wird man ein neues System so aufsetzen, dass man nach dem
Grundsystem zunächst die Pakete installiert, damit eine saubere
"Erstinstallation" durchgeführt wird. Dann kopiert man gesicherte
Konfigurationsdateien ins System und ruft dann die Konfiguration dieser
Pakete im Menu nochmal auf.

Du solltest Samba und Apache2 deinstallieren und nach dem genannten
Verfahren erneut installieren.

Welche konfigurierbaren Pakete hast du noch drauf, dann schaue ich mal, wie
diese zwischen Update und Erstinstallation unterscheiden.

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Boris,

Marcus Röckrath wrote:

> Korekterweise wird man ein neues System so aufsetzen, dass man nach dem
> Grundsystem zunächst die Pakete installiert, damit eine saubere
> "Erstinstallation" durchgeführt wird. Dann kopiert man gesicherte
> Konfigurationsdateien ins System und ruft dann die Konfiguration dieser
> Pakete im Menu nochmal auf.
>
> Du solltest Samba und Apache2 deinstallieren und nach dem genannten
> Verfahren erneut installieren.

Bei Samba könnte es doch etwas anders ablaufe.

Auch wenn du die Konfigurationsdatei vorab in das neue System kopiert hast,
müsste die Samba-Installation als Erstinstallation abgelaufen sein, die
jedoch eine neue Defaultkonfiguration erzeugt und den Hinweis ausgibt, man
müsse Samba noch konfigurieren.

--
Gruß Marcus
[eisfair-Team]

[Alexander Bahlo]

Am Thu, 25 Jan 2024 14:51:40 +0100
schrieb Marcus Röckrath <marcus.r...@gmx.de>:

> Welche konfigurierbaren Pakete hast du noch drauf, dann schaue ich mal, wie
> diese zwischen Update und Erstinstallation unterscheiden.

Dein Support ist wirklich bemerkenswert! Spitze!

Viele Grüße, Alexander.

[B. Sprenger]

Hallo marcus

Am 25.01.2024 um 14:51 schrieb Marcus Röckrath:

> Ich denke, wo dein Installationsfehler liegt.
>
> Du hast die aus dem Altsystem "geretteten" Konfigurationsdateien
> nach /etc/config.d/ kopiert und erst dann die entsprechenden Pakete
> installiert. Korrekt?

Ja allerdings!
Habe eben apache, Samba, LPRNG und MariaDB103 deinstalliert und dann neu
installiert.
Fehlermeldung ist weg.

Ich habe das aber nicht mit allen Pakten so gemacht.
Weiter auf dem System ist folgendes installiert

>
>
> Welche konfigurierbaren Pakete hast du noch drauf, dann schaue ich mal, wie
> diese zwischen Update und Erstinstallation unterscheiden.
>

Folgende Pakete sind dann noch installiert:

1. Haveged Service

2. Nscd Service

3. Perl module handling

4. NTP Service

5. Certs Service

6. Mail Service

7. Power Button

8. Xinetd administration

9. Database server administration

10. rsync daemon

11. Backup-ZIP

12. Update Checker

0. Exit


Ich hoffe das ist unproblematisch.

Vielen Dank für die Hilfe.
Gut das deine Glaskugel gerade nicht zur Reparatur war.

Ich muß noch die Datenbanken von MariaDB wieder hersttellen.
Kann ich einfach Inhalte des Verzeichnis /srv kopieren?

LG
Boris

[Marcus Röckrath]

Hallo Alexander,

Alexander Bahlo wrote:

>> Welche konfigurierbaren Pakete hast du noch drauf, dann schaue ich mal,
>> wie diese zwischen Update und Erstinstallation unterscheiden.
>
> Dein Support ist wirklich bemerkenswert! Spitze!

"Vielen Dank für die Blumen." :-))

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Boris,

B. Sprenger wrote:

>> Ich denke, wo dein Installationsfehler liegt.
>>
>> Du hast die aus dem Altsystem "geretteten" Konfigurationsdateien
>> nach /etc/config.d/ kopiert und erst dann die entsprechenden Pakete
>> installiert. Korrekt?
>
> Ja allerdings!
> Habe eben apache, Samba, LPRNG und MariaDB103 deinstalliert und dann neu
> installiert.
> Fehlermeldung ist weg.

Gut.

> Ich habe das aber nicht mit allen Pakten so gemacht.

Mit welchen denn nicht?

Wenn korrekterweise die Konfigurationsdatei erst nach der Installation ins
System gekommen ist, muss man einmal die Paketkonfiguration aufrufen, damit
deine Altkonfiguration auch aktiv wird.

> Weiter auf dem System ist folgendes installiert

Alle folgenden Einschätzungen sind natürlich ohne Gewähr, da ich das
Installationsverhalten der Pakete nicht bis ins letzte Bit analysieren
kann. :-))

> 1. Haveged Service
> 2. Nscd Service

> 7. Power Button
> 8. Xinetd administration

> 10. rsync daemon
> 11. Backup-ZIP
> 12. Update Checker

Falls Konfigurationdatei nach Installation ins System kopiert wurde, muss
man einmal die Konfiguration aufrufen.


> 3. Perl module handling

Egal, den Menueintrag gibt es nur, um Informationen über Perl-Pakete und die
Doku anzuzeigen. In /etc/config.d habe ich hier keine
perl*-Konfigurationsdatei. Du? elche? Ansonsten alles klar.


> 4. NTP Service

IMHO unkritisch aber wenn Konfigurationsdatei nach der Installation ins
System kopiert wurde, muss einmal die Konfiguration aufgerufen werden.

> 5. Certs Service
> 6. Mail Service

Die Installationsroutine sind so komplex, dass ich hier keine sichere
Einschätzung abgeben kann.

Ich würde hier eher eine Deinstallation, Neuinstallation, Kopieren der
gesicherten Konfiguration und dann Aufruf der Konfiguration vorziehen.

> Gut das deine Glaskugel gerade nicht zur Reparatur war.

Das mit der Glaskugel ist wie der Updatehinweis auf Weihnachten natürlich
ein Running-Gag. In der Regel hilfen nur Infos und Logik. :-)

> Ich muß noch die Datenbanken von MariaDB wieder hersttellen.
> Kann ich einfach Inhalte des Verzeichnis /srv kopieren?

Da wäre ich extrem vorsichtig, kann es aber probieren. Ich gehe aber mit
Sicherheit davon aus, dass User:Group mysql:mysql auf den beiden Systemen
verschiedene UIDs bzw. GIDs haben, da die dynamisch vergeben werden und
damit von der Reihenfolge der Installationen abhängen.

Auf dem neuen System kann man das aber mit chown geradeziehen

chown mysql:mysql <datei>

Es betrifft die Verzeichnisse

/srv/mysql
/srv/mysql-files
/srv/mysql_backup

Aber nicht die Verzeichnisse und Dateien darin, die Root selbst gehören
ändern.

Üblicherweise spielt man nach Konfiguration des Datenbankpaketes die
DB-Backups, zu finden in /srv/mysql_backup/103, über die Restore-Funktion
des Menus wieder ein, sofern du Backups hast. Hierbei sind auch die
mysql-internen-DBs sys und mysql zu restaurieren.

--
Gruß Marcus
[eisfair-Team]

[B. Sprenger]

Hallo Marcus,

Am 26.01.2024 um 12:04 schrieb Marcus Röckrath:

>
>> Ich habe das aber nicht mit allen Pakten so gemacht.
>
> Mit welchen denn nicht?

Das weiss ich natürlich nicht mehr genau,
es sind ja nach der Installation schon ein Paar Standardpakete installiert.

>
> Wenn korrekterweise die Konfigurationsdatei erst nach der Installation ins
> System gekommen ist, muss man einmal die Paketkonfiguration aufrufen, damit
> deine Altkonfiguration auch aktiv wird.
>
>> Weiter auf dem System ist folgendes installiert
>
> Alle folgenden Einschätzungen sind natürlich ohne Gewähr, da ich das
> Installationsverhalten der Pakete nicht bis ins letzte Bit analysieren
> kann. :-))
>
>> 1. Haveged Service
>> 2. Nscd Service
>> 7. Power Button
>> 8. Xinetd administration
>> 10. rsync daemon
>> 11. Backup-ZIP
>> 12. Update Checker
>
> Falls Konfigurationdatei nach Installation ins System kopiert wurde, muss
> man einmal die Konfiguration aufrufen.

Hier war es nur Backup-Zip .
Ich habe natürlich danach die Konfiguration aufgerufen, da es sonst
nicht aktiviert wird.

>
>
>> 3. Perl module handling
>
> Egal, den Menueintrag gibt es nur, um Informationen über Perl-Pakete und die
> Doku anzuzeigen. In /etc/config.d habe ich hier keine
> perl*-Konfigurationsdatei. Du? elche? Ansonsten alles klar.

Nein, Perl wird nicht genutzt.

>
>
>
>> 5. Certs Service
>> 6. Mail Service
>
> Die Installationsroutine sind so komplex, dass ich hier keine sichere
> Einschätzung abgeben kann.

Certs wird nicht benutzt.
Und bei Mail habe ich die Konfigurationsdatei erst nach der Installation
kopiert.

>
> Ich würde hier eher eine Deinstallation, Neuinstallation, Kopieren der
> gesicherten Konfiguration und dann Aufruf der Konfiguration vorziehen.

Habe ich ja mit den oben genannten Paketen gemacht. Derzeit scheint
alles richtig zu funktionieren.

>
>> Ich muß noch die Datenbanken von MariaDB wieder hersttellen.
>> Kann ich einfach Inhalte des Verzeichnis /srv kopieren?
>
> Da wäre ich extrem vorsichtig, kann es aber probieren. Ich gehe aber mit
> Sicherheit davon aus, dass User:Group mysql:mysql auf den beiden Systemen
> verschiedene UIDs bzw. GIDs haben, da die dynamisch vergeben werden und
> damit von der Reihenfolge der Installationen abhängen.
>

> Üblicherweise spielt man nach Konfiguration des Datenbankpaketes die
> DB-Backups, zu finden in /srv/mysql_backup/103, über die Restore-Funktion
> des Menus wieder ein, sofern du Backups hast. Hierbei sind auch die
> mysql-internen-DBs sys und mysql zu restaurieren.

Habe ich gemacht und funktioniert ebenfalls.
Ist das backup automatisch aktiv, oder muss ich das irgendwo konfigurieren?
Ich habe nichts dergleichen gefunden.


LG
Boris

[Marcus Röckrath]

Hallo Boris,

B. Sprenger wrote:

> Habe ich gemacht und funktioniert ebenfalls.
> Ist das backup automatisch aktiv, oder muss ich das irgendwo
> konfigurieren? Ich habe nichts dergleichen gefunden.

Du musst in der mariadb-Konfiguration jede einzelne zu sichernde DB als
BACKUP-Quelle festlegen, einschlisslich der systeminternen mysql und sys.

In der mariadb-Konfiguration gibt es dazu einen Abschniit dessen VAriabvlen
alle mit MARIADB103_BACKUP (Abschnitt Backup settings) beginnen.

Die muss man aktiv einschalten, in deiner Altkonfiguration sollte da aber
was definiert sein, denn sonst hättest du auf dem Altsystem keine Backups
vorfinden können.

--
Gruß Marcus
[eisfair-Team]

[B. Sprenger]

Hallo Marcus,

>
> Du musst in der mariadb-Konfiguration jede einzelne zu sichernde DB als
> BACKUP-Quelle festlegen, einschlisslich der systeminternen mysql und sys.
>
> In der mariadb-Konfiguration gibt es dazu einen Abschniit dessen VAriabvlen
> alle mit MARIADB103_BACKUP (Abschnitt Backup settings) beginnen.
>
> Die muss man aktiv einschalten, in deiner Altkonfiguration sollte da aber
> was definiert sein, denn sonst hättest du auf dem Altsystem keine Backups
> vorfinden können.

Danke, das hatte ich übersehen.
Ein Teil der Datenbanken war tatsächlich im Backup enthalten.
Ich habe das jetzt auf den neuesten Stand gebracht.
Ich hatte so viele Konfigurationsdateien angepackt und das irgendwie
übersehen.
Vielen Dank nochmal.
LG
Boris