Gentoo Archives: gentoo-dev

From: "Daniel Campbell (zlg)" <zlg@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: rfc: openrc mount service prototype
Date: Mon, 03 Aug 2015 07:22:51
Message-Id: 55BF16C2.5060804@gentoo.org
In Reply to: Re: [gentoo-dev] Re: rfc: openrc mount service prototype by Alon Bar-Lev
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA256
3
4 On 07/30/2015 09:55 AM, Alon Bar-Lev wrote:
5 > On 30 July 2015 at 19:15, Ian Stakenvicius <axs@g.o> wrote:
6 >>
7 >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
8 >>
9 >> On 30/07/15 01:55 AM, Duncan wrote:
10 >>> Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as
11 >>> excerpted:
12 >>>
13 >>>> On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev
14 >>>> <alonbl@g.o> wrote:
15 >>>>
16 >>>>> On 29 July 2015 at 23:20, William Hubbs
17 >>>>> <williamh@g.o> wrote:
18 >>>>>>
19 >>>>>> so that there is a better idea out there of what I'm
20 >>>>>> talking about, the OpenRC github repository now has a
21 >>>>>> mount-service branch.
22 >>>>>
23 >>>>> But I still trying to figure out why do we need to keep
24 >>>>> fstab around. It is pure legacy.
25 >>>>>
26 >>>>>
27 >>>> On what planet is fstab pure legacy? Many utilities use it
28 >>>> and expect it to exist. For example the ability to do "mount
29 >>>> /foo" requires a properly configured fstab file (also mount
30 >>>> -a).
31 >>>>
32 >>
33 >> I think there are two meanings of the word legacy here.
34 >>
35 >> #1, /etc/fstab on linux is not legacy, and I don't think anyone
36 >> here (except possibly for WilliamH as I can't actually tell from
37 >> his statements) has been calling it 'legacy' in this context.
38 >
39 > /etc/fstab is legacy in the sense it did not evolve since early
40 > days of UNIX. Imagine /etc/crontab was left the same single file,
41 > but it at least evolved to usr /etc/cron.*/ to ease management of
42 > multiple sources and ease packaging/maintenance without need to
43 > parse and rewrite single file when provisioning.
44 >
45 > Nobody ignores /etc/fstab existence, I provided solutions of how
46 > /etc/fstab can be read in flexible method as netifrc does (which
47 > was actually the core idea of this move), doing so will make the
48 > service much simpler as it can use external helper scripts to
49 > provide the data out of whatever source, please re-read my
50 > message.
51 >
52 > However, having the option *NOT* to use /etc/fstab has many
53 > advantages in security (storing credentials in own files),
54 > provisioning (no need to race parse/rewrite), dynamic (define the
55 > location of nfs server based on logic) and many more.
56 >
57 > I do not understand why people are so sensitive for a change that
58 > does not effect the outcome of their need, all that I recommended
59 > to add is driver:
60 >
61 > mount_driver_\${NAME}=fstab mount_mountpoint_\${NAME}=/mnt/auto
62 >
63 > driver will be executed by the service, in this case:
64 >
65 > openrc-mount-helper-${openrc_mount_driver_\${NAME}}
66 > ${mount_mountpoint_\${NAME}}
67 >
68 > the output will be evaluated. This simple solution will enable the
69 > service to be generic and provide flexible pure configuration
70 > (whatever we choose), while support any source of information that
71 > is capable of constructing this configuration.
72 >
73 > Loose nothing gain some, simpler service and constraint fstab
74 > within driver.
75 >
76 > Another drive I can think of is UPnP.
77 >
78 > Regards, Alon
79 >
80
81 I'm having a hard time understanding why we need daemons to handle our
82 filesystems. Can you give me a use case that /etc/fstab is
83 insufficient for solving?
84
85 - --
86 Daniel Campbell - Gentoo Developer
87 OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
88 fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
89 -----BEGIN PGP SIGNATURE-----
90 Version: GnuPG v2
91
92 iQIcBAEBCAAGBQJVvxa+AAoJEAEkDpRQOeFwGWUQAKCnuRLHYmUikYu+u0+1Tkck
93 eFmzW7C/G+Tbm5vqkRwk0F781gIPbpV36QOdIoTfBB65HJ9155VnsISXmQskf1+7
94 HN2guLTBrtOttZXOyF4KU7klGwElYTmD6tjMmH7aTxy6ID3lMKNtWDlktNgxPcH8
95 lfYsmB2DJ3+pxdMpPLCg0tGcR+s2RjNKJUnbXNGXO3vzO7PH/gPG9KkqtlVI/78I
96 Xf1m1e/MCEpRU8c2GCRzDuUkznUp3OMoXysMo3a/1c7NYx+KZ9CIlFZXiOX8CKJ5
97 hVf1xE0g8spRnH5Bq/EXO0mMhdWLB82ax4mD+jXdMR7H1i8SHjHGqQwQlKRFGIyg
98 UFfFcgz1GswGGar/AjkKz02FuiMYgJ7kU2nRHBlNsfjnjsdc8iIxPGhcCMWYZjuD
99 kLE/c6487ymQTMMYlIZ/qG7/90k57/TXZq0AuBPCB4/HD2vHMJBcYQkoWlnQSGEC
100 oYrVEvb9N1eKYe7/IpxnKVGKTZY1OP+xtDGvpPwp1MtE0GZ9VQbhS1+aJy6nVrs1
101 Uxx6/H7RTFwD5Af4V6mNe20ucz5mkEJxX9qTsNMrDAu+DHFUC3CTtYmeRN9Fsbve
102 ibHsIh1N0mI0bOvN16VK2s/ToahnsP09WvkJpnMIyJSfs4qWfpOhTWN8JEMWEdo2
103 j7V+HGJZ2GNYm3K0hFJI
104 =YuTA
105 -----END PGP SIGNATURE-----

Replies

Subject Author
Re: [gentoo-dev] Re: rfc: openrc mount service prototype Brian Dolbec <dolsen@g.o>