proc an falscher Stelle

[Huflatisch]

Hey

Habe gerade festgestellt das ich drei mal ein identisches proc Verzeichnis habe.

/proc --> hier sollte es auch sein
/var/lib/named/proc --> wird genauso aktualisiert wie /proc
/var/lib/ntp/proc --> wird genauso aktualisiert wie /proc

die zwei zusätzlichen sind auch nicht übern "Midnight Commander" löschbar (zumindest im laufenden Betrieb)


Wie passiert den sowas? Das System (OS 11.1) ist erst seit ca. zwei Wochen aufgesetzt.
In den Backups des /var/lib/ ist immer das "proc" mit drin.

# ll /var/lib/ntp
insgesamt 16
drwxr-xr-x 2 root root 4096 8. Mai 10:43 dev
drwxr-xr-x 2 ntp messagebus 4096 26. Aug 11:30 drift
drwxr-xr-x 2 root root 4096 21. Aug 18:31 etc
dr-xr-xr-x 160 root root 0 26. Aug 07:28 proc
drwxr-xr-x 4 root root 4096 8. Mai 10:43 var

# ll /var/lib/named
insgesamt 460
-rw-r--r-- 1 root root 192 4. Jul 2001 127.0.0.zone
drwxr-xr-x 2 root root 4096 26. Aug 07:29 dev
drwxr-xr-x 2 named named 4096 26. Jan 2009 dyn
drwxr-xr-x 3 root root 4096 26. Aug 07:30 etc
-rw-r--r-- 1 named named 1242 26. Aug 08:03 key.zone.loc
-rw-r--r-- 1 named named 231246 26. Aug 07:50 key.zone.loc.jnl
-rw-r--r-- 1 named named 827 26. Aug 08:05 key.zone.loc.revers
-rw-r--r-- 1 named named 163872 26. Aug 07:50 key.zone.loc.revers.jnl
-rw-r--r-- 1 root root 158 4. Jul 2001 localhost.zone
drwxr-xr-x 2 named named 4096 26. Jan 2009 log
drwxr-xr-x 2 root root 4096 26. Jan 2009 master
dr-xr-xr-x 165 root root 0 26. Aug 07:28 proc
-rw-r--r-- 1 named named 251 28. Mär 16:58 zone.de
-rw-r--r-- 1 named named 285 28. Mär 16:59 zone.loc
-rw-r--r-- 1 named named 193 28. Mär 16:59 zone.loc.revers
-rw-r--r-- 1 root root 2878 26. Jan 2009 root.hint
drwxr-xr-x 2 named named 4096 26. Jan 2009 slave
drwxr-xr-x 4 root root 4096 17. Apr 07:14 var

Vielleicht hat jemand einen Tipp für mich.
Könnten das Hardlinks sein ?

cu
Huflatisch

 

[panamajo]

ntpd und named laufen in einer chroot Umgebung. Damit das funktioniert wird /proc nochmal ro auf /var/lib/.../proc gemountet.

 

[Tooltime]

Wie passiert den sowas?

In dem man ntp und named installiert und startet, oder einfacher ausgedrückt, das ist völlig normal. Beide Dienste laufen in einer chroot-Umgebung, ich nehme mal das Beispiel ntp. In einer chroot-Umgebung kann ein Programm nur auf Daten unterhalb des Neuen root-Verzeichnises zugreifen. Bei ntp ist das der Pfad /var/lib/ntp. Typisch für chroot-Umgebungen ist meistens ein Link auf sich selbst, damit die Pfade wieder stimmen.

• 
  /var/lib/ntp/var/lib/ntp/var/lib/ntp --> /var/lib/ntp
  Für einen Prozess in der chroot-Umgebung sieht es so aus.
  /var/lib/ntp --> /

Das macht man, damit innerhalb und außerhalb der chroot-Umgebung die Pfade identisch sind. Damit ntp die Systemuhr stellen kann braucht es Zugriff auf das proc-Dateisystem, daher wird dieses in die chroot-Umgebung gemountet.
Ausgabe von mount:

• 
  /proc on /proc type proc (rw)
  ...
  proc on /var/lib/ntp/proc type proc (ro)

 

[Huflatisch]

Hallo


.....mhh ....

Aber wiso ist das der einzige Rechner. Der Vorgänger mit der 99,9 % gleichen konfiguration hatte das nicht.
Und die anderen zwei haben auch keine gemounteten proc.

cu
Huflatisch

PS:
habe gerade das andere Posting mit einer sehr guten Erklärung gelesen und gleich mal die mount angeguckt. Werd mir das nochmal verinnerlichen und das Thema als gelöst betrachten.

Danke

/dev/md0 on / type ext3 (rw,acl,user_xattr)
/proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/md2 on /daten type ext3 (rw,acl,user_xattr)
/dev/md1 on /home type ext3 (rw,acl,user_xattr)
/dev/sdc1 on /mnt/750GB type ext3 (rw,acl,user_xattr)
securityfs on /sys/kernel/security type securityfs (rw)
/proc on /var/lib/named/proc type none (ro,bind)
/proc on /var/lib/ntp/proc type proc (ro)
//192.168.115.16/share on /mnt/nas-storage type cifs (rw,mand)

 

[Tooltime]

YaST --> System --> Editor für /etc/sysconfig-Dateien
Network --> NTP --> NTPD_RUN_CHROOTED YES/NO

Das kann man ein/ausschalten. Geht beim DNS-Server ähnlich. Vielleicht war das vorher (welche Version) noch nicht der Standard, oder jemand hatte es mit Absicht deaktiviert.

 

[Huflatisch]

Hey

Habe mir das nochmal auf verschiedenen Rechnern angeguckt

Auf allen PC laufen die Dienste unter CHROOT (die Dateien named und ntp unter sysconfig sind identisch)

NAMED_RUN_CHROOTED="yes"
NTPD_RUN_CHROOTED="yes"

PC1 Suse10.3, 2.6.22.19-0.2-default (keine proc Unterverzeichnisse)
PC2 Suse 11.1, 2.6.27.29-0.1-pae (keine proc Unterverzeichnisse)
PC3 Server Suse 11.1, 2.6.27.29-0.1-pae (proc Unterverzeichnisse vorhanden !!!)
auf PC3 Server läuft der dhcpd auch im chroot, hat aber kein extra proc Verzeichnis unterhalb /var/lib/dhcp
in der fstab stehen die extra proc nicht mit drin.

:???: :???: :???:
also für mich ist das noch nicht klar.


cu Huflatisch

 

[Tooltime]

Vielleicht habe ich mich ein wenig unklar ausgedrückt. Das proc-Filesystem muss nicht zwingend in einer chroot-Umgebung vorhanden, aber alle Dateien, Bibliotheken, Konfigurationsdateien u. ... die ein Programm in dieser Umgebung zur Laufzeit benötigt, müssen auch in der chroot-Umgebung vorhanden. Benötigt also ntp den Zugriff auf das proc-System, so muss dieses in das chroot gemountet werden, Links funktionieren da nicht.

In dem man ntp und named installiert und startet,

Das mounten geschieht in den Start/Stop-Scripten der einzelnen Dienste:

• 
  grep mount /etc/init.d/ntp
  grep mount /etc/init.d/named
  grep mount /etc/init.d/dhcpd

Da bei dhcpd kein mount-Befehl drin steht, kann man wohl davon ausgehen das kein spezielles Dateisystem benötigt wird.

Oder ein Beispiel das hier oft praktiziert wird, Installation des Bootmanager von einen Rescue-System. Dabei wechselt man vom Rettungssystem per chroot auf die Festplatte. (Hanbuch 11.1, ganz am Ende, unter der Überschrift "Zugriff auf das installierte System"):

• 
  /usr/share/doc/manual/opensuse-manual_de/manual/sec.trouble.data.html