[Eisfair] [E64] fuse.sshfs in /etc/fstab -> wrong fs type

Marcus Roeckrath marcus.roeckrath at gmx.de
Mo Okt 7 20:40:31 CEST 2019


Hallo Rolf,

Rolf Bensch wrote:

> if fand in "man mount" folgendes:
> _netdev
> The filesystem resides on a device that requires network access (used to
> prevent the system from attempting to mount these filesystems until the
> network has been enabled on the system).
> 
> Für mich klingt das so, dass "system" solange mit dem mount wartet bis
> "network enabled" ist.

Könnte auch bedeuten, dass ein solch deklarierter Mount ohne Netzwerk
unberücksichtigt bleibt.

Möglicherweise macht das nur mit systemd statt SysV-Init-system einen Sinn.
Auf einen SysV-Init-System werden die Initskripte nacheinander
abgearbeitet, also würde hier ein warten im mount-Initskript nichts
bringen, denn dann käme es nicht zum Starten des Netzwerkes, sondern erst,
wenn es nach einem Timeout weitergeht.

Systemd arbeitet parallel.

> mit _netdev ohne weitere Parameter erhalte ich beim booten die
> Fehlermeldung:
> ....
> /dev                       : already mounted
> random: ssh: uninitialized urandom read (5 bytes read, 49 bits of
> entropy available)
> random: nonblocking pool is initialized                   [FAIL]
> 
> dann booted der Server aber rasch durch.

Das ist ein anderes Problem. Beim Boot ist der Entropiepool erst noch so
mager gefüllt, dass er für bestimmte Anforderungen zunächst nicht genügend
Elemente enthält.

Abhilfe könnte das haveged-Paket schaffen, der aber auch erst nach dem
Mountskript gestartet wird.

>> setzen. Das soll den Mount vornehmen, aber erst beim ersten Zugriff
>> aktivieren.
> 
> ...
> /dev                            : already mounted
> /home                           : sucessfully mounted             [ OK ]
> Ext4-fs (vda3); remount.....
> .....
> NET: Registered protocol family 10
> random: named: uninitalized urandom read (10 bytes read, 56 bits of
> entropy available)                                                [ OK ]

s. o. zu wenig Entropie beim Boot vorhanden.

> Hier hängt der Bootvorgang für 3,5 Minuten, geht dann aber mit [ OK ]
> weiter. Nach dem Login ist aber /home verbunden und kann auch verwendet
> werden.

Kommt auf Server wegen oft wenig Interaktion (Maus, Tastatur, ...) häufiger
als auf Desktops vor. Der in Testphase befindliche neue Kernel 4.9.
reagiert da noch empfindlicher, so dass wir da gegensteuern müssen.

Da kann man auch darüber nachdenken, den Entropiepool beim Runterfahren zu
sichern und beim Boot wieder einzuspielen. Linus Thorvalds arbeitet gerade
daran, dem neuen 5er-Kernel mehr Entropie beizubringen, da immer mehr Dinge
sich aus diesem z. B. zur Erstellung von (temporären) Schlüsseln bedienen
müssen.

Mehr Sicherheit bedingt mehr Zufall also mehr Daten aus einem Entropiepool.

-- 
Gruss Marcus


Mehr Informationen über die Mailingliste Eisfair