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