unlöschbare Files

[Ralph Stahl]

Moin,

ich habe einen User gelöscht und dabei auch die Dateien mit löschen
lassen. Das ist auch bis auf einen Rest gelungen. Ich versuche es in
einer root-Shell, der gelöschte User hieß rollo:

<schnipp>

root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
insgesamt 36
drwx------ 2 rudi rudi 4096 Sep 23 16:01 .
drwxr-xr-x 3 rudi rudi 4096 Sep 23 16:02 ..
-rw-rw-r-- 1 1000 rollo 1512 Jun 21 13:48 icons.screen0-1792x1039.rc
-rw-rw-r-- 1 1000 rollo 1371 Jun 20 18:10 icons.screen0-1792x1064.rc
-rw-rw-r-- 1 1000 rollo 1469 Jun 28 14:05 icons.screen0-1800x1039.rc
-rw-rw-r-- 1 1000 rollo 1509 Jun 21 13:47 icons.screen0-1904x1039.rc
-rw-rw-r-- 1 1000 rollo 1371 Jun 20 18:10 icons.screen0-1904x1064.rc
-rw-rw-r-- 1 1000 rollo 1455 Jun 19 15:07 icons.screen0-1904x834.rc
-rw-rw-r-- 1 1000 rollo 1366 Jun 20 11:31 icons.screen0-512x439.rc
root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# rm
icons.screen0-1792x1039.rc
rm: das Entfernen von 'icons.screen0-1792x1039.rc' ist nicht möglich:
Vorgang nicht zulässig

</schnipp>

Zunächst mal grundlegendes: Was ist "insgesamt 36"? Bytes? Was sind die
einstelligen Zahlen nach den Rechten (3, 2, 1, 1...)?

Das Problem: Was hindert mich als root daran, die Dateien und letztlich
Verzeichnisse zu löschen? Was kann ich machen? Nun stören mich die paar
Byte nicht wirklich, aber Ordnung muss sein :-).

Wenn ich das als root mit dem mc versuche, kommt als Fehlermeldung
"Vorgang nicht zulässig (1)". Was ist die (1)?

Bitte um Tips, danke!

Ralph

[Claus Reibenstein]

Ralph Stahl schrieb am 23.09.2022 um 16:50:

> ich habe einen User gelöscht und dabei auch die Dateien mit löschen cd .

> lassen. Das ist auch bis auf einen Rest gelungen. Ich versuche es in
> einer root-Shell, der gelöschte User hieß rollo:

War rollo zu diesem Zeitpunkt im System angemeldet? Dann kann es
durchaus sein, dass manche Dateien nicht gelöscht werden konnten.

> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
> insgesamt 36
> drwx------ 2 rudi rudi 4096 Sep 23 16:01 .
> drwxr-xr-x 3 rudi rudi 4096 Sep 23 16:02 ..
> -rw-rw-r-- 1 1000 rollo 1512 Jun 21 13:48 icons.screen0-1792x1039.rc

> [...]

>
> Zunächst mal grundlegendes: Was ist "insgesamt 36"? Bytes? Was sind die
> einstelligen Zahlen nach den Rechten (3, 2, 1, 1...)?

Gib mal "ls -lha" ein. Dann weißt Du, was die 36 bedeutet :-)

Die einstelligen Zahlen sind die Anzahl der Hardlinks, die auf diese
Datei zeigen. Normalerweise, also dann, wenn keine weiteren Hardlinks
angelegt wurden, steht hier bei Dateien 1, bei Verzeichnissen 2 plus die
Anzahl der darin enthaltenen Unterverzeichnisse.

Diese und weitere Details findest Du in den Manualseiten von ls.

> Das Problem: Was hindert mich als root daran, die Dateien und letztlich
> Verzeichnisse zu löschen?

Auch direkt nach einem Neustart des Systems und bei Anmeldung an einer
Textkonsole? Vermutlich werden die Dateien noch von irgendetwas benutzt.

Übrigens: Die Gruppe rollo ist nach wie vor vorhanden. Soll das so sein?

Gruß
Claus

[Andreas Wagner]

Hallo Ralph!

Am Fri, 23 Sep 2022 16:50:05 +0200 schrieb Ralph Stahl:

> Moin,
>
> ich habe einen User gelöscht und dabei auch die Dateien mit löschen
> lassen. Das ist auch bis auf einen Rest gelungen. Ich versuche es in
> einer root-Shell, der gelöschte User hieß rollo:
>
> <schnipp>
>
> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la insgesamt 36
> drwx------ 2 rudi rudi 4096 Sep 23 16:01 .
> drwxr-xr-x 3 rudi rudi 4096 Sep 23 16:02 ..
> -rw-rw-r-- 1 1000 rollo 1512 Jun 21 13:48 icons.screen0-1792x1039.rc
> -rw-rw-r-- 1 1000 rollo 1371 Jun 20 18:10 icons.screen0-1792x1064.rc
> -rw-rw-r-- 1 1000 rollo 1469 Jun 28 14:05 icons.screen0-1800x1039.rc
> -rw-rw-r-- 1 1000 rollo 1509 Jun 21 13:47 icons.screen0-1904x1039.rc
> -rw-rw-r-- 1 1000 rollo 1371 Jun 20 18:10 icons.screen0-1904x1064.rc
> -rw-rw-r-- 1 1000 rollo 1455 Jun 19 15:07 icons.screen0-1904x834.rc
> -rw-rw-r-- 1 1000 rollo 1366 Jun 20 11:31 icons.screen0-512x439.rc
> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# rm
> icons.screen0-1792x1039.rc rm: das Entfernen von
> 'icons.screen0-1792x1039.rc' ist nicht möglich: Vorgang nicht zulässig
>
> </schnipp>

Ich glaube, wenn ls den Namen noch kennt, ist er nicht aus der /etc/passwd
raus. Hast Du "deluser" benutzt?

> Zunächst mal grundlegendes: Was ist "insgesamt 36"? Bytes?

Ich tippe auf die Zahl der Inodes oder 512-Bytes-Blöcke. In DOS hieß das
noch "Zuordnungseinheit", wenn ich nichts durcheinander bringe.

> Was sind die
> einstelligen Zahlen nach den Rechten (3, 2, 1, 1...)?

Ein kleines Experiment:
andreas@andreas-esszimmer:~$ cd sandkasten/
andreas@andreas-esszimmer:~/sandkasten$ ls
andreas@andreas-esszimmer:~/sandkasten$ touch file1
andreas@andreas-esszimmer:~/sandkasten$ ls -alh
insgesamt 8,0K
drwxrwxr-x 2 andreas andreas 4,0K Sep 23 17:55 .
drwxr-x--- 41 andreas andreas 4,0K Sep 23 17:55 ..
-rw-rw-r-- 1 andreas andreas 0 Sep 23 17:55 file1
andreas@andreas-esszimmer:~/sandkasten$ ln file2 file1
ln: auf 'file2' konnte nicht zugegriffen werden: Datei oder Verzeichnis
nicht gefunden
andreas@andreas-esszimmer:~/sandkasten$ ln file1 file2
andreas@andreas-esszimmer:~/sandkasten$ ls -alh
insgesamt 8,0K
drwxrwxr-x 2 andreas andreas 4,0K Sep 23 17:55 .
drwxr-x--- 41 andreas andreas 4,0K Sep 23 17:55 ..
-rw-rw-r-- 2 andreas andreas 0 Sep 23 17:55 file1
-rw-rw-r-- 2 andreas andreas 0 Sep 23 17:55 file2
andreas@andreas-esszimmer:~/sandkasten$

-->> Es ist höchst wahrscheinlich die Zahl der Hard-Links auf diese Datei.

> Das Problem: Was hindert mich als root daran, die Dateien und letztlich
> Verzeichnisse zu löschen? Was kann ich machen? Nun stören mich die paar
> Byte nicht wirklich, aber Ordnung muss sein :-).

Es ist denkbar, dass die Dateien genutzt werden und mit flock() gesperrt
wurden. Werden die Icons noch von jemand anderem genutzt?

> Wenn ich das als root mit dem mc versuche, kommt als Fehlermeldung
> "Vorgang nicht zulässig (1)". Was ist die (1)?

Ich tippe auf den Fehlercode von/vom rm/unlink/whatever/Löschen-Syscall.

Gruß
Andreas

[Claus Reibenstein]

Ralph Stahl schrieb am 23.09.2022 um 16:50:

> drwx------ 2 rudi rudi 4096 Sep 23 16:01 .
> drwxr-xr-x 3 rudi rudi 4096 Sep 23 16:02 ..

Fällt mir gerade auf: Im aktuellen Verzeichnis hat niemand Schreibrecht
außer dem Eigentümer, und das ist weder rollo (den es nicht mehr gibt)
noch root, sondern rudi. Auch darin könnte die Ursache Deines Problems
liegen.

Gruß
Claus

[Claus Reibenstein]

Andreas Wagner schrieb am 23.09.2022 um 18:06:

> Am Fri, 23 Sep 2022 16:50:05 +0200 schrieb Ralph Stahl:
>
>> -rw-rw-r-- 1 1000 rollo 1512 Jun 21 13:48 icons.screen0-1792x1039.rc

¯¯¯¯

> Ich glaube, wenn ls den Namen noch kennt, ist er nicht aus der /etc/passwd
> raus.

Wie Du oben erkennen kannst, ist der User nicht mehr vorhanden, sondern
nur noch die Gruppe. Deshalb steht dort auch kein Name, sondern die ID.

>> Zunächst mal grundlegendes: Was ist "insgesamt 36"? Bytes?
>
> Ich tippe auf die Zahl der Inodes oder 512-Bytes-Blöcke.

Nicht tippen, sondern informieren. "ls -lha" hilft, ebenso "man ls".

> In DOS hieß das
> noch "Zuordnungseinheit", wenn ich nichts durcheinander bringe.

In der deutschen "Übersetzung". Im Englischen heißt es "Cluster"
(Bündel, Büschel).

Gruß
Claus

[Andreas Hartmann]

On 23.09.22 at 16:50 Ralph Stahl wrote:
> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
> insgesamt 36
> drwx------ 2 rudi rudi  4096 Sep 23 16:01 .
> drwxr-xr-x 3 rudi rudi  4096 Sep 23 16:02 ..
> -rw-rw-r-- 1 1000 rollo 1512 Jun 21 13:48 icons.screen0-1792x1039.rc
> -rw-rw-r-- 1 1000 rollo 1371 Jun 20 18:10 icons.screen0-1792x1064.rc
> -rw-rw-r-- 1 1000 rollo 1469 Jun 28 14:05 icons.screen0-1800x1039.rc
> -rw-rw-r-- 1 1000 rollo 1509 Jun 21 13:47 icons.screen0-1904x1039.rc
> -rw-rw-r-- 1 1000 rollo 1371 Jun 20 18:10 icons.screen0-1904x1064.rc
> -rw-rw-r-- 1 1000 rollo 1455 Jun 19 15:07 icons.screen0-1904x834.rc
> -rw-rw-r-- 1 1000 rollo 1366 Jun 20 11:31 icons.screen0-512x439.rc
> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# rm icons.screen0-1792x1039.rc
> rm: das Entfernen von 'icons.screen0-1792x1039.rc' ist nicht möglich: Vorgang nicht zulässig

Was sagt lsattr zu den files?

Gruß
Andreas

[Stefan Reuther]

Am 23.09.2022 um 16:50 schrieb Ralph Stahl:
> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
> insgesamt 36
> drwx------ 2 rudi rudi  4096 Sep 23 16:01 .
> drwxr-xr-x 3 rudi rudi  4096 Sep 23 16:02 ..

[...]

> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# rm
> icons.screen0-1792x1039.rc
> rm: das Entfernen von 'icons.screen0-1792x1039.rc' ist nicht möglich:
> Vorgang nicht zulässig

Was ist das denn für ein Filesystem? In einem normalen Linux-Filesystem
sollte sich root über alle Rechte hinwegsetzen können. In einem anderen
vielleicht nicht, insb. wenn da ein Netzwerk im Spiel ist, und der, der
die Rechte prüft, am anderen Ende vom Kabel sitzt.

Eventuell mit 'chmod a+rwx .' das Verzeichnis komplett schreibbar machen
oder mit 'chown root:root . *' den Besitz von allem übernehmen?

> Wenn ich das als root mit dem mc versuche, kommt als Fehlermeldung
> "Vorgang nicht zulässig (1)". Was ist die (1)?

Der numerische Fehlercode EPERM, der bei deutscher Spracheinstellung als
"Vorgang nicht zulässig" angezeigt wird. In Windows hättest du da einen
8-stelligen Hexcode gesehen ("Fehler 0x800f0922") :)


Stefan

[Bonita Montero]

Am 23.09.2022 um 16:50 schrieb Ralph Stahl:

1 ist EPERM, also hast Du nicht die richtigen Rechte.
Keine Ahnung wieso mc das so bescheuert übersetzt.

[Bonita Montero]

Achso, ich habs:
EACCES ist die Rechte-Verletzung.
EPERM ist nur operation not permitted.

[Bonita Montero]

Hier ist der Unterschied erklärt:
https://stackoverflow.com/questions/35023667/difference-between-eacces-and-eperm
EPERM wird gemeldet wenn Du root sein müsstest und es nicht bist.

[Ralph Stahl]

Am 23.09.22 um 18:01 schrieb Claus Reibenstein:

> Ralph Stahl schrieb am 23.09.2022 um 16:50:
>
>> ich habe einen User gelöscht und dabei auch die Dateien mit löschen cd .
>> lassen. Das ist auch bis auf einen Rest gelungen. Ich versuche es in
>> einer root-Shell, der gelöschte User hieß rollo:
>
> War rollo zu diesem Zeitpunkt im System angemeldet? Dann kann es
> durchaus sein, dass manche Dateien nicht gelöscht werden konnten.

Nein ich bin als root angemeldet. User rollo gibts nicht mehr.

>
>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
>> insgesamt 36
>> drwx------ 2 rudi rudi 4096 Sep 23 16:01 .
>> drwxr-xr-x 3 rudi rudi 4096 Sep 23 16:02 ..
>> -rw-rw-r-- 1 1000 rollo 1512 Jun 21 13:48 icons.screen0-1792x1039.rc
>> [...]
>>
>> Zunächst mal grundlegendes: Was ist "insgesamt 36"? Bytes? Was sind die
>> einstelligen Zahlen nach den Rechten (3, 2, 1, 1...)?
>
> Gib mal "ls -lha" ein. Dann weißt Du, was die 36 bedeutet :-)

Wie vermutet.

>
> Die einstelligen Zahlen sind die Anzahl der Hardlinks, die auf diese
> Datei zeigen. Normalerweise, also dann, wenn keine weiteren Hardlinks
> angelegt wurden, steht hier bei Dateien 1, bei Verzeichnissen 2 plus die
> Anzahl der darin enthaltenen Unterverzeichnisse.
>
> Diese und weitere Details findest Du in den Manualseiten von ls.

Klar, lesen bildet :-).

>
>> Das Problem: Was hindert mich als root daran, die Dateien und letztlich
>> Verzeichnisse zu löschen?
>
> Auch direkt nach einem Neustart des Systems und bei Anmeldung an einer
> Textkonsole? Vermutlich werden die Dateien noch von irgendetwas benutzt.

Ebendst.

> Übrigens: Die Gruppe rollo ist nach wie vor vorhanden. Soll das so sein?

Jetzt nicht mehr, geht trotzdem nicht.

>
> Gruß
> Claus

Ralph

[Ralph Stahl]

Am 23.09.22 um 18:06 schrieb Andreas Wagner:

Nein. Die wurden noch nie benutzt, ich hatte die sie mal selbst als
Backup erzeugt. Sie viel weiter oben mein Faden zum angeblich
vermurksten Desktop.

[Ralph Stahl]

Am 23.09.22 um 18:55 schrieb Andreas Hartmann:

---i---------e------- ./icons.screen0-1904x1064.rc
----i---------e------- ./icons.screen0-512x439.rc
----i---------e------- ./icons.screen0-1904x834.rc
----i---------e------- ./icons.screen0-1800x1039.rc
----i---------e------- ./icons.screen0-1904x1039.rc
----i---------e------- ./icons.screen0-1792x1064.rc
----i---------e------- ./icons.screen0-1792x1039.rc

[Ralph Stahl]

Am 23.09.22 um 19:06 schrieb Stefan Reuther:

> Am 23.09.2022 um 16:50 schrieb Ralph Stahl:
>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
>> insgesamt 36
>> drwx------ 2 rudi rudi  4096 Sep 23 16:01 .
>> drwxr-xr-x 3 rudi rudi  4096 Sep 23 16:02 ..
> [...]
>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# rm
>> icons.screen0-1792x1039.rc
>> rm: das Entfernen von 'icons.screen0-1792x1039.rc' ist nicht möglich:
>> Vorgang nicht zulässig
>
> Was ist das denn für ein Filesystem? In einem normalen Linux-Filesystem
> sollte sich root über alle Rechte hinwegsetzen können. In einem anderen
> vielleicht nicht, insb. wenn da ein Netzwerk im Spiel ist, und der, der
> die Rechte prüft, am anderen Ende vom Kabel sitzt.

Was macht den Ubuntu 22.04, ext4? Ich habe nichts besonderes gewünscht
und alles ist nur lokal.

>
> Eventuell mit 'chmod a+rwx .' das Verzeichnis komplett schreibbar machen
> oder mit 'chown root:root . *' den Besitz von allem übernehmen?

Schön wärs.

[Ralph Stahl]

Am 23.09.22 um 19:06 schrieb Stefan Reuther:

> Am 23.09.2022 um 16:50 schrieb Ralph Stahl:
>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
>> insgesamt 36
>> drwx------ 2 rudi rudi  4096 Sep 23 16:01 .
>> drwxr-xr-x 3 rudi rudi  4096 Sep 23 16:02 ..
> [...]
>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# rm
>> icons.screen0-1792x1039.rc
>> rm: das Entfernen von 'icons.screen0-1792x1039.rc' ist nicht möglich:
>> Vorgang nicht zulässig
>
> Was ist das denn für ein Filesystem? In einem normalen Linux-Filesystem
> sollte sich root über alle Rechte hinwegsetzen können. In einem anderen
> vielleicht nicht, insb. wenn da ein Netzwerk im Spiel ist, und der, der
> die Rechte prüft, am anderen Ende vom Kabel sitzt.
>
> Eventuell mit 'chmod a+rwx .' das Verzeichnis komplett schreibbar machen
> oder mit 'chown root:root . *' den Besitz von allem übernehmen?

[rudi: /home/rollo/.config/xfce4.bak] sudo chown -R root:root desktop.bak
chown: der Eigentümer von 'desktop.bak/icons.screen0-1904x1064.rc' wird
geändert: Vorgang nicht zulässig
...

Wieso wird root nicht rangelassen???

[Kay Martinen]

Am 23.09.22 um 21:51 schrieb Ralph Stahl:

> Am 23.09.22 um 19:06 schrieb Stefan Reuther:
>> Am 23.09.2022 um 16:50 schrieb Ralph Stahl:
>>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
>>> insgesamt 36
>>> drwx------ 2 rudi rudi  4096 Sep 23 16:01 .
>>> drwxr-xr-x 3 rudi rudi  4096 Sep 23 16:02 ..
>> [...]
>>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# rm
>>> icons.screen0-1792x1039.rc
>>> rm: das Entfernen von 'icons.screen0-1792x1039.rc' ist nicht möglich:
>>> Vorgang nicht zulässig
>>
>> Was ist das denn für ein Filesystem? In einem normalen Linux-Filesystem
>> sollte sich root über alle Rechte hinwegsetzen können. In einem anderen
>> vielleicht nicht, insb. wenn da ein Netzwerk im Spiel ist, und der, der
>> die Rechte prüft, am anderen Ende vom Kabel sitzt.
>>
>> Eventuell mit 'chmod a+rwx .' das Verzeichnis komplett schreibbar machen
>> oder mit 'chown root:root . *' den Besitz von allem übernehmen?
>
>
> [rudi: /home/rollo/.config/xfce4.bak] sudo chown -R root:root desktop.bak
> chown: der Eigentümer von 'desktop.bak/icons.screen0-1904x1064.rc' wird
> geändert: Vorgang nicht zulässig
> ...
>
> Wieso wird root nicht rangelassen???

Wer ist denn der Benutzer rudi? Hast du den angelegt und hast das
passwort? Dann wechsele doch mit su mal zum benutzer rudi und versuche
dann das verzeichnis zu übernehmen oder zu löschen.

Oder, hast du das oben eben versucht?

BTW. Bei den meisten Linuxen ist die Benutzer ID 1000 der erste User den
man anlegt, gefolgt von 1001 u.s.w.

Hast du mit dem Benutzer rollo etwas angestellt das evtl. immer noch
läuft? Dann solltest du mal mit 'ps' oder 'top' nach den usern schauen
unter denen was läuft.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Christian Garbs]

Mahlzeit!

Ralph Stahl <po...@rstahl.de> wrote:
> Am 23.09.22 um 18:55 schrieb Andreas Hartmann:
>> On 23.09.22 at 16:50 Ralph Stahl wrote:
>>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
>>> insgesamt 36
>>> drwx------ 2 rudi rudi  4096 Sep 23 16:01 .
>>> drwxr-xr-x 3 rudi rudi  4096 Sep 23 16:02 ..
>>> -rw-rw-r-- 1 1000 rollo 1512 Jun 21 13:48 icons.screen0-1792x1039.rc
>>> -rw-rw-r-- 1 1000 rollo 1371 Jun 20 18:10 icons.screen0-1792x1064.rc
>>> -rw-rw-r-- 1 1000 rollo 1469 Jun 28 14:05 icons.screen0-1800x1039.rc
>>> -rw-rw-r-- 1 1000 rollo 1509 Jun 21 13:47 icons.screen0-1904x1039.rc
>>> -rw-rw-r-- 1 1000 rollo 1371 Jun 20 18:10 icons.screen0-1904x1064.rc
>>> -rw-rw-r-- 1 1000 rollo 1455 Jun 19 15:07 icons.screen0-1904x834.rc
>>> -rw-rw-r-- 1 1000 rollo 1366 Jun 20 11:31 icons.screen0-512x439.rc
>>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# rm icons.screen0-1792x1039.rc
>>> rm: das Entfernen von 'icons.screen0-1792x1039.rc' ist nicht möglich: Vorgang nicht zulässig

>> Was sagt lsattr zu den files?

> ---i---------e------- ./icons.screen0-1904x1064.rc
> ----i---------e------- ./icons.screen0-512x439.rc
> ----i---------e------- ./icons.screen0-1904x834.rc
> ----i---------e------- ./icons.screen0-1800x1039.rc
> ----i---------e------- ./icons.screen0-1904x1039.rc
> ----i---------e------- ./icons.screen0-1792x1064.rc
> ----i---------e------- ./icons.screen0-1792x1039.rc

Na dann ist doch alles klar :-)

Was sagt die lsattr(1)-Manpage dazu?
Lustigerweise nichts, aber sie verweist Dich auch chattr(1).

Da steht die Bedeutung des 'i'.
Mit chattr wirst Du (bzw. root) das 'i' auch wieder los.

Ist das 'i' damit die jetzt zu spät gefundene Ursache für Dein
Desktop-Problem oder hast Du das im Rahmen eines Behebungsversuches
selbst gesetzt?

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
(0>
//\
V_/_ Standard Penguin

[Stefan Froehlich]

On Fri, 23 Sep 2022 19:06:10 Stefan Reuther wrote:
> Am 23.09.2022 um 16:50 schrieb Ralph Stahl:
>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
>> insgesamt 36
>> drwx------ 2 rudi rudi  4096 Sep 23 16:01 .
>> drwxr-xr-x 3 rudi rudi  4096 Sep 23 16:02 ..
> [...]
>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# rm
>> icons.screen0-1792x1039.rc
>> rm: das Entfernen von 'icons.screen0-1792x1039.rc' ist nicht möglich:
>> Vorgang nicht zulässig

> Was ist das denn für ein Filesystem? In einem normalen
> Linux-Filesystem sollte sich root über alle Rechte hinwegsetzen
> können.

Über alles, bis auf immutable; blöderweise vergisst man genau darauf
im Zweifelsfall recht gerne.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - die edelste Erleuchtung des Seins!
(Sloganizer)

[Kay Martinen]

Am 23.09.22 um 22:16 schrieb Christian Garbs:

> Ralph Stahl <po...@rstahl.de> wrote:
>> Am 23.09.22 um 18:55 schrieb Andreas Hartmann:
>>> On 23.09.22 at 16:50 Ralph Stahl wrote:
>>>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
>>>> insgesamt 36
>>>> drwx------ 2 rudi rudi  4096 Sep 23 16:01 .
>>>> drwxr-xr-x 3 rudi rudi  4096 Sep 23 16:02 ..
>>>> -rw-rw-r-- 1 1000 rollo 1512 Jun 21 13:48 icons.screen0-1792x1039.rc
>>>> -rw-rw-r-- 1 1000 rollo 1371 Jun 20 18:10 icons.screen0-1792x1064.rc
>>>> -rw-rw-r-- 1 1000 rollo 1469 Jun 28 14:05 icons.screen0-1800x1039.rc
>>>> -rw-rw-r-- 1 1000 rollo 1509 Jun 21 13:47 icons.screen0-1904x1039.rc
>>>> -rw-rw-r-- 1 1000 rollo 1371 Jun 20 18:10 icons.screen0-1904x1064.rc
>>>> -rw-rw-r-- 1 1000 rollo 1455 Jun 19 15:07 icons.screen0-1904x834.rc
>>>> -rw-rw-r-- 1 1000 rollo 1366 Jun 20 11:31 icons.screen0-512x439.rc
>>>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# rm icons.screen0-1792x1039.rc
>>>> rm: das Entfernen von 'icons.screen0-1792x1039.rc' ist nicht möglich: Vorgang nicht zulässig
>
>>> Was sagt lsattr zu den files?
>
>> ---i---------e------- ./icons.screen0-1904x1064.rc
>> ----i---------e------- ./icons.screen0-512x439.rc
>> ----i---------e------- ./icons.screen0-1904x834.rc
>> ----i---------e------- ./icons.screen0-1800x1039.rc
>> ----i---------e------- ./icons.screen0-1904x1039.rc
>> ----i---------e------- ./icons.screen0-1792x1064.rc
>> ----i---------e------- ./icons.screen0-1792x1039.rc

> Da steht die Bedeutung des 'i'.
> Mit chattr wirst Du (bzw. root) das 'i' auch wieder los.

Da bin ich auch eben erst; durch deinen Hinweis; drüber gestolpert.

Warum sollte man aber solche Dateien bloß immutable und mit extents (zu
denen die man page meint das könne man mit chattr auch nicht entfernen)
markieren?

Immutable hab ich nur EIN mal verwendet, um meine handgeschriebene
resolv.conf vor herumdilettieren von systemd oder resolvconf zu
schützen. Das die mir ständig einen anderen/falschen nameserver
überhelfen wollen hat mich damit zum letzten mal genervt.

> Ist das 'i' damit die jetzt zu spät gefundene Ursache für Dein
> Desktop-Problem oder hast Du das im Rahmen eines Behebungsversuches
> selbst gesetzt?

Gute Frage. Von einem Desktop-Problem hab ich hier noch nix gelesen. War
das evtl. vor einem F'up2 aus einer anderen Gruppe?

[Laurenz Trossel]

On 2022-09-23, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
> On Fri, 23 Sep 2022 19:06:10 Stefan Reuther wrote:
>
>> Was ist das denn für ein Filesystem? In einem normalen
>> Linux-Filesystem sollte sich root über alle Rechte hinwegsetzen
>> können.
>
> Über alles, bis auf immutable; blöderweise vergisst man genau darauf
> im Zweifelsfall recht gerne.

Und das sticky-Flag auf Verzeichnissen. Sieht hier aber nicht so aus als
wäre das ein Problem.

[Kay Martinen]

Am 23.09.22 um 23:37 schrieb Laurenz Trossel:

> On 2022-09-23, Stefan Froehlich <Stefan...@Froehlich.Priv.at> wrote:
>> On Fri, 23 Sep 2022 19:06:10 Stefan Reuther wrote:
>>
>>> Was ist das denn für ein Filesystem? In einem normalen
>>> Linux-Filesystem sollte sich root über alle Rechte hinwegsetzen
>>> können.
>>
>> Über alles, bis auf immutable; blöderweise vergisst man genau darauf
>> im Zweifelsfall recht gerne.

Genau. Darum hab ich das auch nur bei einer Datei gemacht.

> Und das sticky-Flag auf Verzeichnissen.

sticky wird aber prominenter angezeigt, z.b. bei 'ls' und 'mc' zeigt es
m.E. auch. Die attribute sieht man aber normalerweise nur wenn man extra
danach sucht.

[Alexander Schreiber]

Claus Reibenstein <crei...@gmail.com> wrote:
> Ralph Stahl schrieb am 23.09.2022 um 16:50:
>
>> ich habe einen User gelöscht und dabei auch die Dateien mit löschen cd .
>> lassen. Das ist auch bis auf einen Rest gelungen. Ich versuche es in
>> einer root-Shell, der gelöschte User hieß rollo:
>
> War rollo zu diesem Zeitpunkt im System angemeldet? Dann kann es
> durchaus sein, dass manche Dateien nicht gelöscht werden konnten.
>
>> root@tux2:/home/rollo/.config/xfce4.bak/desktop.bak# ls -la
>> insgesamt 36
>> drwx------ 2 rudi rudi 4096 Sep 23 16:01 .
>> drwxr-xr-x 3 rudi rudi 4096 Sep 23 16:02 ..
>> -rw-rw-r-- 1 1000 rollo 1512 Jun 21 13:48 icons.screen0-1792x1039.rc
>> [...]
>>
>> Zunächst mal grundlegendes: Was ist "insgesamt 36"? Bytes? Was sind die
>> einstelligen Zahlen nach den Rechten (3, 2, 1, 1...)?
>
> Gib mal "ls -lha" ein. Dann weißt Du, was die 36 bedeutet :-)
>
> Die einstelligen Zahlen sind die Anzahl der Hardlinks, die auf diese
> Datei zeigen. Normalerweise, also dann, wenn keine weiteren Hardlinks
> angelegt wurden, steht hier bei Dateien 1, bei Verzeichnissen 2 plus die
> Anzahl der darin enthaltenen Unterverzeichnisse.
>
> Diese und weitere Details findest Du in den Manualseiten von ls.
>
>> Das Problem: Was hindert mich als root daran, die Dateien und letztlich
>> Verzeichnisse zu löschen?

Da fallen mir spontan zwei Möglichkeiten ein:
- wenn das ein lokales Dateisystem (ext4, XFS, ...) ist, dann mal
mit lsattr nachsehen ob da immutable gesetzt ist - allerdings
erfordert das Setzen des immutable Attributs root Rechte, also
eher unwahrscheinlich
- wenn das ein NFS Mount ist, dann ist mal schauen ob auf dem Server
no_root_squash für den Export gesetzt ist (root squash: Nutzer
root auf dem Client wird auf Nutzer nobody auf dem Server umgemappt)

> Auch direkt nach einem Neustart des Systems und bei Anmeldung an einer
> Textkonsole? Vermutlich werden die Dateien noch von irgendetwas benutzt.

Das ist Windows Dateisystem API Verhalten, aber nicht Unix. Man kann unter
Unix (so die Rechte passend sind) sehr wohl einem Prozess eine offene
Datei löschen, sie dem Prozess quasi "unterm Hintern wegziehen". Das
entfernt aber in _dem_ Fall erstmal nur den Verzeichniseintrag und nicht
die Datei selber - die wird vom Filesystem abgeräumt sobald der letzte
offene Dateidescriptor darauf geschlossen wird. Ja, es gibt im Prinzip
file locking APIs, aber so richtig funktionieren die IIRC nicht wirklich.

Man liest sich,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison

[Ralph Stahl]

Am 23.09.22 um 22:16 schrieb Christian Garbs:

Das wars, danke! Keine Ahnung, wer oder was das gesetzt hat. Zumal ich
das Backup selber erzeugt habe im Zuge meiner Bemühungen, die scheinbar
falsche Desktopgröße zu beheben (<jm6ve0...@mid.individual.net> und
<jlpjth...@mid.individual.net>). Da habe ich nur was kopiert, weiter
nichts bewusst gemacht...

Frage am Rand: wozu wird das i-Attribut normalerweise benutzt?

Also, jetzt ist der Müll weg. Danke an alle Mitdenker :-).

VG Ralph

[Ralph Stahl]

Am 23.09.22 um 22:05 schrieb Kay Martinen:

Nach der schon gelungenen Lösung: Ich bin User rudi (1002). adm (1000)
und rollo (1001) waren zuerst da und hatte ein xfce4-Problem, das ich
nicht gefunden habe.

[Ulli Horlacher]

Ralph Stahl <po...@rstahl.de> wrote:

> Frage am Rand: wozu wird das i-Attribut normalerweise benutzt?

Zum Dateien schuetzen (vor versehentlichem Loeschen).


--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Ralph Stahl]

Am 24.09.22 um 15:33 schrieb Ulli Horlacher:

> Ralph Stahl <po...@rstahl.de> wrote:
>
>> Frage am Rand: wozu wird das i-Attribut normalerweise benutzt?
>
> Zum Dateien schuetzen (vor versehentlichem Loeschen).
>
>

Das ging schnell. Danke!

[Andreas Wagner]

Hallo Claus!

Am 23.09.2022 um 18:13 schrieb Claus Reibenstein:
> Andreas Wagner schrieb am 23.09.2022 um 18:06:
>
>> Am Fri, 23 Sep 2022 16:50:05 +0200 schrieb Ralph Stahl:
>>
>>> -rw-rw-r-- 1 1000 rollo 1512 Jun 21 13:48 icons.screen0-1792x1039.rc
> ¯¯¯¯
>
>> Ich glaube, wenn ls den Namen noch kennt, ist er nicht aus der /etc/passwd
>> raus.
>
> Wie Du oben erkennen kannst, ist der User nicht mehr vorhanden, sondern
> nur noch die Gruppe. Deshalb steht dort auch kein Name, sondern die ID.

Hoppala, ja, das hatte ich übersehen!

>>> Zunächst mal grundlegendes: Was ist "insgesamt 36"? Bytes?
>>
>> Ich tippe auf die Zahl der Inodes oder 512-Bytes-Blöcke.
>
> Nicht tippen, sondern informieren. "ls -lha" hilft, ebenso "man ls".

In die Map-Page hatte ich reingeschaut. Da habe ich nicht gesehen, wie
das zu interpretieren ist. "ls -alh" und dividieren geht aber. Bei mir
sind es 1K(i?)B-Blöcke, also höchst wahrscheinlich Inodes.

>> In DOS hieß das
>> noch "Zuordnungseinheit", wenn ich nichts durcheinander bringe.
>
> In der deutschen "Übersetzung". Im Englischen heißt es "Cluster"
> (Bündel, Büschel).

Ah, danke!

Gruß
Andreas

[Bonita Montero]

Am 24.09.2022 um 12:47 schrieb Alexander Schreiber:

> Das ist Windows Dateisystem API Verhalten, aber nicht Unix. Man kann unter
> Unix (so die Rechte passend sind) sehr wohl einem Prozess eine offene
> Datei löschen, sie dem Prozess quasi "unterm Hintern wegziehen". Das
> entfernt aber in _dem_ Fall erstmal nur den Verzeichniseintrag und nicht
> die Datei selber - die wird vom Filesystem abgeräumt sobald der letzte
> offene Dateidescriptor darauf geschlossen wird. Ja, es gibt im Prinzip
> file locking APIs, aber so richtig funktionieren die IIRC nicht wirklich.

Funktioniert unter Windows mit FILE_SHARE_DELETE auch, nur nutzt das
keiner. Ich find den Regelfall unter Windows schon ganz o.k., aber
leider kann man nicht für die C-APIs an denen vorbei einen Default,
ggf. für den aktuellen Thread, festlegen. D.h. man muss schon die
Win32-API nutzen um das festzulefen.

[Gerald E¡scher]

Ralph Stahl schrieb am 24/9/2022 15:32:
>
> Nach der schon gelungenen Lösung: Ich bin User rudi (1002). adm (1000)
> und rollo (1001) waren zuerst da und hatte ein xfce4-Problem, das ich
> nicht gefunden habe.

Nun hast du eine wahrscheinliche Ursache für dein xfce4-Problem.

--
Gerald

[Kay Martinen]

Am 24.09.22 um 15:33 schrieb Ulli Horlacher:

> Ralph Stahl <po...@rstahl.de> wrote:
>
>> Frage am Rand: wozu wird das i-Attribut normalerweise benutzt?
>
> Zum Dateien schuetzen (vor versehentlichem Loeschen).

Das müsste er doch JETZT eigentlich selbst wissen. Die Wirkung ist doch
nun auch ihm bekannt (geworden).

Ja, ich bin auch nicht sofort drüber gestolpert. Bei dem EINEN 'i' file
das ich hab...

Aber: Gibt's eigentlich eine schnelle Suchfunktion nach immutable? In
einer Schleife alle dir's und files mit lsattr aufrufen dürfte reichlich
lange dauern - wenn man bei / anfängt und keine excludes hätte/wollte.

[Kay Martinen]

Am 24.09.22 um 18:18 schrieb Gerald E¡scher:

Ein Desktop den man nicht mal eben aus dem ROM (=immutable) starten
könnte taugt ja auch irgendwie nix. :-)

war's nicht auch mal eines der Design-prinzipien, das sich z.B. Inhalte
unter /usr nicht ändern und damit RO sein könnten und alles was RW
braucht eher in /var landet?

Ersteres ermöglichte ja auch erst das Teilen von /usr via nfs mit Thin
Clients.

[Christian Garbs]

Mahlzeit!

Kay Martinen <use...@martinen.de> wrote:

> Warum sollte man aber solche Dateien bloß immutable und mit extents (zu
> denen die man page meint das könne man mit chattr auch nicht entfernen)
> markieren?

Die Extends müssten doch eher ein Feature des Dateisystems sein, oder?

Wenn man bei einem alten ext4 nachträglich per tune2fs die Extends
aktiviert, wirkt das nicht automatisch auf die bestehenden Dateien,
sondern nur auf zukünftig geschriebene. Vermutlich ist lsattr eine
Möglichkeit, bei einer bestehenden Datei zu gucken, ob sie schon mit
Extends geschrieben wurde oder nicht.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Aufgrund der gestiegenen Kosten von Öl und Strom wurde das Licht am
Ende des Tunnels abgeschaltet. Wir bedauern die dadurch entstandenen
Unanehmlichkeiten.

[Peter J. Holzer]

On 2022-09-24 14:25, Andreas Wagner <andreas...@web.de> wrote:
> Am 23.09.2022 um 18:13 schrieb Claus Reibenstein:
>> Andreas Wagner schrieb am 23.09.2022 um 18:06:
>>> Am Fri, 23 Sep 2022 16:50:05 +0200 schrieb Ralph Stahl:
>>>> Zunächst mal grundlegendes: Was ist "insgesamt 36"? Bytes?
>>>
>>> Ich tippe auf die Zahl der Inodes oder 512-Bytes-Blöcke.
>>
>> Nicht tippen, sondern informieren. "ls -lha" hilft, ebenso "man ls".
>
> In die Map-Page hatte ich reingeschaut. Da habe ich nicht gesehen, wie
> das zu interpretieren ist. "ls -alh" und dividieren geht aber. Bei mir
> sind es 1K(i?)B-Blöcke, also höchst wahrscheinlich Inodes.

1KiB-Blöcke stimmt. Inodes ist falsch.

hp

[Helmut Waitzmann]

Kay Martinen <use...@martinen.de>:

> Aber: Gibt's eigentlich eine schnelle Suchfunktion nach
> immutable? In einer Schleife alle dir's und files mit lsattr
> aufrufen dürfte reichlich lange dauern - wenn man bei / anfängt
> und keine excludes hätte/wollte.

Ich vermute, es gibt sie nicht.  Selbst dann, wenn man im
Dateisystem die Möglichkeit hätte, alle Inodes – egal, wo im
Dateisystem sie verwendet werden – nach einander zu untersuchen,
ob sie immutable sind, fehlt immer noch die Möglichkeit, zu
erfragen, wo im Dateisystem sie verwendet werden.  Und dazu gibt
es meines Wissens keine jedenfalls mit den Systemaufrufen
erreichbare Datenbank, in der zu jedem Inode festgehalten ist, in
welchen Verzeichnis‐Inodes welche Verzeichniseinträge zu ihm
gehören.

[Ralph Stahl]

Am 24.09.22 um 18:18 schrieb Gerald E¡scher:

Könnte sein :-), auch wenn die gezeigten Files nur eine Kopie waren. Da
müssten die Originale auch schon vermurkst gewesen sein. Daher kam ja
meine Frage: Wer (welcher Prozess, Vorgang...) hätte das tun sollen? Ich
jedenfalls wars nicht, ich kannte das Attribut bis gestern gar nicht.

[Gerald E¡scher]

Ralph Stahl schrieb am 25/9/2022 11:36:

> Am 24.09.22 um 18:18 schrieb Gerald E¡scher:
>>

>> Nun hast du eine wahrscheinliche Ursache für dein xfce4-Problem.
>>
>
> Könnte sein :-), auch wenn die gezeigten Files nur eine Kopie waren. Da
> müssten die Originale auch schon vermurkst gewesen sein. Daher kam ja
> meine Frage: Wer (welcher Prozess, Vorgang...) hätte das tun sollen? Ich
> jedenfalls wars nicht, ich kannte das Attribut bis gestern gar nicht.

Sicher nicht :-?

Hier ist einmal jemand aufgeschlagen, der hat nachdem WIRME xfce immer
wieder die Plazierung von Icons vergessen hat, nach einem
zweifelhaften, irgendwo gefundenen Hinweis die entsprechenden
Konfigurationsdateien (vermutlich die gleichen wie bei dir) auf
"immutable" gesetzt.
Etwas später hat sich der Typ sich bei den Machern seiner Distribution
lauthals beschwert, weil beim nächsten Distributionsrelease das
Installationsprogramm auf die Nase gefallen ist...


--
Gerald

[Ralph Stahl]

Am 25.09.22 um 17:03 schrieb Gerald E¡scher:

Nee war mir garantiert nicht bekannt. Und für so einen Zweck hätte es
ja auch gereicht, dem User die Schreibrechte wegzunehmen und nicht allen
einschließlich root. Nee nee, das war ich nicht.

[Marc Haber]

Ralph Stahl <po...@rstahl.de> wrote:
>Am 25.09.22 um 17:03 schrieb Gerald E¡scher:

>> Hier ist einmal jemand aufgeschlagen, der hat nachdem WIRME xfce immer
>> wieder die Plazierung von Icons vergessen hat, nach einem
>> zweifelhaften, irgendwo gefundenen Hinweis die entsprechenden
>> Konfigurationsdateien (vermutlich die gleichen wie bei dir) auf
>> "immutable" gesetzt.
>> Etwas später hat sich der Typ sich bei den Machern seiner Distribution
>> lauthals beschwert, weil beim nächsten Distributionsrelease das
>> Installationsprogramm auf die Nase gefallen ist...
>
>Nee war mir garantiert nicht bekannt. Und für so einen Zweck hätte es
>ja auch gereicht, dem User die Schreibrechte wegzunehmen und nicht allen
>einschließlich root. Nee nee, das war ich nicht.

In meiner Welt kenne ich das Immutable-Flag als Werkzeug von
Pfuschern, die zu faul sind, der verwendeten
Konfigurationsmanagement-Software eine Ausnahme beizubringen, und die
deswegen lieber den Kollegen innerhalb der nächsten
Upgrade-Nachtschicht ein Ei in den Korb legen.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Dietz Proepper]

Marc Haber <mh+usene...@zugschl.us> wrote:

> Ralph Stahl <po...@rstahl.de> wrote:
> >Am 25.09.22 um 17:03 schrieb Gerald E¡scher:
> >> Hier ist einmal jemand aufgeschlagen, der hat nachdem WIRME xfce
> >> immer wieder die Plazierung von Icons vergessen hat, nach einem
> >> zweifelhaften, irgendwo gefundenen Hinweis die entsprechenden
> >> Konfigurationsdateien (vermutlich die gleichen wie bei dir) auf
> >> "immutable" gesetzt.
> >> Etwas später hat sich der Typ sich bei den Machern seiner
> >> Distribution lauthals beschwert, weil beim nächsten
> >> Distributionsrelease das Installationsprogramm auf die Nase
> >> gefallen ist...
> >
> >Nee war mir garantiert nicht bekannt. Und für so einen Zweck hätte
> >es ja auch gereicht, dem User die Schreibrechte wegzunehmen und
> >nicht allen einschließlich root. Nee nee, das war ich nicht.
>
> In meiner Welt kenne ich das Immutable-Flag als Werkzeug von
> Pfuschern, die zu faul sind, der verwendeten
> Konfigurationsmanagement-Software eine Ausnahme beizubringen, und die
> deswegen lieber den Kollegen innerhalb der nächsten
> Upgrade-Nachtschicht ein Ei in den Korb legen.

Ausnahme: es war *wirklich* dringend (Downtimekosten per Minute oder so)
und der Kollege hat ein Ticket angelegt und es am nächsten Tag gerade
gezogen.

--
SIC SEMPER
+--|=======>
TYRANNIS

[Marc Haber]

Dietz Proepper <dietz-...@rotfl.franken.de> wrote:

>Marc Haber <mh+usene...@zugschl.us> wrote:
>> In meiner Welt kenne ich das Immutable-Flag als Werkzeug von
>> Pfuschern, die zu faul sind, der verwendeten
>> Konfigurationsmanagement-Software eine Ausnahme beizubringen, und die
>> deswegen lieber den Kollegen innerhalb der nächsten
>> Upgrade-Nachtschicht ein Ei in den Korb legen.
>
>Ausnahme: es war *wirklich* dringend (Downtimekosten per Minute oder so)
>und der Kollege hat ein Ticket angelegt und es am nächsten Tag gerade
>gezogen.

Auch dann ist es Pfusch, aber legitimer solcher. Habe ich auch
schonmal gemacht.

[Dietz Proepper]

Marc Haber <mh+usene...@zugschl.us> wrote:

> Dietz Proepper <dietz-...@rotfl.franken.de> wrote:
> >Marc Haber <mh+usene...@zugschl.us> wrote:
> >> In meiner Welt kenne ich das Immutable-Flag als Werkzeug von
> >> Pfuschern, die zu faul sind, der verwendeten
> >> Konfigurationsmanagement-Software eine Ausnahme beizubringen, und
> >> die deswegen lieber den Kollegen innerhalb der nächsten
> >> Upgrade-Nachtschicht ein Ei in den Korb legen.
> >
> >Ausnahme: es war *wirklich* dringend (Downtimekosten per Minute oder
> >so) und der Kollege hat ein Ticket angelegt und es am nächsten Tag
> >gerade gezogen.
>
> Auch dann ist es Pfusch, aber legitimer solcher. Habe ich auch
> schonmal gemacht.

Auch Pfuschen will gelernt sein.

[Marc Haber]

Dietz Proepper <dietz-...@rotfl.franken.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>
>> Dietz Proepper <dietz-...@rotfl.franken.de> wrote:
>> >Marc Haber <mh+usene...@zugschl.us> wrote:
>> >> In meiner Welt kenne ich das Immutable-Flag als Werkzeug von
>> >> Pfuschern, die zu faul sind, der verwendeten
>> >> Konfigurationsmanagement-Software eine Ausnahme beizubringen, und
>> >> die deswegen lieber den Kollegen innerhalb der nächsten
>> >> Upgrade-Nachtschicht ein Ei in den Korb legen.
>> >
>> >Ausnahme: es war *wirklich* dringend (Downtimekosten per Minute oder
>> >so) und der Kollege hat ein Ticket angelegt und es am nächsten Tag
>> >gerade gezogen.
>>
>> Auch dann ist es Pfusch, aber legitimer solcher. Habe ich auch
>> schonmal gemacht.
>
>Auch Pfuschen will gelernt sein.

Die Kunst ist zu erkennen wenn Pfusch angezeigt ist und wann nicht.

Dummerweise sind die Pfuscher üblicherweise Team- und
Abteilungsleiters Liebling: Wenn man nur nach Aktenlage entscheidet,
sind das die Leute mit den meisten erledigten Tickets in der wenigsten
Zeit, weil die Kollateralschäden im Ticketsystem erst mit Verspätung
auftauchen und ihrem Verursacher üblicherweise nicht zugeordnet
werden.

[Dietz Proepper]

Marc Haber <mh+usene...@zugschl.us> wrote:

> Dietz Proepper <dietz-...@rotfl.franken.de> wrote:
> >Marc Haber <mh+usene...@zugschl.us> wrote:
> >
> >> Dietz Proepper <dietz-...@rotfl.franken.de> wrote:
> >> >Marc Haber <mh+usene...@zugschl.us> wrote:
> >> >> In meiner Welt kenne ich das Immutable-Flag als Werkzeug von
> >> >> Pfuschern, die zu faul sind, der verwendeten
> >> >> Konfigurationsmanagement-Software eine Ausnahme beizubringen,
> >> >> und die deswegen lieber den Kollegen innerhalb der nächsten
> >> >> Upgrade-Nachtschicht ein Ei in den Korb legen.
> >> >
> >> >Ausnahme: es war *wirklich* dringend (Downtimekosten per Minute
> >> >oder so) und der Kollege hat ein Ticket angelegt und es am
> >> >nächsten Tag gerade gezogen.
> >>
> >> Auch dann ist es Pfusch, aber legitimer solcher. Habe ich auch
> >> schonmal gemacht.
> >
> >Auch Pfuschen will gelernt sein.
>
> Die Kunst ist zu erkennen wenn Pfusch angezeigt ist und wann nicht.

Schreib' ich ja.

> Dummerweise sind die Pfuscher üblicherweise Team- und
> Abteilungsleiters Liebling: Wenn man nur nach Aktenlage entscheidet,
> sind das die Leute mit den meisten erledigten Tickets in der wenigsten
> Zeit, weil die Kollateralschäden im Ticketsystem erst mit Verspätung
> auftauchen und ihrem Verursacher üblicherweise nicht zugeordnet
> werden.

Bei solchen Vorgesetzten habe ich meist das Weite gesucht.

[Kay Martinen]

Am 27.09.22 um 12:57 schrieb Dietz Proepper:

Berühnte Letzte Worte aus der Realen Welt der Elektroinstallation:
"Nichts ist haltbarer als ein Provisorium" :-)

Der Grund ist oft ein "Kannst du mal schnell..." kurz vor Feierabend.

JA, so was gab es früher mal bei Handwerkern. ;)

Ｂｙｅ／
／Ｋａｙ
(Tastatur mit der Hand weg leg')

[Frank Miller]

Kay Martinen wrote:
[..snip..]

> Berühnte Letzte Worte aus der Realen Welt der Elektroinstallation:
> "Nichts ist haltbarer als ein Provisorium" :-)
>
> Der Grund ist oft ein "Kannst du mal schnell..." kurz vor Feierabend.
>
> JA, so was gab es früher mal bei Handwerkern. ;)

Oder auch ein Kurzschluss der gesamten Elektro-Installation in einer
Kneipe. Ca. 70 Jahre alte Leitungen mit geteerter(!) Isolation.
"Also /eigentlich dürfte/ ich da jetzt garnichts mehr 'dran machen. Aber
Sie brauchen ja Strom." ;-)

[Ignatios Souvatzis]

On 2022-09-27, Dietz Proepper <dietz-...@rotfl.franken.de> wrote:

> Auch Pfuschen will gelernt sein.

Hm... Dazu eine Anekdote aus meiner relativen Jugend. Hat aber nichts
mit Linux zu tun. Eher mit C. Und mit meinem Sysadministrieren, deshalb
mal nach dasr verschoben.

Es begab sich in jener Zeit, dass die Abteilung, für die ich seinerzeit
tätig war, ein Parallelrechnerpraktikum regelmäßig anbot.

In der ursprünglichen Version mussten dazu die Studierenden vor
Ort auf einem von 7 PCs mit DOS in einem Cross-Entwicklungssystem
Transputercode (in K&R-C) schreiben, und auf dem achten das Kompilat
in einen 3x3-Matrix von Transputern laden und ausführen. Irgendwann
sollte das attraktiver gemacht werden. Ein SBUS-Transputerinterface
ward beschafft, in eine vernetzte (ca.)Sparc1+ eingebaut und der
Transputerrechner daran angeschlossen.

Da damit neue Interfacesoftware des Herstellers jener Karte
einherging, mussten die Studierenden jetzt nicht nur in ANSI-C
schreiben, sondern auch noch leicht andere Timing-Libraryfunktionen
zum Messen des parallelen Speedups und der Skalierbarkeit ihrer
Implementierung der beauftragten Algorithmen verwenden. Alles
dokumentiert und online auf dem System verfuegbar, das wiederum
zeitlich unbegrenzt von den allgemeinen Studi-Poolraeumen aus per
ssh erreichbar war (statt nur vor Ort zu bestimmten Zeiten anwesend
sein zu müssen).

Soweit so gut. Das erste Semester mit dem System ging klaglos
vorüber. Das zweite brach an, und einer der Aufgaben sollte abgegeben
werden. Der Betreuer erzählte hinterher (zufällig waren wir beiden
Techies zu jenem Termin beide beim Mittagessen), eine Zweiergruppe
habe partout ihre Abgabe nicht vorfuehren koennen, weil sie sich
gar nicht kompilieren liess. Sie hatten aber felsenfest behauptet,
am Abend vorher habe das noch funktioniert. Er habe sich die Datei
dann doch aushändigen lassen, um uns dann anzusprechen, ob irgendwas
am System defekt sei. In der Zeit, in der er auf uns wartete, habe
er sich aber alte Abgaben aus dem vorvorigen Durchlauf (ihrwisstschon,
K&R und so) durchgelesen, und eine gefunden, die *exakt* der
abgegebenen entsprach. Damit seien wir 'raus, und er habe die
Betreffenden angeschrieben und um Kommentar gebeten. Die Gruppe
hat es wohl nicht gewagt, nach dem Schein für die Veranstaltung zu
fragen.

Merke: wenn du schon eine Programmieraufgabe kopierst statt selbst
löst, probier wenigstens aus, ob sie funktioniert.

-is
--
A medium apple... weighs 182 grams, yields 95 kcal, and contains no
caffeine, thus making it unsuitable for sysadmins. - Brian Kantor