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

[Alon Bar-Lev]

On 30 July 2015 at 19:15, Ian Stakenvicius <axs@g.o> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 30/07/15 01:55 AM, Duncan wrote:
> > 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).
> >>
>
> I think there are two meanings of the word legacy here.
>
> #1, /etc/fstab on linux is not legacy, and I don't think anyone here
> (except possibly for WilliamH as I can't actually tell from his
> statements) has been calling it 'legacy' in this context.

/etc/fstab is legacy in the sense it did not evolve since early days of UNIX.
Imagine /etc/crontab was left the same single file, but it at least
evolved to usr /etc/cron.*/ to ease management of multiple sources and
ease packaging/maintenance without need to parse and rewrite single
file when provisioning.

Nobody ignores /etc/fstab existence, I provided solutions of how
/etc/fstab can be read in flexible method as netifrc does (which was
actually the core idea of this move), doing so will make the service
much simpler as it can use external helper scripts to provide the data
out of whatever source, please re-read my message.

However, having the option *NOT* to use /etc/fstab has many advantages
in security (storing credentials in own files), provisioning (no need
to race parse/rewrite), dynamic (define the location of nfs server
based on logic) and many more.

I do not understand why people are so sensitive for a change that does
not effect the outcome of their need, all that I recommended to add is
driver:

mount_driver_\${NAME}=fstab
mount_mountpoint_\${NAME}=/mnt/auto

driver will be executed by the service, in this case:

    openrc-mount-helper-${openrc_mount_driver_\${NAME}}
${mount_mountpoint_\${NAME}}

the output will be evaluated. This simple solution will enable the
service to be generic and provide flexible pure configuration
(whatever we choose), while support any source of information that is
capable of constructing this configuration.

Loose nothing gain some, simpler service and constraint fstab within driver.

Another drive I can think of is UPnP.

Regards,
Alon