Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
nfs-mount per fstab
0 views
Skip to first unread message
Uwe Kunze
Oct 11, 2020, 5:50:17 AM10/11/20
to
Hi@all,
ich möchte (auf einem eis-1) ein nfs-Dateisystem über die fstab einbinden.
Dazu habe ich (testhalber) sowohl einen anderen eis-1 als auch einen
Debian als nfs-Server konfiguriert und das Dateisystem (als nfsv4)
bereitgestellt.
Mounte ich das Dateisystem händisch, nachdem der eis-1 komplett
gestartet ist, funktioniert alles wunschgemäß.
Auch ein "mount -a" der in der fstab eingetragenen nfs-Verbindung klappt
problemlos, wenn der eis-1 (mit nfs-Server und nfs-client für andere
Zwecke) bereits läuft.
Der fstab-Eintrag sieht (beispielhaft) SO aus:
192.168.1.1:/freigabe /mointpoint nfs
nfsvers=4,nolock,rw,rsize=8192,wsize=8192 0 0
Jetzt das Problem:
Das Verbinden mit der nfs-Freigabe BEIM START des eis-1 funktioniert
nicht :-( Beim Booten versucht der eis eine (zeitlich begrenzte) Zeit
lang (vergeblich) auf die nfs-Freigabe zuzugreifen, was (ohne weitere
Fehlermeldung) erfolglos ist.
Es scheint mir, als ob die nfs-Funktionalität kurz nach dem Start des
Kernels und der Abarbeitung der fstab auf dem eis (noch) nicht zur
Verfügung steht.
Das spätere Einbinden des nfs-Dateisystems kommt leider nicht infrage
... ich brauche dringend das Dateisystem sofort beim Start ... was
könnte ich da tun ?
Einige Experimente mit verschiedenen Mount-Optionen habe ich schon
gemacht .... bislang ohne Erfolg.
Danke und schönen Sonntag.
Uwe
ich möchte (auf einem eis-1) ein nfs-Dateisystem über die fstab einbinden.
Dazu habe ich (testhalber) sowohl einen anderen eis-1 als auch einen
Debian als nfs-Server konfiguriert und das Dateisystem (als nfsv4)
bereitgestellt.
Mounte ich das Dateisystem händisch, nachdem der eis-1 komplett
gestartet ist, funktioniert alles wunschgemäß.
Auch ein "mount -a" der in der fstab eingetragenen nfs-Verbindung klappt
problemlos, wenn der eis-1 (mit nfs-Server und nfs-client für andere
Zwecke) bereits läuft.
Der fstab-Eintrag sieht (beispielhaft) SO aus:
192.168.1.1:/freigabe /mointpoint nfs
nfsvers=4,nolock,rw,rsize=8192,wsize=8192 0 0
Jetzt das Problem:
Das Verbinden mit der nfs-Freigabe BEIM START des eis-1 funktioniert
nicht :-( Beim Booten versucht der eis eine (zeitlich begrenzte) Zeit
lang (vergeblich) auf die nfs-Freigabe zuzugreifen, was (ohne weitere
Fehlermeldung) erfolglos ist.
Es scheint mir, als ob die nfs-Funktionalität kurz nach dem Start des
Kernels und der Abarbeitung der fstab auf dem eis (noch) nicht zur
Verfügung steht.
Das spätere Einbinden des nfs-Dateisystems kommt leider nicht infrage
... ich brauche dringend das Dateisystem sofort beim Start ... was
könnte ich da tun ?
Einige Experimente mit verschiedenen Mount-Optionen habe ich schon
gemacht .... bislang ohne Erfolg.
Danke und schönen Sonntag.
Uwe
Juergen Edner
Oct 11, 2020, 6:01:46 AM10/11/20
to
Hallo Uwe,
> Jetzt das Problem:
> Das Verbinden mit der nfs-Freigabe BEIM START des eis-1 funktioniert
> nicht :-( Beim Booten versucht der eis eine (zeitlich begrenzte) Zeit
> lang (vergeblich) auf die nfs-Freigabe zuzugreifen, was (ohne weitere
> Fehlermeldung) erfolglos ist.
um ein verlässliches Mounten von NFS-Freigaben sich zu stellen,
möchte ich Dir die Verwednung des nfsclient-Paketes nahe legen.
Ich nutze dies schon seit langer Zeit ohne zwischenzeitlich wieder
in die von Dir beschriebene Probleme gelaufen zu sein.
Gruß Jürgen
--
Mail: jue...@eisfair.org
> Jetzt das Problem:
> Das Verbinden mit der nfs-Freigabe BEIM START des eis-1 funktioniert
> nicht :-( Beim Booten versucht der eis eine (zeitlich begrenzte) Zeit
> lang (vergeblich) auf die nfs-Freigabe zuzugreifen, was (ohne weitere
> Fehlermeldung) erfolglos ist.
möchte ich Dir die Verwednung des nfsclient-Paketes nahe legen.
Ich nutze dies schon seit langer Zeit ohne zwischenzeitlich wieder
in die von Dir beschriebene Probleme gelaufen zu sein.
Gruß Jürgen
--
Mail: jue...@eisfair.org
Uwe Kunze
Oct 11, 2020, 6:11:37 AM10/11/20
to
Hallo Jürgen,
Danke für Deine schnelle Antwort.
Das nfsclient-Paket ist auf dem eis-1 bereits installiert und (für
andere Freigaben) in Verwendung.
Das Problem ist aber meines Erachtens, dass das Paket die nfs-Freigabe
"ZU SPÄT" einbindet.
Wenn ich beispielsweise auf der nfs-Freigabe das System-Logging
(messages ...) abwickeln will oder mysql-Datenbanken darauf starten
will, steht das Dateisystem noch garnicht zur Verfügung.
Wie schon geschrieben ... ich brauche das nfs-Dateisystem unmittelbar
nach dem Booten des Kernels .... in DEM Moment, in dem auch die lokalen
Dateisysteme verfügbar gemacht werden.
Ist das irgendwie machbar ?
Gruß Uwe
Danke für Deine schnelle Antwort.
andere Freigaben) in Verwendung.
Das Problem ist aber meines Erachtens, dass das Paket die nfs-Freigabe
"ZU SPÄT" einbindet.
Wenn ich beispielsweise auf der nfs-Freigabe das System-Logging
(messages ...) abwickeln will oder mysql-Datenbanken darauf starten
will, steht das Dateisystem noch garnicht zur Verfügung.
Wie schon geschrieben ... ich brauche das nfs-Dateisystem unmittelbar
nach dem Booten des Kernels .... in DEM Moment, in dem auch die lokalen
Dateisysteme verfügbar gemacht werden.
Ist das irgendwie machbar ?
Gruß Uwe
Juergen Edner
Oct 11, 2020, 6:25:29 AM10/11/20
to
Hallo Uwe,
> Wenn ich beispielsweise auf der nfs-Freigabe das System-Logging
> (messages ...) abwickeln will oder mysql-Datenbanken darauf starten
> will, steht das Dateisystem noch garnicht zur Verfügung.
>
> Wie schon geschrieben ... ich brauche das nfs-Dateisystem unmittelbar
> nach dem Booten des Kernels .... in DEM Moment, in dem auch die lokalen
> Dateisysteme verfügbar gemacht werden.
Dies ist meines Erachtens so nicht machbar, dass Netzwerkzugriffe
erst zu einem deutlich späteren Zeitpunkt möglich sind.
> Ist das irgendwie machbar ?
Generell finde ich den Ansatz Systemmeldungen oder Datenbanken per
Dateizugriff auf einer NFS-Freigabe abzulegen suboptimal, da ein
solcher Zugriff häufig deutlich langsamer als ein direkter Netzwerk-
zugriff ist.
Auf Datenbanken kann man direkt über die Netzwerkschnittstelle
zugreifen, sodass das Ablegen einer Datenbank auf einer Freigabe
nicht erforderlich ist.
Wenn Du darüber hinaus an Stelle des syslogd-Paketes das rsyslogd-
Paket verwendest, kannst Du meines Erachtens über das Netzwerk alle
Meldungen direkt in eine entfernte Datenbank schreiben lassen.
> Wenn ich beispielsweise auf der nfs-Freigabe das System-Logging
> (messages ...) abwickeln will oder mysql-Datenbanken darauf starten
> will, steht das Dateisystem noch garnicht zur Verfügung.
>
> Wie schon geschrieben ... ich brauche das nfs-Dateisystem unmittelbar
> nach dem Booten des Kernels .... in DEM Moment, in dem auch die lokalen
> Dateisysteme verfügbar gemacht werden.
erst zu einem deutlich späteren Zeitpunkt möglich sind.
> Ist das irgendwie machbar ?
Dateizugriff auf einer NFS-Freigabe abzulegen suboptimal, da ein
solcher Zugriff häufig deutlich langsamer als ein direkter Netzwerk-
zugriff ist.
Auf Datenbanken kann man direkt über die Netzwerkschnittstelle
zugreifen, sodass das Ablegen einer Datenbank auf einer Freigabe
nicht erforderlich ist.
Wenn Du darüber hinaus an Stelle des syslogd-Paketes das rsyslogd-
Paket verwendest, kannst Du meines Erachtens über das Netzwerk alle
Meldungen direkt in eine entfernte Datenbank schreiben lassen.
Marcus Röckrath
Oct 11, 2020, 8:20:02 AM10/11/20
to
Hallo Uwe,
Uwe Kunze wrote:
> Das Problem ist aber meines Erachtens, dass das Paket die nfs-Freigabe
> "ZU SPÄT" einbindet.
>
> Wenn ich beispielsweise auf der nfs-Freigabe das System-Logging
> (messages ...) abwickeln will oder mysql-Datenbanken darauf starten
> will, steht das Dateisystem noch garnicht zur Verfügung.
Wie auch. Als erstes wird / RW gemountet und damit messages verfügbar
gemacht, bevor dann die init-Skripte abgearbeitet werden.
--
Gruß Marcus
[eisfair-Team]
Uwe Kunze wrote:
> Das Problem ist aber meines Erachtens, dass das Paket die nfs-Freigabe
> "ZU SPÄT" einbindet.
>
> Wenn ich beispielsweise auf der nfs-Freigabe das System-Logging
> (messages ...) abwickeln will oder mysql-Datenbanken darauf starten
> will, steht das Dateisystem noch garnicht zur Verfügung.
gemacht, bevor dann die init-Skripte abgearbeitet werden.
--
Gruß Marcus
[eisfair-Team]
Uwe Kunze
Oct 12, 2020, 2:49:30 AM10/12/20
to
Moin Marcus, Jürgen, Derya,
>> Wenn ich beispielsweise auf der nfs-Freigabe das System-Logging
>> (messages ...) abwickeln will oder mysql-Datenbanken darauf starten
>> will, steht das Dateisystem noch garnicht zur Verfügung.
>
> Wie auch. Als erstes wird / RW gemountet und damit messages verfügbar
> gemacht, bevor dann die init-Skripte abgearbeitet werden.
ich habe das mal interessehalber mit einer anderen Distri probiert:
Debian als NFS-Server, Ubuntu als Client.
Dort klappt das Einbinden von nfs-Shares über die fstab genau SO, wie
ich mir das auf dem eis vorgestellt hatte. Offenbar sind dort die
nfs-Module in der initrd eingebunden (wie Derya auch als Lösungsansatz
für meine Frage für den eis vorschlug) und können sofort nach dem
Starten des Kernel benutzt werden.
Evtl. experimentiere ich mal mit der initrd ... oder mache mir nochmal
Gedanken, wie ich auch ohne nfs klarkomme.
Auf jeden Fall Danke für Eure Rückmeldungen.
Gruß Uwe
>> Wenn ich beispielsweise auf der nfs-Freigabe das System-Logging
>> (messages ...) abwickeln will oder mysql-Datenbanken darauf starten
>> will, steht das Dateisystem noch garnicht zur Verfügung.
>
> Wie auch. Als erstes wird / RW gemountet und damit messages verfügbar
> gemacht, bevor dann die init-Skripte abgearbeitet werden.
Debian als NFS-Server, Ubuntu als Client.
Dort klappt das Einbinden von nfs-Shares über die fstab genau SO, wie
ich mir das auf dem eis vorgestellt hatte. Offenbar sind dort die
nfs-Module in der initrd eingebunden (wie Derya auch als Lösungsansatz
für meine Frage für den eis vorschlug) und können sofort nach dem
Starten des Kernel benutzt werden.
Evtl. experimentiere ich mal mit der initrd ... oder mache mir nochmal
Gedanken, wie ich auch ohne nfs klarkomme.
Auf jeden Fall Danke für Eure Rückmeldungen.
Gruß Uwe
Holger Bruenjes
Oct 12, 2020, 3:11:06 AM10/12/20
to
Hallo Uwe
On 12/10/2020 08.49, Uwe Kunze wrote:
> ich habe das mal interessehalber mit einer anderen Distri probiert:
> Debian als NFS-Server, Ubuntu als Client.
da laeuft auch systemd, der das regelt ;-)
Holger
On 12/10/2020 08.49, Uwe Kunze wrote:
> ich habe das mal interessehalber mit einer anderen Distri probiert:
> Debian als NFS-Server, Ubuntu als Client.
Holger
Marcus Röckrath
Oct 12, 2020, 3:40:02 AM10/12/20
to
Hallo Uwe,
Uwe Kunze wrote:
Uwe Kunze wrote:
>>> Wenn ich beispielsweise auf der nfs-Freigabe das System-Logging
>>> (messages ...) abwickeln will oder mysql-Datenbanken darauf starten
>>> will, steht das Dateisystem noch garnicht zur Verfügung.
>>
>> Wie auch. Als erstes wird / RW gemountet und damit messages verfügbar
>> gemacht, bevor dann die init-Skripte abgearbeitet werden.
>
> ich habe das mal interessehalber mit einer anderen Distri probiert:
> Debian als NFS-Server, Ubuntu als Client.
> Dort klappt das Einbinden von nfs-Shares über die fstab genau SO, wie
> ich mir das auf dem eis vorgestellt hatte.
Auch für die messages?
>>> (messages ...) abwickeln will oder mysql-Datenbanken darauf starten
>>> will, steht das Dateisystem noch garnicht zur Verfügung.
>>
>> Wie auch. Als erstes wird / RW gemountet und damit messages verfügbar
>> gemacht, bevor dann die init-Skripte abgearbeitet werden.
>
> ich habe das mal interessehalber mit einer anderen Distri probiert:
> Debian als NFS-Server, Ubuntu als Client.
> Dort klappt das Einbinden von nfs-Shares über die fstab genau SO, wie
> ich mir das auf dem eis vorgestellt hatte.
Legst du dafür eigentlich /var/log auf die NFS-Share?
--
Gruß Marcus
[eisfair-Team]
Olaf Jaehrling
Oct 12, 2020, 6:05:37 AM10/12/20
to
Hallo Uwe,
Uwe Kunze schrieb am 11.10.20 um 11:50:
> Hi@all,
Vllt. Wird das dann ja so in Eisfair implementiert.
Gruß
Olaf
>
> Danke und schönen Sonntag.
> Uwe
--
Packageserver: https://ojaehrling.de/eis/index.txt
Uwe Kunze schrieb am 11.10.20 um 11:50:
> Hi@all,
>
>
> Es scheint mir, als ob die nfs-Funktionalität kurz nach dem Start des
> Kernels und der Abarbeitung der fstab auf dem eis (noch) nicht zur
> Verfügung steht.
>
> Das spätere Einbinden des nfs-Dateisystems kommt leider nicht infrage
> ... ich brauche dringend das Dateisystem sofort beim Start ... was
> könnte ich da tun ?
>
> Einige Experimente mit verschiedenen Mount-Optionen habe ich schon
> gemacht .... bislang ohne Erfolg.
Du hast PM. Sollte es so funktionieren kannst du die Lösung ja hier posten.
>
> Es scheint mir, als ob die nfs-Funktionalität kurz nach dem Start des
> Kernels und der Abarbeitung der fstab auf dem eis (noch) nicht zur
> Verfügung steht.
>
> Das spätere Einbinden des nfs-Dateisystems kommt leider nicht infrage
> ... ich brauche dringend das Dateisystem sofort beim Start ... was
> könnte ich da tun ?
>
> Einige Experimente mit verschiedenen Mount-Optionen habe ich schon
> gemacht .... bislang ohne Erfolg.
Vllt. Wird das dann ja so in Eisfair implementiert.
Gruß
Olaf
>
> Danke und schönen Sonntag.
> Uwe
Packageserver: https://ojaehrling.de/eis/index.txt
Hilix
Oct 12, 2020, 6:13:11 AM10/12/20
to
Hallo Olaf, mich würde Dein Lösungsvorschlag interessieren, ob läuft oder nicht...
Gruß./ Hilmar.
Am 12.10.20 um 12:05 schrieb Olaf Jaehrling:
Gruß./ Hilmar.
Am 12.10.20 um 12:05 schrieb Olaf Jaehrling:
Olaf Jaehrling
Oct 13, 2020, 4:17:36 PM10/13/20
to
Hallo Hilmar
Hilix schrieb am 12.10.20 um 12:13:> Hallo Olaf, mich würde Dein
geben.
Gruß
Olaf
Hilix schrieb am 12.10.20 um 12:13:> Hallo Olaf, mich würde Dein
Lösungsvorschlag interessieren, ob läuft
> oder nicht...
> Gruß./ Hilmar.
Ich habe dir die PM mal geschickt. Vllt. kannst du ja eine Rückmeldung
> oder nicht...
> Gruß./ Hilmar.
geben.
Gruß
Olaf
Hilix
Oct 15, 2020, 11:38:49 AM10/15/20
to
Hallo Olaf,
vielen Dank für die Info. Ich habe mich mal mit dem Problem bzw. einer evtl. Lösung beschäftigt und bin zu dem Schluss gekommen,
dass
- _ohne eine Änderung der Start-Skript-Reihenfolge_ NFS_shares _vor_ dem Start des S40syslogd Service
- oder noch früher im Rahmen des S07mountfs Skripts (noch kein Netzwerk aktiv)
nicht möglich sind.
Anmerkungen:
1) mount.nfs scheint zu "hängen".
Dieses Phänomen hatte ich auch. Das kann ich bestätigen. Bei mir wird aber noch der Startzeitpunkt angezeigt:
mount.nfs: timeout set for Thu Oct 15 14:19:05 2020"
Das Timeout beträgt standardmäßig (bei mir) 120s. Es gibt auch eine mount.nfs Option "timeo=n" Damit könnte man das Timeout
mglw. verkürzen. Grund waren in meinen Fälle Mountprobleme z.B. wg. Fehler im remotetarget String (permissions) oder falscher
Optionen im mount Befehl. (Vllt auch wg. inkompatibler NFS-Protokoll-Versionen - da bin ich mir aber nicht sicher.) Nach
Korrektur im Setup->NFSclient-Service - Setup läuft bei mir der NFS_Mount ohne Stop durch. Allerdings wirft das
S07mountfs-Skript immer die Meldung aus:
mount.nfs: timeout set for Thu Oct 15 14:19:05 2020
mount.nfs: trying text-based options 'vers=4.2,addr=172.16.0.14,clientaddr=0.0.0.0'
Man beachte: clientaddr=0.0.0.0
Ist aber logisch, da die Netzwerkaktivierung erst mit "S25ip-eth" startet. Deswegen ist zu diesem frühen Zeitpunkt auch kein
Netzwerk-Mount möglich.
2) Versuch,
Netzwerkaktivierung vor S07mountfs zu verlegen (S04ip-eth, S05route, S06nfsclient), führt zum gleichen Problem mit
"clientaddr=0.0.0.0" --> kein Mount des NFS-Share. Vllt fehlt auch da noch ein Skript (vorne)?
3) Versuch
Standard rc2.d Startreihenfolge, aber nfsclient _vor_ S40syslogd gestellt, z.B. S38nfsclient.
Das funktioniert und würde ggf. helfen, da das NFS-Share vor Start des syslogd Service liegt.
4) Allerdings
muss man sich halt bewusst sein, dass eine Änderung der Abfolge der Start-Skripts in rc2.d:
- zu unpredictable side effects führen kann
- ggf. bei einer System-Aktualisierung diese überschrieben geändert werden kann und
- dass es von den Entwicklern sehr ungern gesehen wird! :)
Ich würde mich daher Jürgens Vorschlag anschließen, sich mit rsyslogd zu beschäftigen.
Grüße. / Hilmar.
P.S. Ich vergaß zu erwähnen, dass NFS-Shares mit Eisfair als Client ganz einwandfrei eingerichtet und genutzt werden können. :-)
Am 13.10.20 um 22:17 schrieb Olaf Jaehrling:
vielen Dank für die Info. Ich habe mich mal mit dem Problem bzw. einer evtl. Lösung beschäftigt und bin zu dem Schluss gekommen,
dass
- _ohne eine Änderung der Start-Skript-Reihenfolge_ NFS_shares _vor_ dem Start des S40syslogd Service
- oder noch früher im Rahmen des S07mountfs Skripts (noch kein Netzwerk aktiv)
nicht möglich sind.
Anmerkungen:
1) mount.nfs scheint zu "hängen".
Dieses Phänomen hatte ich auch. Das kann ich bestätigen. Bei mir wird aber noch der Startzeitpunkt angezeigt:
mount.nfs: timeout set for Thu Oct 15 14:19:05 2020"
Das Timeout beträgt standardmäßig (bei mir) 120s. Es gibt auch eine mount.nfs Option "timeo=n" Damit könnte man das Timeout
mglw. verkürzen. Grund waren in meinen Fälle Mountprobleme z.B. wg. Fehler im remotetarget String (permissions) oder falscher
Optionen im mount Befehl. (Vllt auch wg. inkompatibler NFS-Protokoll-Versionen - da bin ich mir aber nicht sicher.) Nach
Korrektur im Setup->NFSclient-Service - Setup läuft bei mir der NFS_Mount ohne Stop durch. Allerdings wirft das
S07mountfs-Skript immer die Meldung aus:
mount.nfs: timeout set for Thu Oct 15 14:19:05 2020
mount.nfs: trying text-based options 'vers=4.2,addr=172.16.0.14,clientaddr=0.0.0.0'
Man beachte: clientaddr=0.0.0.0
Ist aber logisch, da die Netzwerkaktivierung erst mit "S25ip-eth" startet. Deswegen ist zu diesem frühen Zeitpunkt auch kein
Netzwerk-Mount möglich.
2) Versuch,
Netzwerkaktivierung vor S07mountfs zu verlegen (S04ip-eth, S05route, S06nfsclient), führt zum gleichen Problem mit
"clientaddr=0.0.0.0" --> kein Mount des NFS-Share. Vllt fehlt auch da noch ein Skript (vorne)?
3) Versuch
Standard rc2.d Startreihenfolge, aber nfsclient _vor_ S40syslogd gestellt, z.B. S38nfsclient.
Das funktioniert und würde ggf. helfen, da das NFS-Share vor Start des syslogd Service liegt.
4) Allerdings
muss man sich halt bewusst sein, dass eine Änderung der Abfolge der Start-Skripts in rc2.d:
- zu unpredictable side effects führen kann
- ggf. bei einer System-Aktualisierung diese überschrieben geändert werden kann und
- dass es von den Entwicklern sehr ungern gesehen wird! :)
Ich würde mich daher Jürgens Vorschlag anschließen, sich mit rsyslogd zu beschäftigen.
Grüße. / Hilmar.
P.S. Ich vergaß zu erwähnen, dass NFS-Shares mit Eisfair als Client ganz einwandfrei eingerichtet und genutzt werden können. :-)
Am 13.10.20 um 22:17 schrieb Olaf Jaehrling:
Olaf Jaehrling
Oct 15, 2020, 4:16:21 PM10/15/20
to
Hallo Hilmar,
Hilix schrieb am 15.10.20 um 17:38:
Gruß
Olaf
--
Paketserver: https://ojaehrling.de/eis/index.txt
Hilix schrieb am 15.10.20 um 17:38:
> Hallo Olaf,
> vielen Dank für die Info. Ich habe mich mal mit dem Problem bzw. einer
> evtl. Lösung beschäftigt und bin zu dem Schluss gekommen, dass
> - _ohne eine Änderung der Start-Skript-Reihenfolge_ NFS_shares _vor_ dem
> Start des S40syslogd Service
> - oder noch früher im Rahmen des S07mountfs Skripts (noch kein Netzwerk
> aktiv)
> nicht möglich sind.
>
Danke für deine Rückmeldung.
> vielen Dank für die Info. Ich habe mich mal mit dem Problem bzw. einer
> evtl. Lösung beschäftigt und bin zu dem Schluss gekommen, dass
> - _ohne eine Änderung der Start-Skript-Reihenfolge_ NFS_shares _vor_ dem
> Start des S40syslogd Service
> - oder noch früher im Rahmen des S07mountfs Skripts (noch kein Netzwerk
> aktiv)
> nicht möglich sind.
>
Gruß
Olaf
--
Paketserver: https://ojaehrling.de/eis/index.txt
Uwe Kunze
Oct 17, 2020, 8:55:29 AM10/17/20
to
Hi Olaf,
> Du hast PM. Sollte es so funktionieren kannst du die Lösung ja hier posten.
> Vllt. Wird das dann ja so in Eisfair implementiert.
Du hast ebenfalls PM.
Mit einer kleinen Änderung der Reihenfolge der Startscripts
(/etc/rc2.d/S04ip-eth statt /etc/rc2.d/S25ip-eth) habe ich das Mounten
von nfs-Freigaben per fstab hinbekommen .... einschließlich der
Verwendung eines nfs-Shares als /var/log.
Nachteile daraus habe ich bislang nicht feststellen können .... weder
aus der "Vorverlegung" von ip-eth noch Performance-Probleme für das Logging.
Als Server dient in meiner Testumgebung ein Debian-NFS-Server (nfs
Version4), als Client ein eis-1 ... das Ganze virtuell auf Proxmox.
Gruß Uwe
> Du hast PM. Sollte es so funktionieren kannst du die Lösung ja hier posten.
> Vllt. Wird das dann ja so in Eisfair implementiert.
Mit einer kleinen Änderung der Reihenfolge der Startscripts
(/etc/rc2.d/S04ip-eth statt /etc/rc2.d/S25ip-eth) habe ich das Mounten
von nfs-Freigaben per fstab hinbekommen .... einschließlich der
Verwendung eines nfs-Shares als /var/log.
Nachteile daraus habe ich bislang nicht feststellen können .... weder
aus der "Vorverlegung" von ip-eth noch Performance-Probleme für das Logging.
Als Server dient in meiner Testumgebung ein Debian-NFS-Server (nfs
Version4), als Client ein eis-1 ... das Ganze virtuell auf Proxmox.
Gruß Uwe
Hilix
Oct 18, 2020, 11:45:59 AM10/18/20
to
Hallo,
wie Uwe jetzt berichtet hat, funktioniert bei ihm der NFS-Mount seines Log-Shares aus S07mountfs heraus. Schön für ihn. :-)
Ich weiss jetzt aber warum: Uwe benutzt ein E1-System; ich habe auf einem E64 als NFS-Client getestet. Beim E64-System wird das
Netzwerk NICHT initialisiert, wenn ip-eth als S04/5/6ip-eth vor das S07mountfs gezogen wird.
Und das, obwohl sowohl die Reihenfolde der Startscripts als auch die jeweiligen ip-eth Skripte identisch sind. (Kernel?)
Zum Test habe ich eine Eisfair-1 und eine Eisfair-64 VM neu aufgesetzt und in gleicher Weise als NFS-Client konfiguriert. Der
NFS-Server ist mein KVM-Host mit Debian-10 und NFS V4 Server.
==> Insofern schränke ich meinen Testbericht unten auf Eisfair-64 ein.
Viele Grüße. / Hilmar.
P.S.:
Bzgl. Log-Messages beim Systemstart werden nach meinem Verständnis solche bis zur Aktivierung der entsprechenden Log-Daemons
(Syslogd, Klogd) im Speicher gepuffert und nach Aktivierung in die entsprechenden Dateien raus geschrieben. Wenn man, wie
beschrieben "S47nfsclient" auf S38nfsclient vorzieht, müsste es auch mit E64 klappen. Ansonsten "rsyslogd". Oft haben
Applikationen wie Datenbanken auch ihre eigenen remote log Mechnismen...
Am 15.10.20 um 17:38 schrieb Hilix:
D. Oezbilen
Oct 18, 2020, 12:41:35 PM10/18/20
to
Hallo Uwe,
> Evtl. experimentiere ich mal mit der initrd ... oder mache mir nochmal
> Gedanken, wie ich auch ohne nfs klarkomme.
> Auf jeden Fall Danke für Eure Rückmeldungen.
eine kleine Ergaenzung, vergass es in der Mial zu erwaehnen:
PXE bootet ueber das LAN ein Betriebssystem, eben auch per nfs-Mount.
Gruss
Derya
> Evtl. experimentiere ich mal mit der initrd ... oder mache mir nochmal
> Gedanken, wie ich auch ohne nfs klarkomme.
> Auf jeden Fall Danke für Eure Rückmeldungen.
PXE bootet ueber das LAN ein Betriebssystem, eben auch per nfs-Mount.
Gruss
Derya
Olaf Jaehrling
Oct 18, 2020, 12:45:30 PM10/18/20
to
Hallo Holger, hallo Jürgen
Uwe Kunze schrieb am 17.10.20 um 14:55:
1. /etc/rc2.d/S25ip-eth nach /etc/rc2.d/S04ip-eth verschoben wird
2. /etc/rc2.d/S47nfsclient" nach /etc/rc2.d/S38nfsclient verschoben wird.
Dadurch wird das Netzwerk vor dem Mounten aus S07 hochgefahren und der
Clientservice vor dem Starten des syslogd seinen Job beginnen.
Natürlich kann man auch rsyslogd verwenden, aber warum ein zusätzliches
Paket installieren wenn es mit Bordmittel geht.
Danke und Gruß
Uwe Kunze schrieb am 17.10.20 um 14:55:
> Hi Olaf,
>
>> Du hast PM. Sollte es so funktionieren kannst du die Lösung ja hier
>> posten.
>> Vllt. Wird das dann ja so in Eisfair implementiert.
>
> Du hast ebenfalls PM.
>
> Mit einer kleinen Änderung der Reihenfolge der Startscripts
> (/etc/rc2.d/S04ip-eth statt /etc/rc2.d/S25ip-eth) habe ich das Mounten
> von nfs-Freigaben per fstab hinbekommen .... einschließlich der
> Verwendung eines nfs-Shares als /var/log.
Zusammegefasst auf Uwe und Hilmars Antworten würde es funktionieren wenn:
>
>> Du hast PM. Sollte es so funktionieren kannst du die Lösung ja hier
>> posten.
>> Vllt. Wird das dann ja so in Eisfair implementiert.
>
> Du hast ebenfalls PM.
>
> Mit einer kleinen Änderung der Reihenfolge der Startscripts
> (/etc/rc2.d/S04ip-eth statt /etc/rc2.d/S25ip-eth) habe ich das Mounten
> von nfs-Freigaben per fstab hinbekommen .... einschließlich der
> Verwendung eines nfs-Shares als /var/log.
1. /etc/rc2.d/S25ip-eth nach /etc/rc2.d/S04ip-eth verschoben wird
2. /etc/rc2.d/S47nfsclient" nach /etc/rc2.d/S38nfsclient verschoben wird.
Dadurch wird das Netzwerk vor dem Mounten aus S07 hochgefahren und der
Clientservice vor dem Starten des syslogd seinen Job beginnen.
Natürlich kann man auch rsyslogd verwenden, aber warum ein zusätzliches
Paket installieren wenn es mit Bordmittel geht.
Danke und Gruß
Hilix
Oct 18, 2020, 1:27:59 PM10/18/20
to
Am 18.10.20 um 18:45 schrieb Olaf Jaehrling:
> Zusammegefasst auf Uwe und Hilmars Antworten würde es funktionieren wenn:
> 1. /etc/rc2.d/S25ip-eth nach /etc/rc2.d/S04ip-eth verschoben wird
! S25ip-eth --> S04ip-eth wirkt NUR bei Eisfair-1!
> Zusammegefasst auf Uwe und Hilmars Antworten würde es funktionieren wenn:
> 1. /etc/rc2.d/S25ip-eth nach /etc/rc2.d/S04ip-eth verschoben wird
> 2. /etc/rc2.d/S47nfsclient" nach /etc/rc2.d/S38nfsclient verschoben wird.
Bei E1 und E64: S25ip-eth bleibt, S47nfsclient --> S38nfsclient
>
> Dadurch wird das Netzwerk vor dem Mounten aus S07 hochgefahren
!nur bei Eisfair-1!
> Dadurch wird das Netzwerk vor dem Mounten aus S07 hochgefahren
> und der Clientservice vor dem Starten des syslogd seinen Job beginnen.
Gruß. / Hilmar.
Kay Martinen
Oct 22, 2020, 2:50:02 PM10/22/20
to
Am 18.10.20 um 18:41 schrieb D. Oezbilen:
Wird da nicht üblicherweise eine imagedatei geladen oder generell lesend
zugegriffen? Damit wird die gewiß ins RAM geladen und gestartet - was
noch nicht bedeutet das der kernel dann ein root-filesystem ebenfalls
auf einem nfs-mount haben muß. Und das muß auch nicht der gleiche mount
sein.
Ähnliches erinnere ich vom PXE vorläufer. Dort wurde das image per tftp
geladen, gestartet und konnte dann AFAIR wahlweise eine ramdisk, ein
lokales lw oder auch einen nfs-mount nutzen. Wobei es früher IMHO üblich
war den /usr zweig per nfs vom server zu exportieren. Damit waren dann
auch alle programme dort verfügbar.
Kay
--
Posted via leafnode
zugegriffen? Damit wird die gewiß ins RAM geladen und gestartet - was
noch nicht bedeutet das der kernel dann ein root-filesystem ebenfalls
auf einem nfs-mount haben muß. Und das muß auch nicht der gleiche mount
sein.
Ähnliches erinnere ich vom PXE vorläufer. Dort wurde das image per tftp
geladen, gestartet und konnte dann AFAIR wahlweise eine ramdisk, ein
lokales lw oder auch einen nfs-mount nutzen. Wobei es früher IMHO üblich
war den /usr zweig per nfs vom server zu exportieren. Damit waren dann
auch alle programme dort verfügbar.
Kay
--
Posted via leafnode
Kay Martinen
Oct 22, 2020, 3:00:01 PM10/22/20
to
Am 11.10.20 um 12:11 schrieb Uwe Kunze:
Da geht das dann alles an den syslog port raus und auf dem zentralen
logserver (dafür gibt's sogar ne dhcp-direktive) kannst du dann damit
machen was du willst. Auch in eine Datenbank schmeißen.
> oder mysql-Datenbanken darauf starten
> will, steht das Dateisystem noch garnicht zur Verfügung.
mysql ist doch auch netzwerk-fähig. Mir leuchtet nicht ein warum du
nicht die möglichen Features nutzt und stattdessen Abseitige Pfade begehst.
Willst du die Zahl der offenen Ports klein halten, verschlüsselt
übertragen oder etwas anderes?
>
>>> Jetzt das Problem:
>>> Das Verbinden mit der nfs-Freigabe BEIM START des eis-1 funktioniert
>>> nicht :-( Beim Booten versucht der eis eine (zeitlich begrenzte) Zeit
>>> Jetzt das Problem:
>>> Das Verbinden mit der nfs-Freigabe BEIM START des eis-1 funktioniert
>>> nicht :-( Beim Booten versucht der eis eine (zeitlich begrenzte) Zeit
> Wenn ich beispielsweise auf der nfs-Freigabe das System-Logging
> (messages ...) abwickeln will
Zeit synchron halten und remote logging aktivieren ist keine option?
> (messages ...) abwickeln will
Da geht das dann alles an den syslog port raus und auf dem zentralen
logserver (dafür gibt's sogar ne dhcp-direktive) kannst du dann damit
machen was du willst. Auch in eine Datenbank schmeißen.
> oder mysql-Datenbanken darauf starten
> will, steht das Dateisystem noch garnicht zur Verfügung.
nicht die möglichen Features nutzt und stattdessen Abseitige Pfade begehst.
Willst du die Zahl der offenen Ports klein halten, verschlüsselt
übertragen oder etwas anderes?
D. Oezbilen
Oct 22, 2020, 7:43:06 PM10/22/20
to
Hallo Kay,
> Ähnliches erinnere ich vom PXE vorläufer.
Novellboot-ROM oder IBM Boot per RPL .
> war den /usr zweig per nfs vom server zu exportieren. Damit waren dann
> auch alle programme dort verfügbar.
Was/wie es erfolgte, die Aussage ist doch, dass diese Einheiten *keine*
HD haben mussten, konnten, musste man nicht benutzen. Sprich diskless.
Dann wurde halt aus dem Kernel ein nfs eingebunden und das BS gestartet.
Sprich, wenn man NFS braucht, muss man nicht zwangsweise eine HD haben,
man kann direkt aus der initrd nfs starten.
Gruss
Derya
> Ähnliches erinnere ich vom PXE vorläufer.
> war den /usr zweig per nfs vom server zu exportieren. Damit waren dann
> auch alle programme dort verfügbar.
HD haben mussten, konnten, musste man nicht benutzen. Sprich diskless.
Dann wurde halt aus dem Kernel ein nfs eingebunden und das BS gestartet.
Sprich, wenn man NFS braucht, muss man nicht zwangsweise eine HD haben,
man kann direkt aus der initrd nfs starten.
Gruss
Derya
0 new messages