Geschichte von "ping" (in memoriam Mike Muuss)

[Raimund Huemmer]

Kürzlich (beim Installieren von Nextstep) wurde ich wieder einmal daran
erinnert, dass dort ping in /etc zu finden ist. Beim überlegen, was das
wohl für historische Gründe hat, kam ich schnell durch die aktuellen
Manpages von ping(8) auf 4.3BSD und Mike Muuss.

Da ich eben sah, dass Mike Muuss vor 20 Jahren (20.11.2000) leider
relativ jung verstarb, dachte ich, hier in der Gruppe daran zu erinnern.

https://ftp.arl.army.mil/~mike/
https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.etc/ping/ping.c

Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?

Gruss
Raimund

[Goetz Hoffart]

Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?

Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.

Aber das Filesystem-Layout von UNIX ist dafür, dass ja alles eine Datei
ist, eh ... »spannend«. Unaufgeräumter Kram seit Anno dazumal. Ich sag
nur /usr/bin und /bin. Alles nur, weil mal in den Mittsiebzigern die
Hauptplatte mit /bin voll war, und man Binaries also auf die Zweitplatte
unter dem User-Verzeichnis /usr parkte ...

Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.

Grüße
Götz

[Michael Bäuerle]

Post by Goetz Hoffart
[...]
Aber das Filesystem-Layout von UNIX ist dafür, dass ja alles eine Datei
ist, eh ... »spannend«. Unaufgeräumter Kram seit Anno dazumal. Ich sag
nur /usr/bin und /bin. Alles nur, weil mal in den Mittsiebzigern die
Hauptplatte mit /bin voll war, und man Binaries also auf die Zweitplatte
unter dem User-Verzeichnis /usr parkte ...

Früher hatte man /usr auch gerne auf einem NFS-Server liegen und ganze
Rechner-Pools haben das von dort gemountet.

Post by Goetz Hoffart
Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.

Eine Begründung der systemd-Leute findet sich hier:
<https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/>

[Hanno Foest]

Post by Michael Bäuerle

Post by Goetz Hoffart
Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.

<https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/>

Kompatibilität zu anderen Unixen als (eine) Begründung? Von den Leuten,
die mit systemd die größte Inkompatibilität zu anderen Unixen
durchgedrückt haben? Verarschen kann ich mich alleine.

Hanno

[Michael van Elst]

Kompatibilität zu anderen Unixen als (eine) Begründung? Von den Leuten,
die mit systemd die größte Inkompatibilität zu anderen Unixen
durchgedrückt haben? Verarschen kann ich mich alleine.

Salami-Taktik erhöht die Akzeptanz.

[Kay Martinen]

Post by Michael van Elst

Kompatibilität zu anderen Unixen als (eine) Begründung? Von den Leuten,
die mit systemd die größte Inkompatibilität zu anderen Unixen
durchgedrückt haben? Verarschen kann ich mich alleine.

Ja, das finde ich als Begründung auch eher frech.

Post by Michael van Elst
Salami-Taktik erhöht die Akzeptanz.

Hier erhöht es allenfalls die Salamität der Kalamität (von systemd).
Aber auch so kann ich deinen Satz nur als unwahr abtun. Jedenfalls ich
glaube nicht dran aber... YMMV. ;-)

Kay

[Michael Bäuerle]

Post by Hanno Foest

Post by Michael Bäuerle

Post by Goetz Hoffart
Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.

<https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/>

Kompatibilität zu anderen Unixen als (eine) Begründung? Von den Leuten,
die mit systemd die größte Inkompatibilität zu anderen Unixen
durchgedrückt haben? Verarschen kann ich mich alleine.

Ja, das ist schon ein wenig lustig (oder auch nicht).
Ich wollte trotzdem auf deren Begründungen verweisen.

[Hauke Fath]

Post by Goetz Hoffart

Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?

Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.

War "ganz früher" nicht /etc das home von root? Verlinkt Solaris immer
noch "everything but the kitchen sink" nach /etc?

Hauke

[Thomas Koenig]

Post by Hauke Fath

Post by Goetz Hoffart

Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?

Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.

War "ganz früher" nicht /etc das home von root?

Ich dachte, root hatte / (daher der Name).

[Kay Martinen]

Post by Thomas Koenig

Post by Hauke Fath

Post by Goetz Hoffart

Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?

Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.

War "ganz früher" nicht /etc das home von root?

Ich dachte, root hatte / (daher der Name).

Ich denke das kommt eher von der Dateisystem-wurzel. Das ist nun mal /

Aber ich bin auch kein Kenner alter Unices und mag mich irren.

Kay

[Thomas Koenig]

Post by Kay Martinen

Post by Thomas Koenig

Post by Hauke Fath

Post by Goetz Hoffart

Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?

Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.

War "ganz früher" nicht /etc das home von root?

Ich dachte, root hatte / (daher der Name).

Ich denke das kommt eher von der Dateisystem-wurzel. Das ist nun mal /

Ich meinte das wie in https://en.wikipedia.org/wiki/Superuser
erläutert:

# The name root may have originated because root is the only user
# account with permission to modify the root directory of a Unix
# system. This directory was originally considered to be root's
# home directory,[4] but the UNIX Filesystem Hierarchy Standard now
# recommends that root's home be at /root.[5]

[Andreas Fenner]

Post by Hauke Fath
War "ganz früher" nicht /etc das home von root? Verlinkt Solaris immer
noch "everything but the kitchen sink" nach /etc?
Hauke

Bis einschließlich Solaris-10 hatte der USer root "/" als $HOME. Seit
Solaris-11 ist es nun "/root" .

Andreas

[Sebastian Barthel]

Post by Goetz Hoffart

Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?

Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.

Das stimmt - in dem McKusick Buch zu BSD 4.3 steht das auch so drin,
allerdings nicht als eine Definition sondern eher als Beispiele für die
Beschreibung des Bootens. Da gibt es u.a. in /etc

/etc/rc
/etc/fsck
/etc/update
/etc/cron
/etc/accton
/etc/syslogd
/etc/getty und
/etc/init

interessanterweise taucht login dann als /bin/login auf


Normalerweise haben die das aber sicher auch mal irgendwo aufgeschrieben,
wahrscheinlich findet man das in so einem USENIX Konferenz Papier, wo mal
jemand einen Dateibaum vorschlägt - an den sich dann alle, mehr oder
weniger, halten.

Post by Goetz Hoffart
Aber das Filesystem-Layout von UNIX ist dafür, dass ja alles eine Datei
ist, eh ... »spannend«. Unaufgeräumter Kram seit Anno dazumal. Ich sag
nur /usr/bin und /bin.

Manches ist aber auch schwierig, wenn man das wirklich richtig machen
will. Ein schönes Beispiel ist da /usr/local
Darin taucht dann quasi 'alles' nochmal auf und weil es ja sowieso nur
auf der Einzelmaschine da sein sollte, wäre es ja auch relativ konsequent
das als /local einzubinden. Auf der anderen Seite ist eben alles was drin
ist auch per se immer /usr Content.

Ein anderes Beispiel ist /usr/share/doc - keine Ahnung, warum das nicht
ganz oben liegen kann. Erklären kann man sich das aus heutiger Sicht nur
damit, daß grafische Filemanager einfach unüblich waren. Genausowas ist /
usr/share/icons und die Nummer mit dem /X11 ist auch nie wirklich
entschieden worden. Ich z.B. finde ja, daß man auch so Sachen wie
Windowmanager oder Datenbanken schön in Einzelordner packen könnte. Bei
Sun gibt es sowas mit dem Openwin Verzeichnis, wo mal halt alles was zum
Desktop gehört drin ist - dann aber eben auch konsequenterweise mit dem X
- den man dann stundenlang suchen kann, wenn man das nicht weiß.

Post by Goetz Hoffart
Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.

Das ist aber auch keine wirklich schöne Lösung. Eher so eine Art backward-
Kompatibilitätslayer der besonders trivialen Art.


Gruß,
SBn

[Nils M Holm]

Post by Sebastian Barthel
Ein anderes Beispiel ist /usr/share/doc - keine Ahnung, warum das nicht
ganz oben liegen kann.

Wahrscheinlich, weil die RK05 dann ziemlich schnell voll waere!

[Norbert Narten]

Post by Sebastian Barthel
interessanterweise taucht login dann als /bin/login auf

Der Grund ist wirklich einfach: Es hat damit zu tun, das /usr in einem klassischem
UNIX-System ein eigens Filesystem ist. Wenn das System "mal" nicht Ordnungsgemäß
starten kann und die Dateisysteme nicht gemountet werden, steht das logon-Programm
noch zur Verfügung. Ebenso die Standard-Shell /bin/sh. Damit ist ein Logon
im "Maintenance-Mode" immer noch möglich.

Post by Sebastian Barthel

Post by Goetz Hoffart
Aber das Filesystem-Layout von UNIX ist dafür, dass ja alles eine Datei
ist, eh ... »spannend«. Unaufgeräumter Kram seit Anno dazumal. Ich sag
nur /usr/bin und /bin.

Das ist hier der gleiche Grund. In /bin liegen die Programme, die im Notfall
unbedingt benötigt werden, um das System zu "retten"...

Post by Sebastian Barthel
Manches ist aber auch schwierig, wenn man das wirklich richtig machen
will. Ein schönes Beispiel ist da /usr/local
Darin taucht dann quasi 'alles' nochmal auf und weil es ja sowieso nur
auf der Einzelmaschine da sein sollte, wäre es ja auch relativ konsequent
das als /local einzubinden. Auf der anderen Seite ist eben alles was drin
ist auch per se immer /usr Content.

Der local-Ordner ist im Ursprung dafür gedacht, das dort Programme & Daten liegen,
die zu dem System gehören, wenn z.B. /usr über NFS gemountet wurde.

Post by Sebastian Barthel
Ein anderes Beispiel ist /usr/share/doc - keine Ahnung, warum das nicht
ganz oben liegen kann. Erklären kann man sich das aus heutiger Sicht nur

Wenn /usr ein NFS-Mount ist, liegen dort die Dateien, die für alle Systeme,
die diesen Mount nutzen, dann gleich sind (normalerweise RO gemountet)...

Post by Sebastian Barthel
damit, daß grafische Filemanager einfach unüblich waren. Genausowas ist /
usr/share/icons und die Nummer mit dem /X11 ist auch nie wirklich
entschieden worden. Ich z.B. finde ja, daß man auch so Sachen wie
Windowmanager oder Datenbanken schön in Einzelordner packen könnte. Bei
Sun gibt es sowas mit dem Openwin Verzeichnis, wo mal halt alles was zum
Desktop gehört drin ist - dann aber eben auch konsequenterweise mit dem X
- den man dann stundenlang suchen kann, wenn man das nicht weiß.

...somit machen /usr/X11 und /usr/share/X11 dann doch wieder Sinn, den
die Programme & Daten sind /usr-Mount und die Konfiguration ist in /etc.

Post by Sebastian Barthel

Post by Goetz Hoffart
Heute gibt es bei Linux und macOS Bestrebungen bzw. Aktivitäten da
Aufzuräumen -- bei manchem System sind das nur noch Symlinks.

Ich finde es eher "sub optimal" (um das höflich zu umschreiben), alles in
ein "Riesiges" File-System rein zu kippen. Das sorgt eher dafür, das der
vom Kernel kontrollierte File-System-Cache "extrem" anwachsen kann, bzw
die Suche nach Dateien in einem großen Dateisystem länger dauert, wenn es
keinen "Cache-Hit" gibt - es muss dann der Inode-Tree vollständig durchsucht
werden. Das kann dauern. Nicht jeder nutzt SSDs - schon gar nicht in klassischen
Systemen.

Post by Sebastian Barthel
Das ist aber auch keine wirklich schöne Lösung. Eher so eine Art backward-
Kompatibilitätslayer der besonders trivialen Art.

So ist das eben, wenn bewährte Dinge - meiner Meinung nach - zu schnell über
Board geworfen werden, nur weil es geil ist, alles von einer Firma in Redmond
vorgemachte, zu übernehmen. Der systemd ist da auch so ein Beispiel: Nach 10
Sekunden ist der Logon-Schirm da, aber eine Anmeldung dauert, weil die System-
Dienste im Hintergrund noch am starten sind... ;-)... aber das gehört jetzt
nicht hierhin.

Post by Sebastian Barthel
Gruß,
SBn

Viele Grüße
Norbert

[Stefan Möding]

Post by Norbert Narten
Der local-Ordner ist im Ursprung dafür gedacht, das dort Programme &
Daten liegen, die zu dem System gehören, wenn z.B. /usr über NFS
gemountet wurde.

Ich habe das so kennengelernt, dass /usr vom Betriebssystem ist und in
/usr/local die eigenen Erweiterungen abgelegt wurden. Da gab es dann eben
/usr/local/bin/bash, weil die Bash nicht beim OS mitgeliefert wurde und
man die stattdessen selber kompiliert hat.

Post by Norbert Narten
Ich finde es eher "sub optimal" (um das höflich zu umschreiben), alles
in ein "Riesiges" File-System rein zu kippen. Das sorgt eher dafür, das
der vom Kernel kontrollierte File-System-Cache "extrem" anwachsen kann,
bzw die Suche nach Dateien in einem großen Dateisystem länger dauert,
wenn es keinen "Cache-Hit" gibt - es muss dann der Inode-Tree
vollständig durchsucht werden. Das kann dauern. Nicht jeder nutzt SSDs -
schon gar nicht in klassischen Systemen.

Da sehe ich keinen Zusammenhang zur Anzahl der Filesysteme. Wenn der PATH
x Verzeichnisse enthält, dann läuft die Suche doch immer gleich ab, egal
ob die x Verzeichnisse in einem, drei oder fünf Filesystemen liegen. Der
Cache hält das, was eingelesen wird. Ich kenne das noch so (Ultrix 4.2),
dass die Größe des Caches ein statischer Kernelparameter war. Eine
Änderung erforderte einen Reboot mit einem neu compilierten Kernel.

Neben der Größe der Platten ist m.E. da eher noch die Dauer des
Filesystemchecks ein Thema. Es gab keine Journaling Filesysteme, d.h. bei
einem Crash (und nach x Reboots) war ein fsck nötig. Und Filesysteme auf
mehreren Disks konnten parallel durchlaufen werden. Drei Platten mit
jeweils 500MB waren da schneller fertig, als eine Platte mit 1500MB.

[K. Krause]

...

Post by Norbert Narten
Der Grund ist wirklich einfach: Es hat damit zu tun, das /usr in einem klassischem
UNIX-System ein eigens Filesystem ist. Wenn das System "mal" nicht Ordnungsgemäß
starten kann und die Dateisysteme nicht gemountet werden, steht das logon-Programm
noch zur Verfügung. Ebenso die Standard-Shell /bin/sh. Damit ist ein Logon
im "Maintenance-Mode" immer noch möglich.
Viele Grüße
    Norbert

In dem Buch von 1983 "The UNIX System, von S. R. Bourne, das war der mit
der gleichnamigen Muschel) steht geschrieben, dass die Homes der
Benutzer in /usr untergebracht sind. Daneben gibt es dort auch noch die
Subdirectories wie include, spool und src.
Von daher scheint mir der Name usr eher als eine Verkürzung von user,
als ein Akronym für Unix System Resources wahrscheinlich. Der Herr
Bourne hat es mit dreibuchstabigen Abkürzungen.

Ping gibt es in dem Buch natürlich noch nicht, und der Herr Bourne
freut sich, dass er von seinem Rechner allegra mit uucp Zugriff auf
über 300 andere Rechner hat, auf die er Files entweder über Telefon-
leitungen oder über spezielle Hochgeschwindigkeitsleitungen kopieren
kann. :-)

Klemens

[Stefan Möding]

Ich sag nur /usr/bin und /bin. Alles nur, weil mal in den Mittsiebzigern
die Hauptplatte mit /bin voll war, und man Binaries also auf die
Zweitplatte unter dem User-Verzeichnis /usr parkte ...

Nach /bin gehören die Sachen, die man im Single-User Betrieb und zum
Booten braucht, bevor /usr gemounted wurde (ggfs. über NFS).

Irgendwo habe ich mal gelesen, dass /usr das Kürzel für Unix System
Resources sei, also nicht unbedingt was mit Usern zu tun hat. Wer kann
heute noch sagen, ob da was dran ist...

[Nils M Holm]

Irgendwo habe ich mal gelesen, dass /usr das K?rzel f?r Unix System
Resources sei, also nicht unbedingt was mit Usern zu tun hat. Wer kann
heute noch sagen, ob da was dran ist...

Da die User-Verzeichnisse frueher direkt unter /usr lagen, halte
ich das fuer ein bacronym.

[Stefan Möding]

Post by Nils M Holm
Da die User-Verzeichnisse frueher direkt unter /usr lagen, halte
ich das fuer ein bacronym.

Ja, vermutlich ist das auch so.

Im Unix Programmer’s Manual unter
https://www.bell-labs.com/usr/dmr/www/1stEdman.html (auch hier sieht man
/usr/dmr) finden noch ein paar Hinweise zu /etc:

,----[ mkfs ]
| This program is kept in /etc to avoid inadvertant use and consequent
| destruction of information
`----

,----[ boot ]
| boot logically a command, and is kept in /etc only to lessen the
| probability of its being invoked by accident or from curiosity
`----

/etc sollte wohl nicht im Pfad sein und damit potentiell gefährliche
Kommandos nicht aus versehen gestartet werden, sondern eben durch Eingabe
des kompletten Pfades.

[Nils M Holm]

Post by Stefan Möding
,----[ mkfs ]
| This program is kept in /etc to avoid inadvertant use and consequent
| destruction of information
`----

Ergibt Sinn!

Post by Stefan Möding
,----[ boot ]
| boot logically a command, and is kept in /etc only to lessen the
| probability of its being invoked by accident or from curiosity
`----

*Das* hat bei mir nicht funktioniert! :)

Post by Stefan Möding
/etc sollte wohl nicht im Pfad sein und damit potentiell gef?hrliche
Kommandos nicht aus versehen gestartet werden, sondern eben durch Eingabe
des kompletten Pfades.

Genau so habe ich das immer gehandhabt.

[Diedrich Ehlerding]

Post by Nils M Holm

Post by Stefan Möding
| This program is kept in /etc to avoid inadvertant use and
| consequent destruction of information
`----

Ergibt Sinn!

Nun ja - damit mkfs Unheil anrichten kann, muss der Benutzer
Schreibzugriff auf den Deviceknoen haben. Eigentlich nacht das nur dann
Sinn, wenn jemand als root arbeitet. Das sollte aber sowieso niemand
tun, und schon gar nicht jemand, der mal eben so Filesysteme zerstört.
Und die heutigen Versionen von fsck fragen nochmal nach, wenn sie da
schon ein Filesystem vorfinden.

Irgendwie hat die Idee "Programme nach /etc legen, damit sie nicht
versehentlich bvenutzt werden" etwas von "security by obscurity".

[Nils M Holm]

Post by Diedrich Ehlerding
Irgendwie hat die Idee "Programme nach /etc legen, damit sie nicht
versehentlich bvenutzt werden" etwas von "security by obscurity".

Ich denke, da geht es eher um safety als security.

[Kay Martinen]

Post by Nils M Holm

Post by Diedrich Ehlerding
Irgendwie hat die Idee "Programme nach /etc legen, damit sie nicht
versehentlich bvenutzt werden" etwas von "security by obscurity".

Ich denke, da geht es eher um safety als security.

'Safety by Obscurity" klingt auch nicht besser, eher wie eine
Marketing-Luftblase. :-)

Pers. möchte ich bei meinen Linuxen auch keine binarys in /etc sehen
noch einen link darauf. /etc/init.d/ zählt dabei nicht weil die binarys
nur aus den scripts dort aufgerufen werden. Aber das gewöhnt man sich
m.E. als erstes an das man für Start/stops ein /etc/init.d/ schreibt.
Und dank Autocomplete in der bash kommt man auch schnell zum richtigen
script. Im gegensatz zu 'systemctl <aktion> <dienstname>.service
blablafasel... was ich total praxisfeindlich finde. Dann lieber 'service'


Kay

[Ignatios Souvatzis]

Post by Diedrich Ehlerding
Nun ja - damit mkfs Unheil anrichten kann, muss der Benutzer
Schreibzugriff auf den Deviceknoen haben. Eigentlich nacht das nur dann
Sinn, wenn jemand als root arbeitet. Das sollte aber sowieso niemand
tun, und schon gar nicht jemand, der mal eben so Filesysteme zerstört.
Und die heutigen Versionen von fsck fragen nochmal nach, wenn sie da

****

Post by Diedrich Ehlerding
schon ein Filesystem vorfinden.
Irgendwie hat die Idee "Programme nach /etc legen, damit sie nicht
versehentlich bvenutzt werden" etwas von "security by obscurity".

Hm, ja. Es ist kein echter Schutz. Es hilft aber in begrenztem Ausmass
vor Tippfehlern, wie dem inversen von dem, den du gerade begangen hast.
Gerade als root.

-is

[Gerrit Heitsch]

Post by Ignatios Souvatzis

Post by Diedrich Ehlerding
Nun ja - damit mkfs Unheil anrichten kann, muss der Benutzer
Schreibzugriff auf den Deviceknoen haben. Eigentlich nacht das nur dann
Sinn, wenn jemand als root arbeitet. Das sollte aber sowieso niemand
tun, und schon gar nicht jemand, der mal eben so Filesysteme zerstört.
Und die heutigen Versionen von fsck fragen nochmal nach, wenn sie da

****

Post by Diedrich Ehlerding
schon ein Filesystem vorfinden.
Irgendwie hat die Idee "Programme nach /etc legen, damit sie nicht
versehentlich bvenutzt werden" etwas von "security by obscurity".

Hm, ja. Es ist kein echter Schutz. Es hilft aber in begrenztem Ausmass
vor Tippfehlern, wie dem inversen von dem, den du gerade begangen hast.
Gerade als root.

fsck sollte aber nachfragen bevor es ein Filesystem anfasst wenn dieses
aktuell gemounted ist.

Gerrit

[Andreas Fenner]

Post by Gerrit Heitsch
fsck sollte aber nachfragen bevor es ein Filesystem anfasst wenn dieses
aktuell gemounted ist.
 Gerrit

So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?

:-)

Andreas

[Kay Martinen]

Post by Andreas Fenner

Post by Gerrit Heitsch
fsck sollte aber nachfragen bevor es ein Filesystem anfasst wenn
dieses aktuell gemounted ist.
  Gerrit

So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?

Ach das ist interessant. Welche Version von fsck auf welchem OS
verwendest du bitte?

Ich meine, es wäre doch toll wenn alle so ein Tool hätte das außer den
"bist du Sicher" und "Willst du das WIRKLICH tun" Nachfragen - hier
offenbar auch noch die Qualifikation des fsck-aufrufenden abfragt
(online-vitae analysierend) und bei weniger als 3 Jahren
Systemverwaltungspraxis den Zugriff einfach mit einem DAU-Error 404
verweigert. MIR würde dann zwar der Zugriff immer verweigert aber die
Regeln kann man ja sicher auch umgehen, nodephalls durch ziehen des
Netzwerkkabels. Man muß ja *nur* wissen was man tut. So wie Sledge Hammer.

Post by Andreas Fenner
:-)

Ja, genau. Stell dir mal vor das Skalpel fährt erst dann den
Klingenschutz zurück wenn der Doc seinen Heilberufsausweis vorzeigt. In
der Notaufnahme - bei einem Kritisch Schwerverletzten...

Wir müssen es echt irgendwie hinkriegen das in Summe nur noch so viele
Menschen (über)leben wie der Planet auch ernähren kann. Dafür werden uns
irgendwann alle mittel recht sein.

Ob sie dann auch GERECHT sind, das liegt dann wohl am Bankkonto...

fsck -t terraform -M /dev/earth

Result is: FUBAK

Kay

[Guido Grohmann]

Post by Kay Martinen
fsck -t terraform -M /dev/earth

segmentation fault
core dumped

uuuund:

kernel panic

;)

Guido

[Kay Martinen]

Post by Guido Grohmann

Post by Kay Martinen
fsck -t terraform -M /dev/earth

segmentation fault
core dumped
kernel panic
;)

Du hast den Film "2012" also auch gesehen, und dessen Thema treffend und
kurz umrissen. :-)

Das kriegen wir auch 2021 noch ganz alleine hin. Praktische
Zahlendreherei. ;)

Kay

[Guido Grohmann]

Post by Kay Martinen

Post by Guido Grohmann

Post by Kay Martinen
fsck -t terraform -M /dev/earth

segmentation fault
core dumped
kernel panic
;)

Du hast den Film "2012" also auch gesehen, und dessen Thema treffend und
kurz umrissen. :-)

Nö, der ist mir völlig unbekannt. :o

Guido

[Kay Martinen]

Post by Guido Grohmann

Post by Kay Martinen

Post by Guido Grohmann

Post by Kay Martinen
fsck -t terraform -M /dev/earth

segmentation fault
core dumped
kernel panic
;)

Du hast den Film "2012" also auch gesehen, und dessen Thema treffend und
kurz umrissen. :-)

Nö, der ist mir völlig unbekannt. :o

[x] Dir ist der Alu-Hut über die Augen gerutscht.

Andere Beschreibung des Films: "Wir werden alle Sterben! Nein! Doch!
Ohh! Na, doch nicht alle..." Aber schön das zum Ende hin der US
Präsident stirbt - leider der Falsche wie üblich.

Kay

[Michael van Elst]

Post by Kay Martinen
Andere Beschreibung des Films: "Wir werden alle Sterben! Nein! Doch!
Ohh! Na, doch nicht alle..." Aber schön das zum Ende hin der US
Präsident stirbt - leider der Falsche wie üblich.

Helden müssen sterben.

[Arno Welzel]

Post by Andreas Fenner

Post by Gerrit Heitsch
fsck sollte aber nachfragen bevor es ein Filesystem anfasst wenn dieses
aktuell gemounted ist.
 Gerrit

So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?

Nein, so wie fsck eben fragt:

--------------------

fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
/dev/sda2 is mounted.



WARNING!!! The filesystem is mounted. If you continue you ***WILL***
cause ***SEVERE*** filesystem damage.


Do you really want to continue<n>?

--------------------

[Hanno Foest]

Post by Andreas Fenner

Post by Gerrit Heitsch
fsck sollte aber nachfragen bevor es ein Filesystem anfasst wenn dieses
aktuell gemounted ist.
 Gerrit

So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?

Daß es das heute tut ist klar. Ob es das im letzten Jahrtausend (immer)
schon getan hat? Und was davon "sollte" sein? Der Admin sollte wissen,
was er tut :)

Die Nachfrage ist dennoch nett, klar.

Hanno

[Christian Corti]

Post by Hanno Foest
Daß es das heute tut ist klar. Ob es das im letzten Jahrtausend (immer)
schon getan hat? Und was davon "sollte" sein? Der Admin sollte wissen,
was er tut :)

Eben. Unter SunOS passiert einfach folgendes:
# fsck /dev/sd12c
** /dev/sd12c
** Currently Mounted on /src
** Phase 1 - Check Blocks and Sizes
[...]

Das System weiß immerhin, daß das FS gemountet ist. Man sollte bei
eventuellen Fragen, ob etwas repariert werden soll, natürlich wissen,
worauf man sich da einläßt.

Christian

[Dennis Grevenstein]

Post by Andreas Fenner
So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?

Ist halt wie beim Löten. Da fragt der Lötkölben auch nicht, ob man
wirklich was extrem Heisses an diese Stelle halten will. Und im
Normalfall hat man das Schneiden schonmal an einem Stück zum wegwerfen
geübt (siehe auch: Körperspende).

gruss,
Dennis

[Kay Martinen]

Post by Dennis Grevenstein

Post by Andreas Fenner
So wie das Scalpel den Chirurgen fragt ob er wirklich das Herz schneiden
will?

Ist halt wie beim Löten. Da fragt der Lötkölben auch nicht, ob man
wirklich was extrem Heisses an diese Stelle halten will. Und im

Anders herum hat die Sonne auch keiner gefragt ob sie so und nicht
anders "heiß" brennen will. Und wir; als Kinder der Sonne (und des
Universums an sich) wurden auch nicht gefragt. Typisch Götter. Machen
einfach! ;-)

Post by Dennis Grevenstein
Normalfall hat man das Schneiden schonmal an einem Stück zum wegwerfen
geübt (siehe auch: Körperspende).

Da sagst du was wahres. Bei der Übermenge an Menschen auf dem Planeten,
warum war "Mensch" noch gleich KEIN Wegwerf-artikel?

Doch nur weil man selbst dem Dümmsten Menschen einen Verstand (auch wenn
er ihn nicht gebraucht), Selbstbewußtsein (was etliche leider im Übermaß
haben) und eine "Seele" (was auch immer $Religion darunter versteht).

Ergo Schnibbeln Angehende Ärzte nur an Toten (Verdacht: Seele futsch)
und alles andere ist verboten.


Kay

[Dennis Grevenstein]

Post by Kay Martinen
Da sagst du was wahres. Bei der Übermenge an Menschen auf dem Planeten,
warum war "Mensch" noch gleich KEIN Wegwerf-artikel?
Doch nur weil man selbst dem Dümmsten Menschen einen Verstand (auch wenn
er ihn nicht gebraucht), Selbstbewußtsein (was etliche leider im Übermaß
haben) und eine "Seele" (was auch immer $Religion darunter versteht).
Ergo Schnibbeln Angehende Ärzte nur an Toten (Verdacht: Seele futsch)
und alles andere ist verboten.

So kann man es natürlich auch betrachten, aber ich würde auch
sagen, dass man es nicht ganz so philosophisch aufladen muss.
Dahinter steckt ja ein "best practice" Ansatz. Erst die Struktur
mit der stumpfen Seite vom Skalpell freilegen, bevor man was
mit der scharfen Seite durchschneidet. Das ist dann wieder
Handwerk. Piloten verwenden Checklisten. Piloten müssen auch
im Simulator üben, bevor man sie ans Steuer eines Urlausflieger
nach Mallorca setzt.
In der IT gibt es diese Art von Sicherheit nicht unbedingt.
Wer einmal unfallfrei Linux installiert hat, kann morgen schon
Administrator von irgendeiner box werden, wenn es halt kein
anderer machen will. Man will gar nicht drüber nachdenken,
wieviel Software irgendwelchen Zombie-code, von irgendwelchen
Praktikanten geschrieben, enthält, der einfach nicht sterben
will. Ich gebe offen zu, dass ich an der Front auch schuldig
bin. Ich habe keine Ahnung, wie man sowas kulturell besser
lösen könnte, aber vor dem Hintergrund finde ich Sicherheits-
fragen wie "Sind Sie sicher, dass Sie XY formatieren wollen?"
sinnvoll.

Immer noch schön:
https://www.gnu.org/fun/jokes/vaxorcist.html

"SYSMGR: Documentation S...? Oh, you mean the grey binders? They're over
there. (he points to the wall behind the VAXORCIST. The VAXORCIST turns
and we see a closed glass-front bookcase packed with grey binders. A small
red sign on the front of the bookcase reads: "IN CASE OF EMERGENCY, BREAK
GLASS")."

gruss,
Dennis

[Martin Wohlauer]

Post by Kay Martinen

Post by Dennis Grevenstein
Normalfall hat man das Schneiden schonmal an einem Stück zum wegwerfen
geübt (siehe auch: Körperspende).

Da sagst du was wahres. Bei der Übermenge an Menschen auf dem Planeten,
warum war "Mensch" noch gleich KEIN Wegwerf-artikel?

Och, nach Ende des Gebrauchs bzw. bei völliger Unbenutzbarkeit ist das
doch gar nicht so weit weg von der Wahrheit. Manche landen quasi in der
Verbrennungsanlage, andere werden verbuddelt. Mancher will sich von
seinem inzwischen nicht mehr so ganz brauchbaren Menschen trotzdem nicht
trennen und stellt ihn zum Anschauen trotzdem noch in eine Art Vitrine,
wo wie mancher auch noch kaputte/unbenutzbare alte Computer behält. Aber
wirklich aufgehoben wurden anteilig gesehen nicht so irre viele, die
meisten fliegen raus™... Also die Parallelen sind schon definitiv da. ;-)

Post by Kay Martinen
Doch nur weil man selbst dem Dümmsten Menschen einen Verstand (auch wenn
er ihn nicht gebraucht), Selbstbewußtsein (was etliche leider im Übermaß
haben) und eine "Seele" (was auch immer $Religion darunter versteht).
Ergo Schnibbeln Angehende Ärzte nur an Toten (Verdacht: Seele futsch)
und alles andere ist verboten.

Naja, eigentlich ist der (relativ gut zu begründende) Verdacht der
permanenten Absenz eines Bewusstseins der ausschlaggebende Grund, warum
man das so machen kann. Es gibt aber welche, die der Meinung sind, die
Seele würde mit beschädigt, wenn der Körper beschädigt würde, und daher
verlangen sie, dass man das unterlässt.

Grüßle,

Martin.

[Diedrich Ehlerding]

Post by Goetz Hoffart
Ich bin alles andere als ein Kenner von altem UNIX, aber bei alten
IRIX-Versionen gab es auch Binaries in /etc.

Ich habe hier noch ein altes Buch "Unix Version 7, System III und System
V" von 1985, das nennt auch diverse Binaries in /etc ( (/etc/getty,
/etc/fsck z.B.)

[Nils M Holm]

Post by Raimund Huemmer
Und ggf. zur Struktur unter /etc? War das in
4.3BSD so ?blich?

Bei einigen 7th-Edition-Derivaten (und ich meine in
7th Edition selbst auch) lagen die administrativen
binaries in /etc. /sbin gab es noch nicht. Coherent, zum
Beispiel, wurde mit /etc/shutdown heruntergefahren (es sei
denn /etc lag in $PATH). fsck, fdisk, getty, mkfs, mount,
passwd, und vieles mehr lag in /etc. Bei BSD war das
anfangs genauso.

[Ralph Spitzner]

Raimund Huemmer wrote on 11/15/20 9:17 PM:
[...]

Post by Raimund Huemmer
Und will auch noch fragen, ob jemand noch Näheres zur Entwicklung von
ping zu berichten weiß? Und ggf. zur Struktur unter /etc? War das in
4.3BSD so üblich?
Gruss
Raimund

um mal zum Thema zurueckzukommen:
Ich denke das hat wirklich eher mit security by obscurity zu tun, als mit
irgendwelchen dateisystemhirarien, oder philosophien, den wer / folgt kommt so oder so auch durch
irgendwelche eingehaengte dateisysteme...

Allerdings gehoert ping halt root/root und hat das s bit gesetzt, waer also mit irgendwelchen tricks
evtl. dazu zu ueberreden ne #shell herzugeben...
security by obscurity weils halt unter /etc nicht im $PATH liegt....

nur meine 2 Pfennig...

Mfg
-rasp
PS: sorry, falls das schon wer schrub und ich's ueberlesen hab

[Michael van Elst]

Post by Ralph Spitzner
security by obscurity weils halt unter /etc nicht im $PATH liegt....

Safety, nicht security. Und versteckt ist es auch kaum.

So wie /sbin, in das man die /etc-Binaries hineinsortiert hat. Nur dass
heutzutage jeder /sbin in den Pfad aufnimmt, auch wenn er nicht als root
arbeitet.

[Norbert Narten]

Post by Michael van Elst
So wie /sbin, in das man die /etc-Binaries hineinsortiert hat. Nur dass
heutzutage jeder /sbin in den Pfad aufnimmt, auch wenn er nicht als root
arbeitet.

/sbin steht für "Static Binaries". Das sind Binaries, die ohne zusätzliche
Libraries auskommen. Hat im übrigen die gleiche Funktion wie /bin bei dem
System-Start / Wartung (z.B nach einem init s) oder im Notfall, um dann
noch ein Minimal-System zur Verfügung zu haben. Die Pfade sind deswegen
in PATH enthalten, weil es auch reguläre Programme sind, die jeder nutzen
kann / darf.

Norbert

[Michael van Elst]

/sbin steht für "Static Binaries".

4.4BSD hat /sbin und /usr/sbin eingeführt, hatte aber noch keine shared
libraries. Administrative Kommandos, die z.B. bei 4.3BSD noch in /etc
lagen, wurden nach /sbin bzw. /usr/sbin verschoben.

SunOS 4 (da hat SunOS shared libraries eingeführt) hatte einige
Kommandos in /bin noch statisch gelinkt, aber nicht alle. Das
reichte dann um Libraries von einer anderen Maschine zu kopieren.

SysVR4 hatte seine shared libraries in /usr/lib (/lib gab es nicht).
Alle Binaries in /bin und /sbin waren dynamisch gelinkt (z.B. gegen
/usr/lib/libc.so.1) weswegen /usr kein eigenes Filesystem mehr sein
konnte.

Aktuell sind alle Binaries in /sbin dynamisch gelinkt (bei Linux
mit Ausnahme von ldconfig aus verständlichen Gründen).

[Michael Bäuerle]

Post by Michael van Elst

Post by Norbert Narten
/sbin steht für "Static Binaries".

4.4BSD hat /sbin und /usr/sbin eingeführt, hatte aber noch keine shared
libraries. Administrative Kommandos, die z.B. bei 4.3BSD noch in /etc
lagen, wurden nach /sbin bzw. /usr/sbin verschoben.

Demnach steht das "s" in sbin dann für "Superuser".


[Umlaut im Zitat repariert]

[Christian Corti]

Post by Michael van Elst

/sbin steht für "Static Binaries".

So habe ich das auch gelernt.

Post by Michael van Elst
SunOS 4 (da hat SunOS shared libraries eingeführt) hatte einige
Kommandos in /bin noch statisch gelinkt, aber nicht alle. Das
reichte dann um Libraries von einer anderen Maschine zu kopieren.

Das hier immer noch laufende SunOS 4.1.1 hat in /etc nur dynamische
Binaries. In /sbin sind alle Binaries statisch:
# ldd /sbin/*
/sbin/hostconfig: statically linked
/sbin/hostname: statically linked
/sbin/ifconfig: statically linked
/sbin/init: statically linked
/sbin/intr: statically linked
/sbin/mount: statically linked
/sbin/sh: statically linked

Christian

[Kay Martinen]

Post by Christian Corti

/sbin steht für "Static Binaries".

So habe ich das auch gelernt.

Dann ist das mein Problem (der späten Geburt) das ich sbin immer als
"secure" o.ä. Verstanden habe. Sprich: tools die nur root o.a. admin
user benutzen (dürfen). Aber ich muß auch zugeben das ich das nie im
Detail nachprüfte. Seit ca. 1990 als ich mit Linux anfing... und ein
Unix/Minix hab ich nie benutzt.

Oder kann es sein das Linux da <> Unix <> Minix ist?

Kay

[Dennis Grevenstein]

SunOS 4 (da hat SunOS shared libraries eingef?hrt) hatte einige
Kommandos in /bin noch statisch gelinkt, aber nicht alle. Das
reichte dann um Libraries von einer anderen Maschine zu kopieren.

Hat diese Abhaengigkeit von shared libraries an der Stelle nicht
mehr damit zu tun, dass keine Abhaengigkeiten in /usr vorkommen
duerfen, weil man das System noch retten koennen muss, wenn /usr
nicht gemountet ist? Die libc liegt docch unter /usr/lib wenn ich
mich richtig erinnere.

gruss,
Dennis

[Kay Martinen]

Post by Dennis Grevenstein

SunOS 4 (da hat SunOS shared libraries eingef?hrt) hatte einige
Kommandos in /bin noch statisch gelinkt, aber nicht alle. Das
reichte dann um Libraries von einer anderen Maschine zu kopieren.

Hat diese Abhaengigkeit von shared libraries an der Stelle nicht
mehr damit zu tun, dass keine Abhaengigkeiten in /usr vorkommen
duerfen, weil man das System noch retten koennen muss, wenn /usr
nicht gemountet ist? Die libc liegt docch unter /usr/lib wenn ich
mich richtig erinnere.

Bei meinem aktuellen Linux hier finde ich 'libc' auf die Schnelle unter
/lib obwohl unter /usr/lib u.a. auch vieles liegt. Das scheint aber eher
Text oder zusätzliches zu sein.

Hat sich das evtl. nicht bewährt?

Kay

[Dennis Grevenstein]

Post by Kay Martinen
Bei meinem aktuellen Linux hier finde ich 'libc' auf die Schnelle unter
/lib obwohl unter /usr/lib u.a. auch vieles liegt. Das scheint aber eher
Text oder zus?tzliches zu sein.
Hat sich das evtl. nicht bew?hrt?

ein aktuelles Linux ist halt nochmal was anderes als ein echtes Unix
mit Wurzeln in den 80ern :-)
Daher koennte man schon sagen, dass sich die alte Struktur nicht bewaehrt
hat.

Ich habe gerade mal Solaris 2.4 angeguckt. Da gibt es in /sbin
auch dynamisch gelinkte Dateien. /bin ist ein symlink nach /usr/bin.

gruss,
Dennis