Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/28/2015 06:57 AM, William Hubbs wrote: > On Mon, Jul 27, 2015 at 07:25:20PM -0700, Daniel Campbell (zlg) > wrote: >> What would a migration be like? For example, I manage >> filesystems exclusively through fstab (to my knowledge). Would >> this be useful for, say, mounting over the network? What would >> managing FSes with openrc look like? > > I don't quite understand your question, but I'll give it a shot. > > With the new mount service, it will not matter whether the file > systems are local or on the network. It will be up to you to > configure the mounts for each file system to start in the right > order and configure their dependencies. > > I am not looking at deprecating fstab at this point; I'm not sure > how I would go about figuring out the locations of mount points > without it yet. > > William > Okay, so OpenRC's filesystem management is more like an enhancement for standard /etc/fstab mounts? My apologies for the vague questions. Perhaps I should spend my next weekend off learning a bit more about how OpenRC handles mounting. - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVuJSnAAoJEAEkDpRQOeFwBdcQALtzqCDnXHI364vVJhWXQRac FRtALTx/RlgG2BS7fclMp5PPC7TYWG4jH50ZD35qozH46JJuhocMwfL02g+FXHIa 1MfaIzXuvhPMotj05PxoaBVBU7TmyhNEFiQJqD7qNu2vgsrknjc2QxXc1+INSgby cfMhmh49nxi6ZxvFAEBXlk2U0RRpomKh/og4NHSd2CiNFDHyg9r2D21S1YAaIAmh n4SHfh1c3y0sDOlhdOaEi6D0a5IGJqM9779LMeKOSjiSGXU+d3Xk+Vhkyo+SXrco 2jk6svz/Sm0XdOz4tCenr/j9PmGSN7UP8QUitoKm+2LmII+ZXkyzWYi5s41knl+2 49fw0fwGKIWJyQKV1f6IHTKOEKaAkxsWIjcmRcVxrQjiZ619ptZJIAv0ILEjZgtr 3/BNV5wiupRuz5aTTnCQdXwBX6wyQnLDsHHLInSjIcM4HCw9Ao2RfEJIAHrS0Sgj rnMV20ixNUgGY+WAv5HXF2HhNNa1ugzuwm+jZqgTjXqubHv9YfUHcJK8ahuWqiN8 IFJde5byla1zom7v+xkwi7rB0WE2La+oGndF+7lxgPkHD5JLtZTzgagYEVVeyFFT xczket5z0LjiRU4GSgucq+vAQUJqyocOprccOn/o5jkRuCexdnLPkZdiMgYzAPN6 cwluPs5OA8LMQPogcrVQ =Q+eI -END PGP SIGNATURE-
[gentoo-dev] Last rites: dev-java/{jldap,openspml,openspml2,soap}
# James Le Cuirot (29 Jul 2015) # dev-java/soap is fixable but it and its related packages are all # dead upstream. Removal in 30 days. See bug #556250. dev-java/jldap dev-java/openspml dev-java/openspml2 dev-java/soap -- James Le Cuirot (chewi) Gentoo Linux Developer pgpRA8ZVZyskS.pgp Description: OpenPGP digital signature
[gentoo-dev] rfc: openrc mount service prototype
All, 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. This is not on master for a very good reason; it is prototype material, definitely pre-alpha at this point. If you don't know how to mess with github branches, or you are not comfortable doing so, you don't want to mess with this. If you are, feel free to take a look at the mount service in that branch. I am interested in thoughts on it. Thanks, William signature.asc Description: Digital signature
[gentoo-dev] [warning] the bug queue has 83 bugs
Our bug queue has 83 bugs! If you have some spare time, please help assign/sort a few bugs. To view the bug queue, click here: http://bit.ly/m8PQS5 Thanks!
[gentoo-dev] Re: rfc: improve file system mounting and unmounting in OpenRC
Daniel Campbell (zlg) posted on Wed, 29 Jul 2015 01:54:03 -0700 as excerpted: > On 07/28/2015 06:57 AM, William Hubbs wrote: >> >> I don't quite understand your question, but I'll give it a shot. >> >> With the new mount service, it will not matter whether the file systems >> are local or on the network. It will be up to you to configure the >> mounts for each file system to start in the right order and configure >> their dependencies. >> >> I am not looking at deprecating fstab at this point; I'm not sure how I >> would go about figuring out the locations of mount points without it >> yet. >> > Okay, so OpenRC's filesystem management is more like an enhancement for > standard /etc/fstab mounts? > > My apologies for the vague questions. Perhaps I should spend my next > weekend off learning a bit more about how OpenRC handles mounting. What openrc does now is the traditional three-stage (plus fscks where appropriate) mount. 1) root The initial root mount is of course normally read-only, and handled either in the initr* or directly in the kernel. What openrc does is remount it (after fsck if appropriate) using the options in fstab, normally including mounting it writable, altho some installations may keep root read-only by default, as I do here. 2) other local filesystems Openrc's localmount service mounts these (after fsck if appropriate) using the standard mount -a, which basically mass-mounts everything (not marked noauto or on the remote filesystem types exclusion list) in fstab. There's no explicit dependency handling other than processing remote filesystems separately, so the only ordering done is the sequence in which they appear in fstab, and that only because mount -a happens to do it that way. So an admin must handle nested mountpoints, etc, manually, either by ensuring that the fstab listing sequence is correct if that's enough, or by setting them noauto in fstab, and either creating creating a custom service to mount them, or doing it entirely manually, issuing the mount commands at the CLI after boot, every time. 3) other remote/network filesystems I have no personal experience with these, but presumably they work the same way as the local filesystem processing, no explicit dependency handling, only minimal implicit fstab-sequential dependency handling. What williamh is proposing here is the addition of explicit dependency handling via mount service multiplexing, similar to the way openrc multiplexes its network interface services, thus making explicit dependencies on specific networks, and now filesystems, possible. [While I'm now subsumed into systemd, I ran live-git openrc- for many years, submitting and sometimes proposing patches for a significant number of bugs along the way. My system setup is customized sufficiently, including multiple mounts, some of them nested, that I found ~arch openrc problematic as it was too granular, dropping a whole bunch of potentially troublesome changes at once, making troubleshooting difficult. By running live-git openrc and religiously checking for updates and reviewing git log orig_head.., and git show-ing any commits that looked interesting, I could follow individual commit-level changes and see where things broke, giving me a head start in patching back to workability, when necessary. Of course this helped catch some of those bugs before they ever made it into an ~arch release, let alone stable, so ~arch users in particular were the beneficiaries. =:^) Anyway, as a result of that, I tend to be rather familiar with openrc's workings, certainly at the service level, tho troubleshooting that did get me exploring the more esoteric functionality of some of the C-coded helper binaries from time to time, as well. Now I'm subsumed into systemd, but as I said, by the time I switched, several other folks were evidently running openrc- as well, filing bugs as necessary, and williamh was doing good things with openrc -- witness this thread -- so I think it was left in good hands. =:^) And I still care about it as even if I'm subsumed, I think it's important that there continues to be *some* alternative to systemd, for much the same reason I make it a practice to note the location of fire extinguishers and exits when I'm traveling -- I want them available should worse come to worse and I have to use them!] -- 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
Re: [gentoo-dev] rfc: openrc mount service prototype
On 29 July 2015 at 23:20, William Hubbs wrote:
>
> All,
>
> 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.
Nice!
But I still trying to figure out why do we need to keep fstab around.
It is pure legacy.
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}=
There can even be a script to set above environments from fstab as
pure utility given mountpoint as parameter. This will simplify the
service as it will always accept the variables at one form.
Regards,
Alon
Re: [gentoo-dev] rfc: openrc mount service prototype
On Thu, Jul 30, 2015 at 01:11:30AM +0300, Alon Bar-Lev wrote: > On 29 July 2015 at 23:20, William Hubbs wrote: > > > > All, > > > > 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. > > Nice! > > But I still trying to figure out why do we need to keep fstab around. > It is pure legacy. Is it? I have heard different people say it is, and it isn't, so I have no idea. If fstab is truly legasy, I'll look into that. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: openrc mount service prototype
On Wed, Jul 29, 2015 at 05:22:54PM -0500, William Hubbs wrote: > On Thu, Jul 30, 2015 at 01:11:30AM +0300, Alon Bar-Lev wrote: > > On 29 July 2015 at 23:20, William Hubbs wrote: > > > > > > All, > > > > > > 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. > > > > Nice! > > > > But I still trying to figure out why do we need to keep fstab around. > > It is pure legacy. > > Is it? I have heard different people say it is, and it isn't, so I have > no idea. > > If fstab is truly legasy, I'll look into that. It seems that it is not legasy... For example, what happens if you do: mount /foo/bar and don't have fstab? William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: openrc mount service prototype
On 30 July 2015 at 01:22, William Hubbs wrote:
> On Thu, Jul 30, 2015 at 01:11:30AM +0300, Alon Bar-Lev wrote:
>> On 29 July 2015 at 23:20, William Hubbs wrote:
>> >
>> > All,
>> >
>> > 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.
>>
>> Nice!
>>
>> But I still trying to figure out why do we need to keep fstab around.
>> It is pure legacy.
>
> Is it? I have heard different people say it is, and it isn't, so I have
> no idea.
>
> If fstab is truly legasy, I'll look into that.
for what it worth, a fstab.d would have been something usable... :)
but if you are providing netifrc like configuration, there is no need
to split configuration between the layout and the fstab, everything
should be at one place if possible.
maybe we can have some intermediate options... to bridge the gap, but
all are in the scope of conf.d, examples:
eval $(openrc-mount-helper-fstab ${NAME} /mnt/auto)
or... builtin
mount_driver_\${NAME}=fstab # will call eval
$(openrc-mount-helper-${openrc-mount-driver-\${NAME}} ${NAME} "$@")
mount_mountpoint=/mnt/auto
but this fstab usage is optional.
Re: [gentoo-dev] rfc: openrc mount service prototype
On Thu, 30 Jul 2015 01:11:30 +0300
Alon Bar-Lev wrote:
> On 29 July 2015 at 23:20, William Hubbs wrote:
> >
> > All,
> >
> > 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.
>
> Nice!
>
> 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.
> 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.
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.
Re: [gentoo-dev] rfc: openrc mount service prototype
On 30 July 2015 at 01:33, William Hubbs wrote: > On Wed, Jul 29, 2015 at 05:22:54PM -0500, William Hubbs wrote: >> On Thu, Jul 30, 2015 at 01:11:30AM +0300, Alon Bar-Lev wrote: >> > On 29 July 2015 at 23:20, William Hubbs wrote: >> > > >> > > All, >> > > >> > > 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. >> > >> > Nice! >> > >> > But I still trying to figure out why do we need to keep fstab around. >> > It is pure legacy. >> >> Is it? I have heard different people say it is, and it isn't, so I have >> no idea. >> >> If fstab is truly legasy, I'll look into that. > > It seems that it is not legasy... > > For example, what happens if you do: > > mount /foo/bar > > and don't have fstab? > > William > if I choose to not use fstab, I will not use mount /foo/bar Why will I do that? For example, I can put passwords in different ACL. I can add logic, for example dynamic mount point. This is why using netifrc like configuration is so great. I can choose to use fstab, then I lost all these goodies but can do mount /foo/bar...
Re: [gentoo-dev] rfc: openrc mount service prototype
On 30/07/2015 00:22, William Hubbs wrote: > On Thu, Jul 30, 2015 at 01:11:30AM +0300, Alon Bar-Lev wrote: >> On 29 July 2015 at 23:20, William Hubbs wrote: >>> >>> All, >>> >>> 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. >> >> Nice! >> >> But I still trying to figure out why do we need to keep fstab around. >> It is pure legacy. > > Is it? I have heard different people say it is, and it isn't, so I have > no idea. > > If fstab is truly legasy, I'll look into that. You have to list the standard mounts /somewhere/, it might as well be /etc/fstab... There's very little useless cruft in that file -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-dev] Re: rfc: openrc mount service prototype
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
> wrote:
>
>> On 29 July 2015 at 23:20, William Hubbs 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 of
