[gentoo-dev] Re: rfc: openrc mount service prototype

[Duncan]

Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as excerpted:

> On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev <alonbl@g.o>
> wrote:
>
>> On 29 July 2015 at 23:20, William Hubbs <williamh@g.o> wrote:
>>>
>>> so that there is a better idea out there of what I'm talking about,
>>> the OpenRC github repository now has a mount-service branch.
>>
>> But I still trying to figure out why do we need to keep fstab around.
>> It is pure legacy.
>>
>>
> On what planet is fstab pure legacy? Many utilities use it and expect it
> to exist. For example the ability to do "mount /foo" requires a properly
> configured fstab file (also mount -a).
>
> AFAIK even systemd needs a fstab file if you want to do anything that
> it can't autodetect by probing the system.

Based on systemd documentation and experience...

Systemd doesn't require an fstab file; its mount units are valid 
replacements.  But systemd _does_ still recommend using fstab at least 
for normal admin-configured mounts, in preference to its own mount-unit 
alternative.  So systemd doesn't consider fstab legacy.

Systemd ships systemd-fstab-generator[1], which parses /etc/fstab and 
places its dynamically created mount units in /run/systemd/generator.
It then uses these dynamically created *.mount units in combination with 
those it ships[2] and any others created either dynamically by other 
generators or by distros/other-packages or admins[3], instead of using 
/etc/fstab entries directly.

But systemd's own docs still recommend using fstab in preference to its 
own mount units, at least for mounts designed for admin control[4].  
According to the systemd.mount (5) manpage, first paragraph in the FSTAB 
section:

>>>>>

Mount units may either be configured via unit files, or via /etc/fstab 
(see fstab(5) for details). Mounts listed in /etc/fstab will be converted 
into native units dynamically at boot and when the configuration of the 
system manager is reloaded. In general, configuring mount points through
/etc/fstab is the preferred approach. See systemd-fstab-generator(8) for 
details about the conversion.

<<<<<

So while fstab isn't actually _required_ on a systemd-managed system as 
its mount units offer the same functionality, its use is still 
"preferred", and fstab is therefore not considered legacy.


And purely from a practical admin viewpoint, I can see see why...

>> There can be a migration script to generate /etc/conf.d/* configuration
>> once, but there is no need to keep it around.
>> The conf.d can contain everything that fstab contains.
>>
>> mount_mountpoint_\${NAME}=
>> mount_type_\${NAME}=
>> mount_fs_\${NAME}=
>> mount_opts_\${NAME}=
>> mount_dump_\${NAME}=
>> mount_pass_\${NAME}=
>>
>>
> That's a mighty verbose format, especially compared to fstab. I don't
> think we should force people to move away from fstab because we have a
> new and shiny service system.

... And that is _precisely_ _why_.  =:^)

Systemd's mount units may offer the same functionality, but they're far 
more verbose.  Moreover the ratio is one fstab line per mount-unit file, 
with mount-unit files potentially scattered in three different locations 
in the file tree depending on their specific purpose and whether they're 
running as shipped or created/customized by the sysadmin.

> Also if you are trying to get rid of "legacy" stuff, why on earth are
> you keeping dump and pass around? Both of those are certainly not needed
> if you are doing everything via services.

Good point.  The dump and pass fields are actually optional in fstab now 
days as well, with the defaults being 0 for both (don't dump and don't 
fsck), if the field isn't present.  And if we're getting rid of fstab, 
anything using those fields will need code to handle some alternative 
config format anyway (if it doesn't have it already), so might as well 
simply drop the options from the mount config entirely, and let that 
separate config handle it.


Meanwhile, if we're talking specific fstab replacement config format, no 
need to reinvent the wheel, we might as well simply adopt systemd's 
*.mount unit-file format as it covers all the bases, including 
compatibility. =:^) The systemd mount-unit fstab field parallels, 
according to the systemd.mount (5) manpage, Options section (quoting 
abridged excerpts):

>>>>>

Mount files must include a [Mount] section.  The options specific to the 
[Mount] section of mount units are the following:

What= 

[Mandatory: A]n absolute path of a device node, file or other resource to 
mount.

Where=

[Mandatory: A]n absolute path of a directory of the mount point.

Type=

[Optional: A] string for the file system type.

Options=

[Optional: O]ptions to use when mounting. This takes a comma-separated 
list of options.

<<<<<

That would be sufficient for an initial openrc implementation. Additional 
optional options that an initial openrc implementation could ignore 
include:

SloppyOptions=

Corresponds to mount's -s option, allowing unknown mount options.  
Defaults to off.

DirectoryMode=

Mountpoints (and parents) are created if they don't exist.  This sets 
their (octal) mode.  Default is 0755.

TimeoutSec=

Mount command timeout.  If the mount command is still running after this 
time, it is SIGTERMed.  If it's still running after this time elapses 
again, it is SIGKILLed.  A unitless value is interpreted as seconds, or a 
time value such as "5min 20s" can be given.  0 disables the timeout 
entirely.  Systemd sets the default at a higher config level, and openrc 
would presumably do so as well.


Additionally, note that mount itself interprets both the nofail and noauto 
options from the fstab options field or -o commandline option, but an 
individualized mount service would have to parse them from the Options= 
line above, avoiding invoking mount with noauto, and ignoring mount 
failure with nofail.

And finally, systemd acts on a number of otherwise systemd specific 
options out of the mount options field.  Some of these are effectively 
systemd specific, but there are two specific dependency related options 
that it would be useful for openrc to act on as well, x-systemd.requires=, 
and xsystemd.requires-mounts-for=.  Both of these take an absolute path 
and set systemd unit dependencies (Requires= and After= for requires, 
RequiresMountsFor= for that one) one way or the other between this mount 
unit and others.

It's worth noting that were openrc to act on these fstab options field 
options as well, it would in doing so process fstab-configured 
dependencies, and there'd be far less need to have separate 
individualized service unit configuration, as dependencies could be 
specified directly in fstab.

---
[1] systemd-fstab-generator: Installed on a normal systemd-managed system 
as /usr/lib/systemd/system-generators/systemd-fstab-generator.

[2] Systemd shipped mount units: /usr/lib/systemd/system/var-run.mount, 
for instance, which conditionally bind-mounts /var/run to /run, only if 
/var/run already exists and isn't a symlink.

[3] Distro/package shipped mount units, as other distro/package shipped 
units, will be installed as /usr/lib/systemd/system/*.mount, while admin-
created units should be created as /etc/systemd/system/*.mount.

[4] Mounts designed for admin control: as opposed to automated mounts 
like the one mentioned in [2], that aren't intended for admin control, 
with some of them part of the systemd API and thus with limited override 
ability even via the usual /etc/systemd/system/ override location, 
according to the manpage.


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman