/etc/fstab.d yes or not

/etc/fstab.d yes or not

[Karel Zak]

 I'd like to add support for /etc/fstab.d to libmount. The library is
 currently used by mount, umount and mount.nfs. The goal is to use it
 on more places.

 The /etc/fstab.d directory has been requested by people who maintains
 large number of mountpoints etc.

 The directory is not replacement for /etc/fstab, it's additional place
 where you can describe your filesystems.

 The disadvantage is that the stuff in the directory will be invisible
 for some tools (udisks, systemd, ...), so I have very vocal
 disagreement from some people who don't want to see /etc/fstab.d at all.

 BTW, systemd allows to define addition mountpoints in
 systemd.mount(5) unit file(s), so we already have additional place
 for fstab stuff...

 Commands? Objections?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: /etc/fstab.d yes or not

[Masatake YAMATO]

> 
>  I'd like to add support for /etc/fstab.d to libmount. The library is
>  currently used by mount, umount and mount.nfs. The goal is to use it
>  on more places.
> 
>  The /etc/fstab.d directory has been requested by people who maintains
>  large number of mountpoints etc.
> 
>  The directory is not replacement for /etc/fstab, it's additional place
>  where you can describe your filesystems.
> 
>  The disadvantage is that the stuff in the directory will be invisible
>  for some tools (udisks, systemd, ...), so I have very vocal
>  disagreement from some people who don't want to see /etc/fstab.d at all.

I'm working on systemd to support /etc/fstab.d.

Masatake YAMATO

Re: /etc/fstab.d yes or not

[Kay Sievers]

On Fri, Jan 20, 2012 at 15:20, Masatake YAMATO <yamato@redhat.com> wrote:
>>
>> =C2=A0I'd like to add support for /etc/fstab.d to libmount. The library =
is
>> =C2=A0currently used by mount, umount and mount.nfs. The goal is to use =
it
>> =C2=A0on more places.
>>
>> =C2=A0The /etc/fstab.d directory has been requested by people who mainta=
ins
>> =C2=A0large number of mountpoints etc.
>>
>> =C2=A0The directory is not replacement for /etc/fstab, it's additional p=
lace
>> =C2=A0where you can describe your filesystems.
>>
>> =C2=A0The disadvantage is that the stuff in the directory will be invisi=
ble
>> =C2=A0for some tools (udisks, systemd, ...), so I have very vocal
>> =C2=A0disagreement from some people who don't want to see /etc/fstab.d a=
t all.
>
> I'm working on systemd to support /etc/fstab.d.

And we don't want to support that in systemd.

It's an old glibc API, and /etc/fstab is ABI, not a service config
file, which now can read more than one file. It's a very different
problem. It an ABI change, not a config extension.

Tools rightfully expect that they find all system mounts in that file,
and not in some new split-up directory. In some cases, fstab is used
to 'check if the device is not a system volume', and that will just
break now,

The gain of features from fstab.d/ vs. the amount of breakage it
causes is not worth the trouble.

And yes, there are systemd units, but we don't recommend anybody
working with a general purpose system to mount system volumes with
them. They are primarily used for virtual filessytems, which do not
belong in fstab. In special purpose setups, like embedded, which do
not care about POSIX-like APIs, the systemd units can replace fstab,
but it's an entirely different story than breaking fstab expectations.

Kay

Re: /etc/fstab.d yes or not

[Roger Leigh]

On Fri, Jan 20, 2012 at 03:56:43PM +0100, Kay Sievers wrote:
> On Fri, Jan 20, 2012 at 15:20, Masatake YAMATO <yamato@redhat.com> wrote:
> >>
> >>  I'd like to add support for /etc/fstab.d to libmount. The library is
> >>  currently used by mount, umount and mount.nfs. The goal is to use it
> >>  on more places.
> >
> > I'm working on systemd to support /etc/fstab.d.
> 
> It's an old glibc API, and /etc/fstab is ABI, not a service config
> file, which now can read more than one file. It's a very different
> problem. It an ABI change, not a config extension.

I think that's putting the problem a little too strongly.  The
glibc API is generic: it can (and is) used to parse any file using
the fstab(5) file format; it's not restricted to only /etc/mtab
and /etc/fstab.  setmntent(3) accepts any filename.

You are entirely correct that it may break the assumptions made by
some software, but it's certainly not "ABI" or even "API" breakage.

> Tools rightfully expect that they find all system mounts in that file,
> and not in some new split-up directory. In some cases, fstab is used
> to 'check if the device is not a system volume', and that will just
> break now,

The number of tools which do this is tiny, and could (if we wished)
be patched trivially to also look at the files in fstab.d.

Alternatively, glibc itself could be updated so that if e.g.
setmntent(3) is called with "/etc/fstab" as its filename argument,
it will additionally process and include the contents of
/etc/fstab.d as well.  This would have the advantage of transparency
for all users of the glibc interface.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Re: /etc/fstab.d yes or not

[Kay Sievers]

On Fri, Jan 20, 2012 at 16:57, Roger Leigh <rleigh@codelibre.net> wrote:
> On Fri, Jan 20, 2012 at 03:56:43PM +0100, Kay Sievers wrote:
>> On Fri, Jan 20, 2012 at 15:20, Masatake YAMATO <yamato@redhat.com> wrote=
:
>> >>
>> >> =C2=A0I'd like to add support for /etc/fstab.d to libmount. The libra=
ry is
>> >> =C2=A0currently used by mount, umount and mount.nfs. The goal is to u=
se it
>> >> =C2=A0on more places.
>> >
>> > I'm working on systemd to support /etc/fstab.d.
>>
>> It's an old glibc API, and /etc/fstab is ABI, not a service config
>> file, which now can read more than one file. It's a very different
>> problem. It an ABI change, not a config extension.
>
> I think that's putting the problem a little too strongly. =C2=A0The
> glibc API is generic: it can (and is) used to parse any file using
> the fstab(5) file format; it's not restricted to only /etc/mtab
> and /etc/fstab. =C2=A0setmntent(3) accepts any filename.

That's right, but it's just not the way it's used. None of the old
tools is prepared to just wrap that in a readdir() loop.

> You are entirely correct that it may break the assumptions made by
> some software, but it's certainly not "ABI" or even "API" breakage.

It is surely the de-facto Linux/UNIX ABI for system mounts.

>> Tools rightfully expect that they find all system mounts in that file,
>> and not in some new split-up directory. In some cases, fstab is used
>> to 'check if the device is not a system volume', and that will just
>> break now,
>
> The number of tools which do this is tiny, and could (if we wished)
> be patched trivially to also look at the files in fstab.d.
>
> Alternatively, glibc itself could be updated so that if e.g.
> setmntent(3) is called with "/etc/fstab" as its filename argument,
> it will additionally process and include the contents of
> /etc/fstab.d as well. =C2=A0This would have the advantage of transparency
> for all users of the glibc interface.

That's true, but good luck with glibc changes. :)

Kay

Re: /etc/fstab.d yes or not

[Boaz Harrosh]

On 01/20/2012 04:56 PM, Kay Sievers wrote:
> 
> It's an old glibc API, and /etc/fstab is ABI, not a service config
> file, which now can read more than one file. It's a very different
> problem. It an ABI change, not a config extension.
> 

Can't we have our cake and eat it too?

I mean why not have both?

The subsystem that you currently plan to parse the /etc/fstab.d/ will
intelligently  add the /etc/fstab.d/ entries to /etc/fstab before
actually processing and mounting /etc/fstab.

So the rpm guys have their /etc/fstab.d/ convenience and the rest
of the  ABI is kept intact. (If you can't bit them join them)

Since /etc/fstab is hand edited as well. There are lots of smart
things that can be done like a remark (#) marker at the end of the
file that all /etc/fstab.d/ entries get to be added after. (And
a comment for the user) and some smart duplicate removal of, and
so on ... Even a marker per line added.

Just my $0,017
Boaz

Re: /etc/fstab.d yes or not

[bastien ROUCARIES]

Le Tuesday 24 January 2012 01:19:24, Boaz Harrosh a écrit :
> On 01/20/2012 04:56 PM, Kay Sievers wrote:
> > It's an old glibc API, and /etc/fstab is ABI, not a service config
> > file, which now can read more than one file. It's a very different
> > problem. It an ABI change, not a config extension.
> 
> Can't we have our cake and eat it too?
> 
> I mean why not have both?
> 
> The subsystem that you currently plan to parse the /etc/fstab.d/ will
> intelligently  add the /etc/fstab.d/ entries to /etc/fstab before
> actually processing and mounting /etc/fstab.
> 
> So the rpm guys have their /etc/fstab.d/ convenience and the rest
> of the  ABI is kept intact. (If you can't bit them join them)
> 
> Since /etc/fstab is hand edited as well. There are lots of smart
> things that can be done like a remark (#) marker at the end of the
> file that all /etc/fstab.d/ entries get to be added after. (And
> a comment for the user) and some smart duplicate removal of, and
> so on ... Even a marker per line added.

I agree. And moreover extensible if they want to use xml for  /etc/fstab.d/. 
> 
> Just my $0,017
> Boaz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: /etc/fstab.d yes or not

[Attila Kinali]

On Fri, 20 Jan 2012 15:04:44 +0100
Karel Zak <kzak@redhat.com> wrote:

>  I'd like to add support for /etc/fstab.d to libmount. The library is
>  currently used by mount, umount and mount.nfs. The goal is to use it
>  on more places.
> 
>  The /etc/fstab.d directory has been requested by people who maintains
>  large number of mountpoints etc.
> 
>  The directory is not replacement for /etc/fstab, it's additional place
>  where you can describe your filesystems.

It might not be my place to say anthing about this, as I am just
a mere mortal .... 

But I'd like to express my concerns on this. In the years i've been
using Linux, the system has become a very complex beast. While in the 
beginning I could just dig trough a couple of scripts to figure out
how a certain system worked, or more likely why it didn't work...
nowadays i have to have knowledge of a dozen of complex interacting
daemons to figure out why gedit refuses to edit a simple text file.

Complexity is added everywhere, to make a few corner cases a little
bit more simple. Making it more difficult for the 99% who do
not care about these corner cases. This in turn makes Linux this
opaque system that only a handfull of selected can understand, who
invest their whole life to the understanding of its many subsystems.
If this continues like this, in a decade or two, Linux will become
like windows. A system nobody clearly understands, which somehow works,
but sometimes not.. and nobody knows why.

Hence, i would like to ask you to consider not adding /etc/fstab.d
unless there is a very good reason to do it. And "to make it simpler
for people who have a lot of mountpoints" is IMHO not a good reason.
How many mountpoints must one use that a single file becomes a problem?


			Attila Kinali

-- 
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
		-- Tirin, The Dispossessed, U. Le Guin

Re: /etc/fstab.d yes or not

[Karel Zak]

On Fri, Jan 20, 2012 at 03:43:09PM +0100, Attila Kinali wrote:
> Hence, i would like to ask you to consider not adding /etc/fstab.d
> unless there is a very good reason to do it. And "to make it simpler
> for people who have a lot of mountpoints" is IMHO not a good reason.
> How many mountpoints must one use that a single file becomes a problem?

 Let's imagine that you have a network and you use the same configuration
 on all machines, then "*.d/" directories are very useful for you -- for
 example you can create a company.rpm with important configuration and
 distribute it to all machines.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

RE: /etc/fstab.d yes or not

[Voelker, Bernhard]

Karel Zak wrote:

> On Fri, Jan 20, 2012 at 03:43:09PM +0100, Attila Kinali wrote:
> > Hence, i would like to ask you to consider not adding /etc/fstab.d
> > unless there is a very good reason to do it. And "to make it simpler
> > for people who have a lot of mountpoints" is IMHO not a good reason.
> > How many mountpoints must one use that a single file becomes a problem?
> 
>  Let's imagine that you have a network and you use the same configuration
>  on all machines, then "*.d/" directories are very useful for you -- for
>  example you can create a company.rpm with important configuration and
>  distribute it to all machines.

Isn't this what the automounter does for decades?

Berny

Re: /etc/fstab.d yes or not

[Kay Sievers]

On Fri, Jan 20, 2012 at 15:59, Karel Zak <kzak@redhat.com> wrote:
> On Fri, Jan 20, 2012 at 03:43:09PM +0100, Attila Kinali wrote:
>> Hence, i would like to ask you to consider not adding /etc/fstab.d
>> unless there is a very good reason to do it. And "to make it simpler
>> for people who have a lot of mountpoints" is IMHO not a good reason.
>> How many mountpoints must one use that a single file becomes a problem?
>
>  Let's imagine that you have a network and you use the same configuration
>  on all machines, then "*.d/" directories are very useful for you -- for
>  example you can create a company.rpm with important configuration and
>  distribute it to all machines.

Yeah, and all tools which read /etc/fstab with the glibc interface, to
find out the properties for the mount point, are just broken now. And
for what gain. Put a script in you RPM that merges your snippets into
the one fstab, and you get the same behaviour without any breakage.

Always remember, /etc/fstab is ABI, not a private config file, you
need a _very_ good reason to break it.

And you usually have not much problems convincing me that breakage is
justified. I just totally fail to see the benefit vs. gain in this
case.

Kay

Re: /etc/fstab.d yes or not

[Roger Leigh]

On Fri, Jan 20, 2012 at 03:04:44PM +0100, Karel Zak wrote:
>  I'd like to add support for /etc/fstab.d to libmount. The library is
>  currently used by mount, umount and mount.nfs. The goal is to use it
>  on more places.
> 
>  The /etc/fstab.d directory has been requested by people who maintains
>  large number of mountpoints etc.
> 
>  The directory is not replacement for /etc/fstab, it's additional place
>  where you can describe your filesystems.

As a general comment, I would like to use fstab.d for replacing
the initscripts which mount kernel filesystems in Debian initscripts
(sysvinit).  We currently hardcode the logic to mount each filesystem
and additionally hardcode the defaults, and permit the defaults to
be overridden by the user via /etc/default/* or via entries in
/etc/fstab.  This could be done much more straightforwardly using
entries such as /etc/fstab.d/kernfs and /etc/fstab.d/tmpfs etc.

>From the distributor's POV, this can then take advantage of the
package manager's conffile handling, meaning it's much simpler
for the user to customise.

>From the initscripts POV, were systemd to also use the same
approach, we could then share the configuration between the different
init systems.

Note that I've not actually taken any of these steps yet; I'm
about to test it with the upcoming util-linux release and the
current prerelease, but it is something under consideration.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Re: /etc/fstab.d yes or not

[Kay Sievers]

On Fri, Jan 20, 2012 at 16:49, Roger Leigh <rleigh@codelibre.net> wrote:
> On Fri, Jan 20, 2012 at 03:04:44PM +0100, Karel Zak wrote:
>>  I'd like to add support for /etc/fstab.d to libmount. The library is
>>  currently used by mount, umount and mount.nfs. The goal is to use it
>>  on more places.
>>
>>  The /etc/fstab.d directory has been requested by people who maintains
>>  large number of mountpoints etc.
>>
>>  The directory is not replacement for /etc/fstab, it's additional place
>>  where you can describe your filesystems.
>
> As a general comment, I would like to use fstab.d for replacing
> the initscripts which mount kernel filesystems in Debian initscripts
> (sysvinit).  We currently hardcode the logic to mount each filesystem
> and additionally hardcode the defaults, and permit the defaults to
> be overridden by the user via /etc/default/* or via entries in
> /etc/fstab.  This could be done much more straightforwardly using
> entries such as /etc/fstab.d/kernfs and /etc/fstab.d/tmpfs etc.

It is just very wrong to expose kernel filesystems to system mounts.
Please invent your own config if you want that for packaging. The
kernel filesystems do not belong in fstab, and for the same reason not
in fstab.d/.

> From the distributor's POV, this can then take advantage of the
> package manager's conffile handling, meaning it's much simpler
> for the user to customise.
>
> From the initscripts POV, were systemd to also use the same
> approach, we could then share the configuration between the different
> init systems.

The init systems need to handle the mounts, but unlikely by sharing
additional config files. For systemd it is a solved problem, we don't
need fstab.d/ for that, and sysv should not start to try to solve it
at that level, because it will conflict with systemd.

Kay

Re: /etc/fstab.d yes or not

[Roger Leigh]

On Fri, Jan 20, 2012 at 05:13:12PM +0100, Kay Sievers wrote:
> On Fri, Jan 20, 2012 at 16:49, Roger Leigh <rleigh@codelibre.net> wrote:
> > On Fri, Jan 20, 2012 at 03:04:44PM +0100, Karel Zak wrote:
> >>  I'd like to add support for /etc/fstab.d to libmount. The library is
> >>  currently used by mount, umount and mount.nfs. The goal is to use it
> >>  on more places.
> >>
> >>  The /etc/fstab.d directory has been requested by people who maintains
> >>  large number of mountpoints etc.
> >>
> >>  The directory is not replacement for /etc/fstab, it's additional place
> >>  where you can describe your filesystems.
> >
> > As a general comment, I would like to use fstab.d for replacing
> > the initscripts which mount kernel filesystems in Debian initscripts
> > (sysvinit).  We currently hardcode the logic to mount each filesystem
> > and additionally hardcode the defaults, and permit the defaults to
> > be overridden by the user via /etc/default/* or via entries in
> > /etc/fstab.  This could be done much more straightforwardly using
> > entries such as /etc/fstab.d/kernfs and /etc/fstab.d/tmpfs etc.
> 
> It is just very wrong to expose kernel filesystems to system mounts.
> Please invent your own config if you want that for packaging. The
> kernel filesystems do not belong in fstab, and for the same reason not
> in fstab.d/.

To be fair, these can be split into two categories: kernel filesystems
such as procfs, sysfs etc., and special-purpose tmpfs mounts.  The
former could be kept in the init scripts, but the latter are commonly
required to be customised (or disabled) by admins, and the fstab format
is the natural way to express this.  This would include tmpfs mounts
for e.g. /run, /run/lock, /run/shm, potentially /tmp] and others, each
of which has separate limits.

Inventing custom file formats for these (as is the current situation)
is both opaque to the admin and less amenable to preservation/upgrading
of the admins customisations and the defaults.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Re: /etc/fstab.d yes or not

[Kay Sievers]

On Fri, Jan 20, 2012 at 17:22, Roger Leigh <rleigh@codelibre.net> wrote:
> On Fri, Jan 20, 2012 at 05:13:12PM +0100, Kay Sievers wrote:
>> On Fri, Jan 20, 2012 at 16:49, Roger Leigh <rleigh@codelibre.net> wrote:
>> > On Fri, Jan 20, 2012 at 03:04:44PM +0100, Karel Zak wrote:
>> >>  I'd like to add support for /etc/fstab.d to libmount. The library is
>> >>  currently used by mount, umount and mount.nfs. The goal is to use it
>> >>  on more places.
>> >>
>> >>  The /etc/fstab.d directory has been requested by people who maintains
>> >>  large number of mountpoints etc.
>> >>
>> >>  The directory is not replacement for /etc/fstab, it's additional place
>> >>  where you can describe your filesystems.
>> >
>> > As a general comment, I would like to use fstab.d for replacing
>> > the initscripts which mount kernel filesystems in Debian initscripts
>> > (sysvinit).  We currently hardcode the logic to mount each filesystem
>> > and additionally hardcode the defaults, and permit the defaults to
>> > be overridden by the user via /etc/default/* or via entries in
>> > /etc/fstab.  This could be done much more straightforwardly using
>> > entries such as /etc/fstab.d/kernfs and /etc/fstab.d/tmpfs etc.
>>
>> It is just very wrong to expose kernel filesystems to system mounts.
>> Please invent your own config if you want that for packaging. The
>> kernel filesystems do not belong in fstab, and for the same reason not
>> in fstab.d/.
>
> To be fair, these can be split into two categories: kernel filesystems
> such as procfs, sysfs etc., and special-purpose tmpfs mounts.  The
> former could be kept in the init scripts, but the latter are commonly
> required to be customised (or disabled) by admins, and the fstab format
> is the natural way to express this.  This would include tmpfs mounts
> for e.g. /run, /run/lock, /run/shm, potentially /tmp] and others, each
> of which has separate limits.
>
> Inventing custom file formats for these (as is the current situation)
> is both opaque to the admin and less amenable to preservation/upgrading
> of the admins customisations and the defaults.

I'm not talking about custom file formats, better just add a mount -c,
and do mount -c /etc/kernelfs.d/*.conf, or whatever will fit systemv
needs.

This is nothing really to share between systemd and systemv here. This
problem just does not exist for systemd.

And for systemv it should not be solved in mount(8), but in a systemv
specific part.

A change in common tools at that level breaks much more than it solves.

Kay

Re: /etc/fstab.d yes or not

[Karel Zak]

On Fri, Jan 20, 2012 at 06:59:47PM +0100, Kay Sievers wrote:
> > Inventing custom file formats for these (as is the current situation)
> > is both opaque to the admin and less amenable to preservation/upgrading
> > of the admins customisations and the defaults.
> 
> I'm not talking about custom file formats, better just add a mount -c,
> and do mount -c /etc/kernelfs.d/*.conf, or whatever will fit systemv
> needs.

 This is planned (I talked about it on dracut list few months ago). It
 means:

    mount --fstab=<path> /mountpoint

 to override the default /etc/fstab path. The <path> could be also a
 directory. So you can maintain our mountpoints in multiple files and
 mount(8) will be able to search in the files if --fstab=<path> is
 explicitly specified. I think this should be enough for initramfs
 scripts.

 The problem is that the configuration won't be visible if
 --fstab is not specified -- this is possible to resolve probably
 by regular /etc/fstab.d only ;-)

> This is nothing really to share between systemd and systemv here. This
> problem just does not exist for systemd.

 Well, Masatake has RHEL customers who want to deploy systems with
 rpm/yum, %post scripts are poor solution because it's not too
 reliable and verification with rpm -V doesn't work. Do we have any
 answer for this use case?

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: /etc/fstab.d yes or not

[Masatake YAMATO]

On Mon, 23 Jan 2012 13:21:15 +0100, Karel Zak <kzak@redhat.com> wrote
> On Fri, Jan 20, 2012 at 06:59:47PM +0100, Kay Sievers wrote:
>> > Inventing custom file formats for these (as is the current situation)
>> > is both opaque to the admin and less amenable to preservation/upgrading
>> > of the admins customisations and the defaults.
>> 
>> I'm not talking about custom file formats, better just add a mount -c,
>> and do mount -c /etc/kernelfs.d/*.conf, or whatever will fit systemv
>> needs.
> 
>  This is planned (I talked about it on dracut list few months ago). It
>  means:
> 
>     mount --fstab=<path> /mountpoint
> 
>  to override the default /etc/fstab path. The <path> could be also a
>  directory. So you can maintain our mountpoints in multiple files and
>  mount(8) will be able to search in the files if --fstab=<path> is
>  explicitly specified. I think this should be enough for initramfs
>  scripts.
> 
>  The problem is that the configuration won't be visible if
>  --fstab is not specified -- this is possible to resolve probably
>  by regular /etc/fstab.d only ;-)
> 
>> This is nothing really to share between systemd and systemv here. This
>> problem just does not exist for systemd.
> 
>  Well, Masatake has RHEL customers who want to deploy systems with
>  rpm/yum, %post scripts are poor solution because it's not too
>  reliable and verification with rpm -V doesn't work. Do we have any
>  answer for this use case?
> 
>     Karel

The question is not for me but I had thought about it in this weekend.
(Now I understand well the importance of the compatibility.)

How do you think following approach:
1. Initially (before booting), the system has /etc/fstab.d/*.fstab files only.
2. When the system booting, systemd merges the *.fstab file into /etc/fstab.
3. Then systemd loads /etc/fstab.
4. Other programs can loads /etc/fstab either directly or via glibc interface.

Though a rpm package must run something `merge-fstab' command to update
fstab after putting a file under /etc/fstab.d, rpm -V rpm -ql and rpm -qf
works fine. Here I assume `merge-fstab' is provided by util-linux.

This approach may need the modification of disro installer.
/etc/fstab is always overwritten by systemd when booting.
So the installer must generate not /etc/fstab but
/etc/fstab.d/00.fstab or something. A tool which adds an entry
to /etc/fstab doesn't work, too.

Masatake YAMATO


> -- 
>  Karel Zak  <kzak@redhat.com>
>  http://karelzak.blogspot.com
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: /etc/fstab.d yes or not

[Kay Sievers]

On Mon, Jan 23, 2012 at 13:21, Karel Zak <kzak@redhat.com> wrote:
> On Fri, Jan 20, 2012 at 06:59:47PM +0100, Kay Sievers wrote:
>> > Inventing custom file formats for these (as is the current situation)
>> > is both opaque to the admin and less amenable to preservation/upgrading
>> > of the admins customisations and the defaults.
>>
>> I'm not talking about custom file formats, better just add a mount -c,
>> and do mount -c /etc/kernelfs.d/*.conf, or whatever will fit systemv
>> needs.
>
>  This is planned (I talked about it on dracut list few months ago). It
>  means:
>
>    mount --fstab=<path> /mountpoint
>
>  to override the default /etc/fstab path. The <path> could be also a
>  directory. So you can maintain our mountpoints in multiple files and
>  mount(8) will be able to search in the files if --fstab=<path> is
>  explicitly specified. I think this should be enough for initramfs
>  scripts.
>
>  The problem is that the configuration won't be visible if
>  --fstab is not specified -- this is possible to resolve probably
>  by regular /etc/fstab.d only ;-)

It creates many times more problems that anybody has today.

>> This is nothing really to share between systemd and systemv here. This
>> problem just does not exist for systemd.
>
>  Well, Masatake has RHEL customers who want to deploy systems with
>  rpm/yum, %post scripts are poor solution because it's not too
>  reliable and verification with rpm -V doesn't work. Do we have any
>  answer for this use case?

We don't need one. System mounts just do not belong into packages,
they are mandatory and hard-coded, or set by the admin and
host-specific configured, and never to be dropped by RPM. RPM is not
to be used for host-only system config.

Kay

Re: /etc/fstab.d yes or not

[Masatake YAMATO]

On Mon, 23 Jan 2012 14:03:41 +0100, Kay Sievers <kay.sievers@vrfy.org> =
wrote
> On Mon, Jan 23, 2012 at 13:21, Karel Zak <kzak@redhat.com> wrote:
>> On Fri, Jan 20, 2012 at 06:59:47PM +0100, Kay Sievers wrote:
>>> > Inventing custom file formats for these (as is the current situat=
ion)
>>> > is both opaque to the admin and less amenable to preservation/upg=
rading
>>> > of the admins customisations and the defaults.
>>>
>>> I'm not talking about custom file formats, better just add a mount =
-c,
>>> and do mount -c /etc/kernelfs.d/*.conf, or whatever will fit system=
v
>>> needs.
>>
>> =A0This is planned (I talked about it on dracut list few months ago)=
. It
>> =A0means:
>>
>> =A0 =A0mount --fstab=3D<path> /mountpoint
>>
>> =A0to override the default /etc/fstab path. The <path> could be also=
 a
>> =A0directory. So you can maintain our mountpoints in multiple files =
and
>> =A0mount(8) will be able to search in the files if --fstab=3D<path> =
is
>> =A0explicitly specified. I think this should be enough for initramfs=

>> =A0scripts.
>>
>> =A0The problem is that the configuration won't be visible if
>> =A0--fstab is not specified -- this is possible to resolve probably
>> =A0by regular /etc/fstab.d only ;-)
> =

> It creates many times more problems that anybody has today.
> =

>>> This is nothing really to share between systemd and systemv here. T=
his
>>> problem just does not exist for systemd.
>>
>> =A0Well, Masatake has RHEL customers who want to deploy systems with=

>> =A0rpm/yum, %post scripts are poor solution because it's not too
>> =A0reliable and verification with rpm -V doesn't work. Do we have an=
y
>> =A0answer for this use case?
> =

> We don't need one. System mounts just do not belong into packages,
> they are mandatory and hard-coded, or set by the admin and
> host-specific configured, and never to be dropped by RPM. RPM is not
> to be used for host-only system config.

What I want is packaging the system mounts.
Consider setting up multiple hosts which mount the same nfs filesystem
to the same mount point. It the mount point is in a rpm package, it
can be used both in kickstart file and from yum command line. In
addition yum update can be used when the name or ip of nfs server is
changed; Just create the new release of the rpm package which holds
new mount point deification. In stead of nfs, you can consider smb or =

iso images as examples. =


Masatake YAMATO
 =

> Kay
> --
> To unsubscribe from this list: send the line "unsubscribe util-linux"=
 in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: /etc/fstab.d yes or not

[Kay Sievers]

On Mon, Jan 23, 2012 at 14:26, Masatake YAMATO <yamato@redhat.com> wrote:

> What I want is packaging the system mounts.
> Consider setting up multiple hosts which mount the same nfs filesystem
> to the same mount point. It the mount point is in a rpm package, it
> can be used both in kickstart file and from yum command line. In
> addition yum update can be used when the name or ip of nfs server is
> changed; Just create the new release of the rpm package which holds
> new mount point deification. In stead of nfs, you can consider smb or
> iso images as examples.

That sounds very wrong to do. This is admin territory and not package
management. There are tools sync and deploy /etc setting per-machine
across big networks, and RPM is surely not the right thing to use
here.

RPM is for the operating system, not for host configuration. Most
stuff in /etc is marked as config for that exact reason. First, static
system-config does not belong in /etc, second non-admin editable files
just do not belong in /etc. It's all wrong, just as the misguided
entire fstab.d/ feature to start with.

Kay

Re: /etc/fstab.d yes or not

[Masatake YAMATO]

On Mon, 23 Jan 2012 14:37:22 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote
>> What I want is packaging the system mounts.
>> Consider setting up multiple hosts which mount the same nfs filesystem
>> to the same mount point. It the mount point is in a rpm package, it
>> can be used both in kickstart file and from yum command line. In
>> addition yum update can be used when the name or ip of nfs server is
>> changed; Just create the new release of the rpm package which holds
>> new mount point deification. In stead of nfs, you can consider smb or
>> iso images as examples.
> 
> That sounds very wrong to do. This is admin territory and not package
> management. 

I'm thiking about the admin manages packages which are installed to 
the host.

> There are tools sync and deploy /etc setting per-machine
> across big networks, and RPM is surely not the right thing to use
> here.

(RPM works fine daily "yum update" done by users on the world.)
Of course I'm thinking about the admin runs her/his own yum repository.

> RPM is for the operating system, not for host configuration. Most
> stuff in /etc is marked as config for that exact reason. First, static
> system-config does not belong in /etc, second non-admin editable files
> just do not belong in /etc. It's all wrong, just as the misguided
> entire fstab.d/ feature to start with.

It is not so simple.

$ rpm -qf /etc/yum.repos.d/fedora.repo 
fedora-release-14-1.noarch

Admin can edit fedora.repo, but generally it is assumed as static
file. 

$ rpm -q --queryformat "%{NAME}: %{FILEFLAGS:fflags}\n" -f /etc/udev/rules.d/*.rules
hplip-common: 
hplip-common: 
libfprint: 
qemu-system-x86: 
alsa-utils: 
hal: c
libdrm: c
vbetool: 
bluez: 
fuse: 
gpsd: cn

Some are marked as config as you said. The other are not. I think the packages
may think their rules files as static data.

Masatake YAMATO

Re: /etc/fstab.d yes or not

[Kay Sievers]

On Mon, Jan 23, 2012 at 15:14, Masatake YAMATO <yamato@redhat.com> wrote:
> On Mon, 23 Jan 2012 14:37:22 +0100, Kay Sievers <kay.sievers@vrfy.org> wrote
>>> What I want is packaging the system mounts.
>>> Consider setting up multiple hosts which mount the same nfs filesystem
>>> to the same mount point. It the mount point is in a rpm package, it
>>> can be used both in kickstart file and from yum command line. In
>>> addition yum update can be used when the name or ip of nfs server is
>>> changed; Just create the new release of the rpm package which holds
>>> new mount point deification. In stead of nfs, you can consider smb or
>>> iso images as examples.
>>
>> That sounds very wrong to do. This is admin territory and not package
>> management.
>
> I'm thiking about the admin manages packages which are installed to
> the host.
>
>> There are tools sync and deploy /etc setting per-machine
>> across big networks, and RPM is surely not the right thing to use
>> here.
>
> (RPM works fine daily "yum update" done by users on the world.)
> Of course I'm thinking about the admin runs her/his own yum repository.
>
>> RPM is for the operating system, not for host configuration. Most
>> stuff in /etc is marked as config for that exact reason. First, static
>> system-config does not belong in /etc, second non-admin editable files
>> just do not belong in /etc. It's all wrong, just as the misguided
>> entire fstab.d/ feature to start with.
>
> It is not so simple.
>
> $ rpm -qf /etc/yum.repos.d/fedora.repo
> fedora-release-14-1.noarch
>
> Admin can edit fedora.repo, but generally it is assumed as static
> file.
>
> $ rpm -q --queryformat "%{NAME}: %{FILEFLAGS:fflags}\n" -f /etc/udev/rules.d/*.rules
> hplip-common:
> hplip-common:
> libfprint:
> qemu-system-x86:
> alsa-utils:
> hal: c
> libdrm: c
> vbetool:
> bluez:
> fuse:
> gpsd: cn
>
> Some are marked as config as you said. The other are not. I think the packages
> may think their rules files as static data.

Yes, and the udev rules in /etc are admin-only, it should be empty,
static RPM-provided rules belong into /lib/udev/rules.d/. Many of them
moved already in later OS releases. Everything else in the list is a
bug, or legacy nobody cared so far.

Some stuff in /etc is hard to fix/change because it is like that since
forever, but that is no reason to add new stuff to that broken model.

And inventing new static files in /etc is as wrong as packaging static
system mounts with RPM and as wrong as the entire fstab.d/ thing.

Please just don't do anything like that, it's not where we want to be
or want to go in the future.

Kay

Re: /etc/fstab.d yes or not

[Theodore Tso]

I am extremely dubious about systemd, and would much rather it not be on any system that *I* run (and using UUID's to identify kernel notification is just whacko) , but I have to agree with Kay in that /etc/fstab.d is Just Wrong.   The /etc/fstab file is parsed by many programs, shell scripts, and not just the ones in util-linux.   We should consider it an ABI, and not mess with it.

-- Ted

Re: /etc/fstab.d yes or not

[Alan Cox]

On Mon, 23 Jan 2012 08:55:21 -0500
Theodore Tso <tytso@MIT.EDU> wrote:

> I am extremely dubious about systemd, and would much rather it not be on any system that *I* run (and using UUID's to identify kernel notification is just whacko) , but I have to agree with Kay in that /etc/fstab.d is Just Wrong.   The /etc/fstab file is parsed by many programs, shell scripts, and not just the ones in util-linux.   We should consider it an ABI, and not mess with it.

Pedantically speaking /etc/fstab is not API, getmntent is API.

In practical terms though it would be very 'interesting' to implement
getmentent with an fstab.d, if not down right impossible because the
argument is a FILE *.

So with a good coding hat on - please don't consider fstab API, it's got
a programming interface 8). Otherwise I agree fstab.d is wrong.

Alan

Re: /etc/fstab.d yes or not

[Ted Ts'o]

On Mon, Jan 23, 2012 at 10:07:20PM +0000, Alan Cox wrote:
> 
> So with a good coding hat on - please don't consider fstab API, it's got
> a programming interface 8). Otherwise I agree fstab.d is wrong.
> 

It has a programming interface for reading, but other programs can do
modify (and read) the file directly.  If some joker decided to change
the formatting of /etc/fstab from tab-delimeted to some crazy XML
encoding, I am certain things would break.

					- Ted

Re: /etc/fstab.d yes or not

[Denys Vlasenko]

On Fri, Jan 20, 2012 at 3:04 PM, Karel Zak <kzak@redhat.com> wrote:
>  BTW, systemd allows to define addition mountpoints in
>  systemd.mount(5) unit file(s), so we already have additional place
>  for fstab stuff...

systemd needs a large blunt object be stuck into its eye.

systemd was supposed to be an init replacement.
Its continuing attempts to infiltrate entire system
are very worrying.

$ ls -l /lib/systemd/systemd*
-rwxr-xr-x. 1 root root  22068 Nov  2 00:41 /lib/systemd/systemd-ac-power
-rwxr-xr-x. 1 root root  38656 Nov  2 00:41 /lib/systemd/systemd-binfmt
-rwxr-xr-x. 1 root root  30356 Nov  2 00:41 /lib/systemd/systemd-cgroups-agent
-rwxr-xr-x. 1 root root  51072 Nov  2 00:41 /lib/systemd/systemd-cryptsetup
-rwxr-xr-x. 1 root root  26328 Nov  2 00:41 /lib/systemd/systemd-detect-virt
-rwxr-xr-x. 1 root root  42856 Nov  2 00:41 /lib/systemd/systemd-fsck
-rwxr-xr-x. 1 root root  63576 Nov  2 00:41 /lib/systemd/systemd-hostnamed
-rwxr-xr-x. 1 root root  38644 Nov  2 00:41 /lib/systemd/systemd-initctl
-rwxr-xr-x. 1 root root  38668 Nov  2 00:41 /lib/systemd/systemd-kmsg-syslogd
-rwxr-xr-x. 1 root root  75776 Nov  2 00:41 /lib/systemd/systemd-localed
-rwxr-xr-x. 1 root root 186724 Nov  2 00:41 /lib/systemd/systemd-logind
-rwxr-xr-x. 1 root root  34552 Nov  2 00:41 /lib/systemd/systemd-modules-load
-rwxr-xr-x. 1 root root  30436 Nov  2 00:41 /lib/systemd/systemd-quotacheck
-rwxr-xr-x. 1 root root  30392 Nov  2 00:41 /lib/systemd/systemd-random-seed
-rwxr-xr-x. 1 root root  51148 Nov  2 00:41
/lib/systemd/systemd-readahead-collect
-rwxr-xr-x. 1 root root  38756 Nov  2 00:41
/lib/systemd/systemd-readahead-replay
-rwxr-xr-x. 1 root root  34520 Nov  2 00:41 /lib/systemd/systemd-remount-api-vfs
-rwxr-xr-x. 1 root root  26216 Nov  2 00:41 /lib/systemd/systemd-reply-password
-rwxr-xr-x. 1 root root  59328 Nov  2 00:41 /lib/systemd/systemd-shutdown
-rwxr-xr-x. 1 root root  38668 Nov  2 00:41 /lib/systemd/systemd-shutdownd
-rwxr-xr-x. 1 root root  34508 Nov  2 00:41
/lib/systemd/systemd-stdout-syslog-bridge
-rwxr-xr-x. 1 root root  38664 Nov  2 00:41 /lib/systemd/systemd-sysctl
-rwxr-xr-x. 1 root root  63496 Nov  2 00:41 /lib/systemd/systemd-timedated
-rwxr-xr-x. 1 root root  22024 Nov  2 00:41 /lib/systemd/systemd-timestamp
-rwxr-xr-x. 1 root root  30364 Nov  2 00:41 /lib/systemd/systemd-uaccess
-rwxr-xr-x. 1 root root  38652 Nov  2 00:41 /lib/systemd/systemd-update-utmp
-rwxr-xr-x. 1 root root  42792 Nov  2 00:41 /lib/systemd/systemd-user-sessions
-rwxr-xr-x. 1 root root  34596 Nov  2 00:41 /lib/systemd/systemd-vconsole-setup

What a *heck* is this?

-- 
vda

Re: /etc/fstab.d yes or not

[Kay Sievers]

On Fri, Jan 20, 2012 at 19:20, Denys Vlasenko <vda.linux@googlemail.com> wrote:
> On Fri, Jan 20, 2012 at 3:04 PM, Karel Zak <kzak@redhat.com> wrote:
>>  BTW, systemd allows to define addition mountpoints in
>>  systemd.mount(5) unit file(s), so we already have additional place
>>  for fstab stuff...
>
> systemd needs a large blunt object be stuck into its eye.
>
> systemd was supposed to be an init replacement.

It's much more, and I don't think you have been involved in defining
the focus of it, and the systemd people do not necessary come to the
same conclusion as you.

> Its continuing attempts to infiltrate entire system
> are very worrying.

You are free to express your worries somewhere else. Don't hijack
treads with completely unrelated stuff. That's not welcome in this
thread and not in general.

> What a *heck* is this?

A platform.

Thanks,
Kay

Re: /etc/fstab.d yes or not

[Al Viro]

On Fri, Jan 20, 2012 at 07:20:33PM +0100, Denys Vlasenko wrote:
> On Fri, Jan 20, 2012 at 3:04 PM, Karel Zak <kzak@redhat.com> wrote:
> > ?BTW, systemd allows to define addition mountpoints in
> > ?systemd.mount(5) unit file(s), so we already have additional place
> > ?for fstab stuff...
> 
> systemd needs a large blunt object be stuck into its eye.
> 
> systemd was supposed to be an init replacement.
> Its continuing attempts to infiltrate entire system
> are very worrying.

I'm not saying I like /etc/foo.d/* (hell, sed in post-install is not
a big deal; not for fstab, not for inetd.conf, etc.), but yes,
complaints about changes that make life somewhat more difficult for
systemd are rather hypocritical, what with the embrace-and-extend
games they are playing.

Re: /etc/fstab.d yes or not (resolved)

[Karel Zak]

 I have reverted the fstab.d support. The libmount will NOT read
 /etc/fstab.d by default.

 If you really need an additional configuration outside /etc/fstab
 then you have to explicitly add the option --fstab <path> to mount(8)
 command line. This option may be specified more than once and the
 <path> may be a directory. This solution should be enough for
 initramfs scripts.

 Thanks for feedback.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com