/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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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:
>>
>>  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.

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:
>> >>
>> >>  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.

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.  This 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
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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.
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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-l88Q8xmqi7wqcZcGjlUOXw@public.gmane.org> 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.
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: /etc/fstab.d yes or not

[Kay Sievers]

On Fri, Jan 20, 2012 at 17:22, Roger Leigh <rleigh-l88Q8xmqi7wqcZcGjlUOXw@public.gmane.org> 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-l88Q8xmqi7wqcZcGjlUOXw@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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

[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-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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.
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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