Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #125209 > unrolled thread

unlöschbare Files

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-23 16:50 +0200
    Re: unlöschbare Files Claus Reibenstein <creibens@gmail.com> - 2022-09-23 18:01 +0200
      Re: unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-23 21:38 +0200
      Re: unlöschbare Files Alexander Schreiber <als@usenet.thangorodrim.de> - 2022-09-24 12:47 +0200
        Re: unlöschbare Files Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 17:02 +0200
    Re: unlöschbare Files Andreas Wagner <andreasw-usenet@web.de> - 2022-09-23 16:06 +0000
      Re: unlöschbare Files Claus Reibenstein <creibens@gmail.com> - 2022-09-23 18:13 +0200
        Re: unlöschbare Files Andreas Wagner <andreasw-usenet@web.de> - 2022-09-24 16:25 +0200
          Re: unlöschbare Files "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2022-09-24 22:36 +0200
      Re: unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-23 21:40 +0200
    Re: unlöschbare Files Claus Reibenstein <creibens@gmail.com> - 2022-09-23 18:07 +0200
    Re: unlöschbare Files Andreas Hartmann <andihartmann@01019freenet.de> - 2022-09-23 18:55 +0200
      Re: unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-23 21:44 +0200
        Re: unlöschbare Files Christian Garbs <mitch@cgarbs.de> - 2022-09-23 20:16 +0000
          Re: unlöschbare Files Kay Martinen <usenet@martinen.de> - 2022-09-23 23:05 +0200
            Re: unlöschbare Files Christian Garbs <mitch@cgarbs.de> - 2022-09-24 18:42 +0000
          Re: unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-24 15:27 +0200
            Re: unlöschbare Files Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-09-24 13:33 +0000
              Re: unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-24 15:34 +0200
              Re: unlöschbare Files Kay Martinen <usenet@martinen.de> - 2022-09-24 18:16 +0200
                Re: unlöschbare Files Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-09-24 22:56 +0200
    Re: unlöschbare Files Stefan Reuther <stefan.news@arcor.de> - 2022-09-23 19:06 +0200
      Re: unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-23 21:48 +0200
      Re: unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-23 21:51 +0200
        Re: unlöschbare Files Kay Martinen <usenet@martinen.de> - 2022-09-23 22:05 +0200
          Re: unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-24 15:32 +0200
            Re: unlöschbare Files Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-24 16:18 +0000
              Re: unlöschbare Files Kay Martinen <usenet@martinen.de> - 2022-09-24 19:24 +0200
              Re: unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-25 11:36 +0200
                Re: unlöschbare Files Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-09-25 15:03 +0000
                  Re: unlöschbare Files Ralph Stahl <post@rstahl.de> - 2022-09-26 13:01 +0200
                    Re: unlöschbare Files Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-26 13:56 +0200
                      Re: unlöschbare Files Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-27 08:32 +0200
                        Re: unlöschbare Files Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-27 12:25 +0200
                          Re: unlöschbare Files Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-27 12:57 +0200
                            Re: unlöschbare Files Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-27 18:21 +0200
                              Re: unlöschbare Files Dietz Proepper <dietz-usenet@rotfl.franken.de> - 2022-09-27 21:01 +0200
                            Re: unlöschbare Files Kay Martinen <usenet@martinen.de> - 2022-09-28 00:34 +0200
                              Re: unlöschbare Files Frank Miller <miller@posteo.ee> - 2022-09-28 03:32 +0200
                            Re: unlöschbare Files Ignatios Souvatzis <u502sou@bnhb484.de> - 2022-09-30 17:16 +0000
      Re: unlöschbare Files Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-09-23 20:58 +0000
        Re: unlöschbare Files Laurenz Trossel <me@example.invalid> - 2022-09-23 21:37 +0000
          Re: unlöschbare Files Kay Martinen <usenet@martinen.de> - 2022-09-23 23:48 +0200
    Re: unlöschbare Files Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 20:28 +0200
      Re: unlöschbare Files Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 21:18 +0200
        Re: unlöschbare Files Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 21:20 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#125254

 Kay Martinen <usenet@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.

[toc] | [prev] | [next] | [standalone]

#125215

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

[toc] | [prev] | [next] | [standalone]

#125226

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.


> 
>> 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

[toc] | [prev] | [next] | [standalone]

#125227

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???



> 
>> 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

[toc] | [prev] | [next] | [standalone]

#125228

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?" :-)

[toc] | [prev] | [next] | [standalone]

#125242

Am 23.09.22 um 22:05 schrieb 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.
> 
> Ｂｙｅ／
>     ／Ｋａｙ
> 

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.

[toc] | [prev] | [next] | [standalone]

#125247

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

[toc] | [prev] | [next] | [standalone]

#125249

Am 24.09.22 um 18:18 schrieb 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.
> 

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.

Ｂｙｅ／
   ／Ｋａｙ

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

[toc] | [prev] | [next] | [standalone]

#125261

Am 24.09.22 um 18:18 schrieb 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.
> 

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.

[toc] | [prev] | [next] | [standalone]

#125266

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

[toc] | [prev] | [next] | [standalone]

#125271

Am 25.09.22 um 17:03 schrieb 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...
> 
> 

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.

[toc] | [prev] | [next] | [standalone]

#125274

Ralph Stahl <post@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

[toc] | [prev] | [next] | [standalone]

#125301

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

> Ralph Stahl <post@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

[toc] | [prev] | [next] | [standalone]

#125306

Dietz Proepper <dietz-usenet@rotfl.franken.de> wrote:
>Marc Haber <mh+usenetspam1118@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.

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

[toc] | [prev] | [next] | [standalone]

#125309

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

> Dietz Proepper <dietz-usenet@rotfl.franken.de> wrote:
> >Marc Haber <mh+usenetspam1118@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.

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

[toc] | [prev] | [next] | [standalone]

#125314

Dietz Proepper <dietz-usenet@rotfl.franken.de> wrote:
>Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
>
>> Dietz Proepper <dietz-usenet@rotfl.franken.de> wrote:
>> >Marc Haber <mh+usenetspam1118@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.

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

[toc] | [prev] | [next] | [standalone]

#125319

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

> Dietz Proepper <dietz-usenet@rotfl.franken.de> wrote:
> >Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> >  
> >> Dietz Proepper <dietz-usenet@rotfl.franken.de> wrote:  
> >> >Marc Haber <mh+usenetspam1118@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.

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

[toc] | [prev] | [next] | [standalone]

#125323

Am 27.09.22 um 12:57 schrieb Dietz Proepper:
> Marc Haber <mh+usenetspam1118@zugschl.us> wrote:
> 
>> Dietz Proepper <dietz-usenet@rotfl.franken.de> wrote:
>>> Marc Haber <mh+usenetspam1118@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.
> 

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')

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

[toc] | [prev] | [next] | [standalone]

#125324

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." ;-)

[toc] | [prev] | [next] | [standalone]

#125385

On 2022-09-27, Dietz Proepper <dietz-usenet@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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web