Ich habe ein nerviges Problem mit dem Rechner meiner Mutter (Linux Mint 19.2). Es kam jetzt ein paar Mal vor (und jetzt zweimal hintereinander), dass ihr Drucker nicht mehr ging. Das Problem ist, dass das in 80% der Fälle an der Nutzerin liegt, so dass es schwer fällt, die 20% dann Ernst zu nehmen ;-)
Der Anlass dafür, dass CUPS nicht startet, ist, dass die Datei /etc/cups/cupsd.conf von irgendetwas überschrieben wurde und jetzt nur noch
/etc/cups$ sudo cat cupsd.conf.bak PreserveJobFiles Yes
enthält. Auf Grund irgendeiner Lösung hatte ich festgestellt, dass es an dieser Konfigurationsdatei liegt und der Server wieder startet, wenn ich eine andere, ausgefüllte (mit knapp 5kB) an ihre Stelle kopiere. Anschließend funktioniert es wieder, nun musste ich aber feststellen, dass die Datei nach zwei oder drei Tagen schon wieder überschrieben wurde.
Mein Verdacht war, dass dies beim automatischen Update irgendeines Pakets passiert (ich muss z.B. auf meinem Laptop nach jedem Kernel-Update das Wlan-Modul neu kompilieren), aber laut etckeeper-Log ist in der fraglichen Zeit gar nichts passiert.
Kann ich irgendwie herausfinden, *wer* zuletzt eine bestimmte Datei überschrieben hat (Besitzer ist natürlich root)?
Ich würde es gerne vermeiden, immer wieder zu diesen Notfalleinsätzen gerufen zu werden (immerhin habe ich jetzt zuverlässigen Terminal-Zugriff über SSH auf ihren Rechner).
Urs
Am 14.11.2019 17:01, schrieb Urs Liska:
Ich habe ein nerviges Problem mit dem Rechner meiner Mutter (Linux Mint 19.2). Es kam jetzt ein paar Mal vor (und jetzt zweimal hintereinander), dass ihr Drucker nicht mehr ging. Das Problem ist, dass das in 80% der Fälle an der Nutzerin liegt, so dass es schwer fällt, die 20% dann Ernst zu nehmen ;-)
Der Anlass dafür, dass CUPS nicht startet, ist, dass die Datei /etc/cups/cupsd.conf von irgendetwas überschrieben wurde und jetzt nur noch
/etc/cups$ sudo cat cupsd.conf.bak PreserveJobFiles Yes
Eventuell sehr trivial aber mal chmod 440 probiert ?
enthält. Auf Grund irgendeiner Lösung hatte ich festgestellt, dass es an dieser Konfigurationsdatei liegt und der Server wieder startet, wenn ich eine andere, ausgefüllte (mit knapp 5kB) an ihre Stelle kopiere. Anschließend funktioniert es wieder, nun musste ich aber feststellen, dass die Datei nach zwei oder drei Tagen schon wieder überschrieben wurde.
Mein Verdacht war, dass dies beim automatischen Update irgendeines Pakets passiert (ich muss z.B. auf meinem Laptop nach jedem Kernel-Update das Wlan-Modul neu kompilieren), aber laut etckeeper-Log ist in der fraglichen Zeit gar nichts passiert.
Kann ich irgendwie herausfinden, *wer* zuletzt eine bestimmte Datei überschrieben hat (Besitzer ist natürlich root)?
im prinzip schon https://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-... (noch nicht selber getestet)
Ich würde es gerne vermeiden, immer wieder zu diesen Notfalleinsätzen gerufen zu werden (immerhin habe ich jetzt zuverlässigen Terminal-Zugriff über SSH auf ihren Rechner).
Du könntest einen cronjob machen der die datei jede stunde neue dahin copiert.
Bei besonders hartnäckigen Kandidaten wäre appamor eine Idee.
re, wh
On Thu, Nov 14, 2019 at 06:01:27PM +0100, walter harms wrote:
Am 14.11.2019 17:01, schrieb Urs Liska:
Ich habe ein nerviges Problem mit dem Rechner meiner Mutter (Linux Mint 19.2) [...]
Eventuell sehr trivial aber mal chmod 440 probiert ?
Problem ist, dass es meist Root-Prozesse sind, die einem da Streiche spielen.
Mein Lieblingsmittel ist da noch ein chattr -i, später in den Logs gucken, wer jammert: das ist meist der Spassvogel.
Aber audit ist natürlich präziser (dafür eine grössere Maschine).
Viel Spass, lg -- t
Am Donnerstag, 14. November 2019 19:06 CET, tomas@tuxteam.de schrieb:
On Thu, Nov 14, 2019 at 06:01:27PM +0100, walter harms wrote:
Am 14.11.2019 17:01, schrieb Urs Liska:
Ich habe ein nerviges Problem mit dem Rechner meiner Mutter (Linux Mint 19.2) [...]
Eventuell sehr trivial aber mal chmod 440 probiert ?
Problem ist, dass es meist Root-Prozesse sind, die einem da Streiche spielen.
Mein Lieblingsmittel ist da noch ein chattr -i, später in den Logs gucken, wer jammert: das ist meist der Spassvogel.
Aber audit ist natürlich präziser (dafür eine grössere Maschine).
Das audit-framework ist natürlich das Tool der Wahl (auditctl -w /etc/cups/cupsd.conf), will aber erst einmal installiert und aktiviert werden (braucht einen Reboot).
Für mich riecht das nach einem Script welches die cupsd.conf verändern will - also testen ob die Konfigurationsoption schon gesetzt ist (grep PreserveJobFiles /etc/cups/cupsd.conf), und falls nicht wird er der Datei hinzugefügt. Wahrscheinlich wollte da jemand 'echo "PreserveJobFiles Yes" >> /etc/cups/cupsd.conf' machen und hat anstelle von '>>' ein einfaches '>' getippt. Soll vorkommen. Hmm, klingt nach einem PostInstall- Script ... hast Du vor kurzem ein Update gemacht. Allerdings: das PostInstall-Script wird nur mehrfach ausgeführt wenn der Install fehlschlägt. Das sollte sich in den Logfiles (/var/log/dpkg.log etc.) finden.
Gruss RalfD
Viel Spass, lg -- t
Hallo Ralf, danke für die Hinweise.
Das mit echo > statt echo >> klingt sehr plausibel (und wäre die konkrete Erklärung für meine vage Ahnung). Allerdings müssten ja updates, die ich im dpkg-Log finden kann, auch ihre Spuren in der git-History von etckeeper hinterlassen haben, oder nicht? Und da sind keine Commits im fraglichen Zeitraum vorhanden. Manuelle Updates habe ich nicht gemacht, die etckeeper vielleicht hätten umgehen können.
Ich schau's mir trotzdem nochmal an, wenn ich Zugriff habe (im Moment scheint der PC nicht an zu sein).
HG Urs
Am 14.11.19 um 23:20 schrieb Ralf Mattes:
Am Donnerstag, 14. November 2019 19:06 CET, tomas@tuxteam.de schrieb:
On Thu, Nov 14, 2019 at 06:01:27PM +0100, walter harms wrote:
Am 14.11.2019 17:01, schrieb Urs Liska:
Ich habe ein nerviges Problem mit dem Rechner meiner Mutter (Linux Mint 19.2) [...]
Eventuell sehr trivial aber mal chmod 440 probiert ?
Problem ist, dass es meist Root-Prozesse sind, die einem da Streiche spielen.
Mein Lieblingsmittel ist da noch ein chattr -i, später in den Logs gucken, wer jammert: das ist meist der Spassvogel.
Aber audit ist natürlich präziser (dafür eine grössere Maschine).
Das audit-framework ist natürlich das Tool der Wahl (auditctl -w /etc/cups/cupsd.conf), will aber erst einmal installiert und aktiviert werden (braucht einen Reboot).
Für mich riecht das nach einem Script welches die cupsd.conf verändern will - also testen ob die Konfigurationsoption schon gesetzt ist (grep PreserveJobFiles /etc/cups/cupsd.conf), und falls nicht wird er der Datei hinzugefügt. Wahrscheinlich wollte da jemand 'echo "PreserveJobFiles Yes" >> /etc/cups/cupsd.conf' machen und hat anstelle von '>>' ein einfaches '>' getippt. Soll vorkommen. Hmm, klingt nach einem PostInstall- Script ... hast Du vor kurzem ein Update gemacht. Allerdings: das PostInstall-Script wird nur mehrfach ausgeführt wenn der Install fehlschlägt. Das sollte sich in den Logfiles (/var/log/dpkg.log etc.) finden.
Gruss RalfD
Viel Spass, lg -- t
On 11/14/19 6:01 PM, walter harms wrote:
Am 14.11.2019 17:01, schrieb Urs Liska:
Kann ich irgendwie herausfinden, *wer* zuletzt eine bestimmte Datei überschrieben hat (Besitzer ist natürlich root)?
im prinzip schon https://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-... (noch nicht selber getestet)
Genau mit dem Link habe ich mal rausbekommen, was meine /etc/resolv.conf überschreibt. Funktioniert prima. (Natürlich bekommt man damit nicht nachträglich raus, wer das war ...)
FTR: https://bugs.debian.org/767071#38
Liebe Grüße Uwe
-
Ralf Mattes -
tomas＠tuxteam.de -
Urs Liska -
Uwe Kleine-König -
walter harms