Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On 14-10-2013 10:00:03 +0400, Peter Volkov wrote: > В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет: > > from what I'm seeing, we should look into converting /etc/mtab to a > > symlink to /proc/self/mounts [1]. > > > > Are there any remaining concerns about doing this? > > The only concern I have how this change affects *BSD or prefix? But yet > I failed to find a package that is affected and that is not Linux > specific. If it works for the host system, then Prefix should be fine. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, Oct 14, 2013 at 12:42 AM, yac wrote: > > Curiously I don't see any difference on my gentoo box, which I think I > should see but I'm not sure. On mine the main difference seems to be bind mounts. In /etc/mtab the bind mount "device" is the directory that is being bind-mounted. In /proc/self/mounts it is the device that the directory sits on. Other than a little confusion, I"m not sure if that will actually cause any issues. Rich
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On 14 October 2013 03:32, William Hubbs wrote: > All, > > from what I'm seeing, we should look into converting /etc/mtab to a > symlink to /proc/self/mounts [1]. > > Are there any remaining concerns about doing this? > > If not, it seems like it would be pretty easy to make baselayout create > this symlink in the stages (I'm willing to do this work), but what about > on systems that are already installed? Should we send out a news item > and have everyone convert their /etc/mtab manually or find a way to > automate that? > > William > > [1] http://bugs.gentoo.org/show_bug.cgi?id=477498 I don't see a compelling case being made for why we should make this change apart from "all the other distros are doing it", and quite a few reasons why we shouldn't. I'm open to being convinced, so please tell me why this is good for Gentoo users. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot wrote: > I don't see a compelling case being made for why we should make this > change apart from "all the other distros are doing it", and quite a > few reasons why we shouldn't. I'm open to being convinced, so please > tell me why this is good for Gentoo users. So far I've seen a reference to a bug associated with a bunch of systemd issues when it isn't mounted, and the point that many things break in namespaces without the symlink, since /etc/mtab does not reflect the state of the namespace. The latter in particular seems like a pretty fundamental limitation - the very concept of /etc/mtab is that mounts are global, and the design of linux is that mounts are NOT global. If all the other distros are doing it, there is probably a reason. As far as problems with switching - I've only seen one or two correctable issues that seem compelling (NFS issues, and PAM issues). There was a bunch of talk about how making this change will cause a command designed to unmount everything actually unmount everything as well. But please continue to chime in with both pros and cons. Rich
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
That is my impression as well. With that said, the behavior is currently the same between our FreeBSD and Linux variants. This change would break that. On Oct 14, 2013, at 7:59 AM, Ben de Groot wrote: > On 14 October 2013 03:32, William Hubbs wrote: >> All, >> >> from what I'm seeing, we should look into converting /etc/mtab to a >> symlink to /proc/self/mounts [1]. >> >> Are there any remaining concerns about doing this? >> >> If not, it seems like it would be pretty easy to make baselayout create >> this symlink in the stages (I'm willing to do this work), but what about >> on systems that are already installed? Should we send out a news item >> and have everyone convert their /etc/mtab manually or find a way to >> automate that? >> >> William >> >> [1] http://bugs.gentoo.org/show_bug.cgi?id=477498 > > I don't see a compelling case being made for why we should make this > change apart from "all the other distros are doing it", and quite a > few reasons why we shouldn't. I'm open to being convinced, so please > tell me why this is good for Gentoo users. > > -- > Cheers, > > Ben | yngwin > Gentoo developer >
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Oct 14, 2013, at 9:19 AM, Rich Freeman wrote: > On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot wrote: >> I don't see a compelling case being made for why we should make this >> change apart from "all the other distros are doing it", and quite a >> few reasons why we shouldn't. I'm open to being convinced, so please >> tell me why this is good for Gentoo users. > > So far I've seen a reference to a bug associated with a bunch of > systemd issues when it isn't mounted, and the point that many things > break in namespaces without the symlink, since /etc/mtab does not > reflect the state of the namespace. The latter in particular seems > like a pretty fundamental limitation - the very concept of /etc/mtab > is that mounts are global, and the design of linux is that mounts are > NOT global. Why should this not be treated as a systemd bug? > If all the other distros are doing it, there is probably a reason. Perhaps they lack a FreeBSD variant and therefore see no reason to be different than Fedora. > As far as problems with switching - I've only seen one or two > correctable issues that seem compelling (NFS issues, and PAM issues). > There was a bunch of talk about how making this change will cause a > command designed to unmount everything actually unmount everything as > well. How do these corrections affect Gentoo FreeBSD?
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
Dnia 2013-10-14, o godz. 09:26:43 Richard Yao napisał(a): > On Oct 14, 2013, at 9:19 AM, Rich Freeman wrote: > > > On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot wrote: > >> I don't see a compelling case being made for why we should make this > >> change apart from "all the other distros are doing it", and quite a > >> few reasons why we shouldn't. I'm open to being convinced, so please > >> tell me why this is good for Gentoo users. > > > > So far I've seen a reference to a bug associated with a bunch of > > systemd issues when it isn't mounted, and the point that many things > > break in namespaces without the symlink, since /etc/mtab does not > > reflect the state of the namespace. The latter in particular seems > > like a pretty fundamental limitation - the very concept of /etc/mtab > > is that mounts are global, and the design of linux is that mounts are > > NOT global. > > Why should this not be treated as a systemd bug? Is it a Linux kernel bug that it supports mount namespaces? Since userspace clearly wasn't designed for that 20 years ago, so Linux clearly has a bug supporting that! -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too. With that said, how does changing things benefit/affect users, especially non-systemd users? On Oct 14, 2013, at 9:36 AM, Michał Górny wrote: > Dnia 2013-10-14, o godz. 09:26:43 > Richard Yao napisał(a): > >> On Oct 14, 2013, at 9:19 AM, Rich Freeman wrote: >> >>> On Mon, Oct 14, 2013 at 7:59 AM, Ben de Groot wrote: I don't see a compelling case being made for why we should make this change apart from "all the other distros are doing it", and quite a few reasons why we shouldn't. I'm open to being convinced, so please tell me why this is good for Gentoo users. >>> >>> So far I've seen a reference to a bug associated with a bunch of >>> systemd issues when it isn't mounted, and the point that many things >>> break in namespaces without the symlink, since /etc/mtab does not >>> reflect the state of the namespace. The latter in particular seems >>> like a pretty fundamental limitation - the very concept of /etc/mtab >>> is that mounts are global, and the design of linux is that mounts are >>> NOT global. >> >> Why should this not be treated as a systemd bug? > > Is it a Linux kernel bug that it supports mount namespaces? Since > userspace clearly wasn't designed for that 20 years ago, so Linux > clearly has a bug supporting that! > > -- > Best regards, > Michał Górny
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao wrote: > The Linux kernel also supports far more architectures than we do. That does > not mean that we must support them too. > > With that said, how does changing things benefit/affect users, especially > non-systemd users? Better support for namespaces, for one. If this is actually going to actually break something, by all means speak up. Otherwise this really comes across as the whole I-DONT-LIKE-CHANGE argument. I get it. By all means don't make your /etc/mtab a symlink, and if down the road something doesn't work as a result feel free to fork it unless you can convince somebody else to make it work. So far the only concrete issues that have been raised seem minor - pertaining to NFS and PAM (both having solutions available). If this causes trouble for the FreeBSD folks I'm interested in what kinds of compromises can be reached. I think a challenge is that Linux and FreeBSD seem to be very slowly diverging - for software that lives near the kernel/userspace boundary that could make things interesting. There doesn't seem to be much desire to limit Linux distros to purely POSIX behavior. Rich
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On 10/14/2013 10:11 AM, Rich Freeman wrote: > On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao wrote: >> The Linux kernel also supports far more architectures than we do. That does >> not mean that we must support them too. >> >> With that said, how does changing things benefit/affect users, especially >> non-systemd users? > > Better support for namespaces, for one. > > If this is actually going to actually break something, by all means > speak up. Otherwise this really comes across as the whole > I-DONT-LIKE-CHANGE argument. I get it. By all means don't make your > /etc/mtab a symlink, and if down the road something doesn't work as a > result feel free to fork it unless you can convince somebody else to > make it work. So far the only concrete issues that have been raised > seem minor - pertaining to NFS and PAM (both having solutions > available). > > If this causes trouble for the FreeBSD folks I'm interested in what > kinds of compromises can be reached. I think a challenge is that > Linux and FreeBSD seem to be very slowly diverging - for software that > lives near the kernel/userspace boundary that could make things > interesting. There doesn't seem to be much desire to limit Linux > distros to purely POSIX behavior. > > Rich > My main concern is that some of the configure flags being proposed could make packages that worked on Gentoo FreeBSD stop working there. I am not making changes, but I think that there should be some benefit and that care should be taken not to break things for everyone else. That being said, mgorny said that this adds support for mount namespaces, but I have yet to hear an explanation of what that actually means. What are the use cases? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, Oct 14, 2013 at 10:00:03AM +0400, Peter Volkov wrote: > В Вс, 13/10/2013 в 14:32 -0500, William Hubbs пишет: > > from what I'm seeing, we should look into converting /etc/mtab to a > > symlink to /proc/self/mounts [1]. > > > > Are there any remaining concerns about doing this? > > The only concern I have how this change affects *BSD or prefix? But yet > I failed to find a package that is affected and that is not Linux > specific. Right, there are no plans to touch *bsd. This would just be a modification to the Linux-specific portion of baselayout. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, Oct 14, 2013 at 10:46:38AM -0400, Richard Yao wrote: > On 10/14/2013 10:11 AM, Rich Freeman wrote: > > On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao wrote: > >> The Linux kernel also supports far more architectures than we do. That > >> does not mean that we must support them too. > >> > >> With that said, how does changing things benefit/affect users, especially > >> non-systemd users? > > > > Better support for namespaces, for one. > > > > If this is actually going to actually break something, by all means > > speak up. Otherwise this really comes across as the whole > > I-DONT-LIKE-CHANGE argument. I get it. By all means don't make your > > /etc/mtab a symlink, and if down the road something doesn't work as a > > result feel free to fork it unless you can convince somebody else to > > make it work. So far the only concrete issues that have been raised > > seem minor - pertaining to NFS and PAM (both having solutions > > available). > > > > If this causes trouble for the FreeBSD folks I'm interested in what > > kinds of compromises can be reached. I think a challenge is that > > Linux and FreeBSD seem to be very slowly diverging - for software that > > lives near the kernel/userspace boundary that could make things > > interesting. There doesn't seem to be much desire to limit Linux > > distros to purely POSIX behavior. As I said earlier in the thread, the planned baselayout change will only affect Linux. > My main concern is that some of the configure flags being proposed could > make packages that worked on Gentoo FreeBSD stop working there. I am not > making changes, but I think that there should be some benefit and that > care should be taken not to break things for everyone else. Richard, the packages we are discussing (nilfs-utils and nfs-utils) are linux-specific, so there is nothing to worry about on the *bsd side for them. > That being said, mgorny said that this adds support for mount > namespaces, but I have yet to hear an explanation of what that actually > means. What are the use cases? There has been a lot written on this; you might want to google "per-process namespaces". William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On 10/14/2013 10:46 AM, Richard Yao wrote: > My main concern is that some of the configure flags being proposed could > make packages that worked on Gentoo FreeBSD stop working there. I am not > making changes, but I think that there should be some benefit and that > care should be taken not to break things for everyone else. > > That being said, mgorny said that this adds support for mount > namespaces, but I have yet to hear an explanation of what that actually > means. What are the use cases? > Someone brought to my attention that there was a slight error in the above message. I had meant to write "I am not against making changes..." rather than "I am not making changes...". In hindsight, the statement that "I am not making changes" was a more profound statement than the one that I meant to write because it can be interpreted in any of two ways: 1. It could be interpreted as meaning that I intend to oppose proposed changes when they have no benefit and I have the ability to oppose them. 2. It could be interpreted as meaning that I am not one of the people who make decisions for the packages involved. Consequently, my opinion here only matters to the extent that those who make decisions are willing to consider it. Both of which are correct. That being said, I am not against making changes, but given that this is on the list, I would like to someone to provide a technical justification. Some key questions that justification should answer are "what capability does this provide to sysytemd that cannot be obtained without this change? and "what does that do for users"? So far, the only thing that I have read is "systemd wants it", which answers neither question. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On 10/14/2013 12:34 PM, William Hubbs wrote: > On Mon, Oct 14, 2013 at 10:46:38AM -0400, Richard Yao wrote: >> On 10/14/2013 10:11 AM, Rich Freeman wrote: >>> On Mon, Oct 14, 2013 at 9:52 AM, Richard Yao wrote: The Linux kernel also supports far more architectures than we do. That does not mean that we must support them too. With that said, how does changing things benefit/affect users, especially non-systemd users? >>> >>> Better support for namespaces, for one. >>> >>> If this is actually going to actually break something, by all means >>> speak up. Otherwise this really comes across as the whole >>> I-DONT-LIKE-CHANGE argument. I get it. By all means don't make your >>> /etc/mtab a symlink, and if down the road something doesn't work as a >>> result feel free to fork it unless you can convince somebody else to >>> make it work. So far the only concrete issues that have been raised >>> seem minor - pertaining to NFS and PAM (both having solutions >>> available). >>> >>> If this causes trouble for the FreeBSD folks I'm interested in what >>> kinds of compromises can be reached. I think a challenge is that >>> Linux and FreeBSD seem to be very slowly diverging - for software that >>> lives near the kernel/userspace boundary that could make things >>> interesting. There doesn't seem to be much desire to limit Linux >>> distros to purely POSIX behavior. > > As I said earlier in the thread, the planned baselayout change will only > affect Linux. > >> My main concern is that some of the configure flags being proposed could >> make packages that worked on Gentoo FreeBSD stop working there. I am not >> making changes, but I think that there should be some benefit and that >> care should be taken not to break things for everyone else. > > Richard, the packages we are discussing (nilfs-utils and nfs-utils) > are linux-specific, so there is nothing to worry about on the *bsd side > for them. That is good to hear. There were a few situations int he past where changes were made for Gentoo Linux that broke Gentoo FreeBSD, so I wanted to be certain that we were not going to have a repeat of that here. >> That being said, mgorny said that this adds support for mount >> namespaces, but I have yet to hear an explanation of what that actually >> means. What are the use cases? > > There has been a lot written on this; you might want to google > "per-process namespaces". If this merits discussion on the list, then it should merit answers for these questions: 1. What are mount namespaces? How do they integrate with the kernel? 2. What does systemd do with them? What does systemd's use of them provide to users? Saying to google "per-process namespaces" does not really answer that. Per-process namespaces provide a means to isolate processes into containers that they have their own pid numbers and can neither nor interact with processes outside of the container via traditional IPC mechanisms such as signals. It is similar to the concept of FreeBSD jails. That does not tell me what a "mount namespace is" or why systemd has anything to do with it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, Oct 14, 2013 at 12:47:08PM -0400, Richard Yao wrote: *snip* > Both of which are correct. That being said, I am not against making > changes, but given that this is on the list, I would like to someone to > provide a technical justification. Some key questions that justification > should answer are "what capability does this provide to sysytemd that > cannot be obtained without this change? and "what does that do for > users"? So far, the only thing that I have read is "systemd wants it", > which answers neither question. A quick google for per-process namespaces turns up this lwn series: http://lwn.net/Articles/531114/ This functionality can't be fully supported if /etc/mtab is a file. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, Oct 14, 2013 at 1:01 PM, Richard Yao wrote: > > 1. What are mount namespaces? How do they integrate with the kernel? > 2. What does systemd do with them? What does systemd's use of them > provide to users? > > Saying to google "per-process namespaces" does not really answer that. > Per-process namespaces provide a means to isolate processes into > containers that they have their own pid numbers and can neither nor > interact with processes outside of the container via traditional IPC > mechanisms such as signals. It is similar to the concept of FreeBSD > jails. That does not tell me what a "mount namespace is" or why systemd > has anything to do with it. > You're describing a process namespace, which is only one type of namespace. All namespaces are "per-process," but process namespaces are just one type of per-process namespace. Confused yet? All processes within the same mount namespace see the same filesystem. If I run mount /dev/cdrom /mnt/cdrom in one process, then all processes in the same namespace will see it mounted. However, processes in another namespace will NOT see the new mount. To illustrate, if you are on linux with util-linux installed launch two root shells, and in one execute: mkdir /tmp/foo touch /tmp/foo/a unshare -m /bin/bash mount -t tmpfs none /tmp/foo touch /tmp/foo/b ls /tmp/foo Then run ls /tmp/foo in your other process. They'll see two different directories, because the tmpfs mounted in the separate namespace created by unshare is not visible to any other process. To clean up within the namespace umount /tmp/foo and exit (I have no idea if it is possible to unmount the tmpfs if you exit first, or if the kernel does it for you). The possibilities are endless. You could mount an encrypted home for a user and make it visible only to the user. Containers are an obvious way to use them. Systemd lets you configure daemons to have restricted access to the filesystem as well - either read-only, or not at all - by directory. I assume it just clones the mount namespace, and then sets up bind-mounts to implement this before dropping root and launching the process. Rich
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
Rich Freeman wrote: [...] and the point that many things break in namespaces without the symlink, since /etc/mtab does not reflect the state of the namespace. The latter in particular seems like a pretty fundamental limitation - the very concept of /etc/mtab is that mounts are global, and the design of linux is that mounts are NOT global. If only someone would invent some sort of kernel feature that could make the name "/etc/mtab" refer to different files in different processes
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On 10/14/2013 01:24 PM, Rich Freeman wrote: > Systemd lets you configure daemons to have restricted access to the > filesystem as well - either read-only, or not at all - by directory. > I assume it just clones the mount namespace, and then sets up > bind-mounts to implement this before dropping root and launching the > process. On 10/14/2013 01:08 PM, William Hubbs wrote: > This functionality can't be fully supported if /etc/mtab is a file. That is all that I needed to read. Make sure that there are no regressions for existing users and I am all for it. :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, Oct 14, 2013 at 2:58 PM, David Leverton wrote: > > If only someone would invent some sort of kernel feature that could make the > name "/etc/mtab" refer to different files in different processes > Well, the symlink seems like the simpler solution to be honest. I mean, instead of having the ps command to list running processes you could just have a daemon dump the list in a file every 10 seconds and have programs read it, but... However, FWIW, linux namespaces cannot be used to have only a single file appear differently to different processes. Mount namespaces can only operate at the directory level. I was actually looking into using namespaces as an alternative to the sandbox model portage currently uses. Basically you'd look at a package's DEPENDs and build a namespace containing only those files, and now devs don't inadvertently add ebuilds that are missing DEPENDs. A bit of a tangent, but the sandbox functionality in portage CAN be used to do just this with somewhat little effort. I've just never gotten around to trying it out. By default sandbox is told to give read-access to everything - the sandbox command does restrict both reads and writes already and if that configuration were made dynamic and set by portage per-package it would work just fine. I just figured namespaces would be a more elegant solution (it is also more secure, but security isn't really a concern here). Rich
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
Rich Freeman wrote:
However, FWIW, linux namespaces cannot be used to have only a single
file appear differently to different processes. Mount namespaces can
only operate at the directory level.
So to work around that limitation we insist that everyone change how
their systems are set up, and still have to reintroduce mtab under a
different name ("utab", hidden away under /run) because
/proc/self/mounts *doesn't* contain everything that's supposed to be in
mtab after all?
If someone decides they want to use, say, different DNS servers in
different namespaces, should we make the kernel store the server IP
addresses, add a /proc file that dumps them out in the expected format,
and demand that everyone replace their /etc/resolv.conf with a symlink
to /proc/self/resolv.conf? Or maybe, if people want namespaces, they
can implement them properly, in which case it becomes literally a
self-solving problem.
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, Oct 14, 2013 at 4:03 PM, David Leverton
wrote:
> Rich Freeman wrote:
>>
>> However, FWIW, linux namespaces cannot be used to have only a single
>> file appear differently to different processes. Mount namespaces can
>> only operate at the directory level.
>
>
> So to work around that limitation we insist that everyone change how their
> systems are set up, and still have to reintroduce mtab under a different
> name ("utab", hidden away under /run) because /proc/self/mounts *doesn't*
> contain everything that's supposed to be in mtab after all?
>
> If someone decides they want to use, say, different DNS servers in different
> namespaces, should we make the kernel store the server IP addresses, add a
> /proc file that dumps them out in the expected format, and demand that
> everyone replace their /etc/resolv.conf with a symlink to
> /proc/self/resolv.conf? Or maybe, if people want namespaces, they can
> implement them properly, in which case it becomes literally a self-solving
> problem.
>
>
This is a horrible example. /etc/resolv.conf is a configuration file
for code that lives entirely in userspace. Of course it makes no sense
to shove that into the kernel.
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, Oct 14, 2013 at 4:03 PM, David Leverton
wrote:
> So to work around that limitation we insist that everyone change how their
> systems are set up, and still have to reintroduce mtab under a different
> name ("utab", hidden away under /run) because /proc/self/mounts *doesn't*
> contain everything that's supposed to be in mtab after all?
The whole design of /etc/mtab is broken. It isn't a list of
everything that is mounted - it is a list of everything done by the
mount command (the command - not the system call). The handbook even
has a line about having to manually populate it before running grub
since it is flat-out wrong when you're in a chroot. There are lots of
things that can cause it to get out-of-sync.
Perhaps there are edge cases where the symlink isn't sufficient -
that's what this thread is all about. However, I've never liked the
design of mtab. It isn't surprising to me that distros are largely
ditching it.
> /etc/resolv.conf
As Mike already pointed out, resolution is actually a userspace
function entirely (I'm not sure if I were designing things from
scratch that I'd put it in the C library, but...).
However, if you want to know the hostname, you should be calling uname
and not looking around for /etc/hostname or whatever. The kernel will
tell you the truth as it applies to your process, not what you think
should be the truth based on what amounts to a logfile.
Rich
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
Mike Gilbert wrote: This is a horrible example. /etc/resolv.conf is a configuration file for code that lives entirely in userspace. Of course it makes no sense to shove that into the kernel. My point is that it's silly to have a hard-coded special case in the kernel for mtab, especially if it doesn't do the job properly and requires an extra utab file, when the general solution could work for any file and wouldn't require any changes when the namespace feature isn't in use.
[gentoo-dev] media-sound/beets up for grabs
I haven't spent much time on beets lately. Current version in tree is 1.1.0, upstream is at 1.3.1. I have the ebuild more or less ready, but it still needs testing/cleanups before I'd be willing to commit to tree. I would *really* appreciate someone taking the package (and several deps, see end of my email). I'd still help out if needed as secondary maintainer. Only missing dependency I could see is version bump for mutagen[1]. Upstream has quite extensive testsuite, plugin architecture which is great for USE flags and Adrian (sampsyo) generally reacts fast and accepts patches that fix or simplify packaging work. In other words...ideal upstream. Dependency chain that is related and maintained by me: dev-python/pyechonest dev-python/munkres dev-python/unidecode dev-python/python-musicbrainz-ngs dev-python/audioread dev-python/pylast dev-python/pyacoustid dev-python/bluelet media-sound/rgain media-sound/beets Currently there are 2 bugs for beets, one is version bump[2] of beets itself and the second[3] is request for replacement of ffmpeg with virtual requires (which is a bit tricky and would likely need upstream work). Any takers? Feel free to add yourself to the top of metadata.xml and ping me on IRC. Unless I'll find some other primary maintainer I'll move to package to maintainer-wanted so that bugs don't accidentally end up in black hole. [1] https://github.com/sampsyo/beets/pull/417 [2] https://bugs.gentoo.org/show_bug.cgi?id=472506 [3] https://bugs.gentoo.org/show_bug.cgi?id=459756 -- Stanislav Ochotnicky Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: signature
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
On Mon, 14 Oct 2013 15:50:36 -0400 Rich Freeman wrote: > On Mon, Oct 14, 2013 at 2:58 PM, David Leverton > wrote: > > > > If only someone would invent some sort of kernel feature that could > > make the name "/etc/mtab" refer to different files in different > > processes > > > > However, FWIW, linux namespaces cannot be used to have only a single > file appear differently to different processes. Mount namespaces can > only operate at the directory level. This is not true. Bind mounts can be performed on a single file, and bind mounts are part of mount namespaces. Granted the target file _must_ exist (it could be a dead symlink, or a symlink to /dev/null) before performing the bind mount.
Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink
Patrick McLean wrote: This is not true. Bind mounts can be performed on a single file, and bind mounts are part of mount namespaces. Granted the target file _must_ exist (it could be a dead symlink, or a symlink to /dev/null) before performing the bind mount. Well that's even better then. :-)
[gentoo-dev] rfc: read-only root Was: rfc: converting /etc/mtab to a symlink
William Hubbs posted on Sun, 13 Oct 2013 14:32:32 -0500 as excerpted: > from what I'm seeing, we should look into converting /etc/mtab to a > symlink to /proc/self/mounts [1]. > > Are there any remaining concerns about doing this? > > If not, it seems like it would be pretty easy to make baselayout create > this symlink in the stages (I'm willing to do this work), but what about > on systems that are already installed? Should we send out a news item > and have everyone convert their /etc/mtab manually or find a way to > automate that? > > William > > [1] http://bugs.gentoo.org/show_bug.cgi?id=477498 New subthread here as I don't see this mentioned in the others (tho pacho mentions it in the bug) ... TL;DR: An /etc/mtab symlink is the generally recommended and simplest way to make a read-only root work, and I've been setup like that for some months now, so I'm all for it. =:^) Some months ago I finally upgraded my core system to SSDs, and with that, btrfs (I had been on reiserfs for years with very good results even thru hardware issues as since ordered-by-default journaling went in, anyway, it's an incredibly stable filesystem that doesn't have the kernel folks monkeying around with it and trying stuff like the infamous ext3- writeback-by-default tricks, like the ext* filesystems do, but unfortunately reiserfs simply was no designed for nor is it suited to SSDs), which of course is still an experimental filesystem, for good reason as altho the mainstream case tends to work relatively well, they're still fixing critical corner-case bugs with every kernel release. So to hopefully counter some of the additional risk, and because I had been looking at the idea for a couple years anyway, I setup a read-only root by default. And I'll tell you what, it sure is nice knowing that after a hard shutdown and reboot, while /home and /var/log will probably have integrity errors due to the bad shutdown and I'll need to do a btrfs scrub to repair them (a pair of SSDs with most filesystems in btrfs raid1 mode for both data and metadata, so there's the second copy of all (meta)data to read and restore from if the first is corrupt and fails the integrity check), root itself should be safe, since it was mounted read- only and thus no ongoing writes could have been occurring there when the crash occurred. And of course the btrfs recovery tools are on root, so if worse did come to worse, they should be fine to use in recovering /home, since the root filesystem was read-only the entire period and thus should be undamaged. =;^) Of course in ordered to setup a read-only root, I had to make some changes, including the one under discussion here, making /etc/mtab a symlink to /proc/self/mounts. (Actually, I symlinked it to /proc/mounts, but as mentioned elsewhere in the thread, on a modern kernel since mount namespaces, that's a symlink to /proc/self/mounts already, so same ultimate result.) So I'm all for the change, since that will bring the default gentoo installation one step closer to a read-only root, meaning one less thing for people who want to setup that way to have to worry about. =:^) Meanwhile, the handbook has for years suggested a separate /boot and mentioned the separate /home option. Once we have /etc/mtab as a symlink, the next logical step would be to consider upgrading that separate /home option to suggested default, adding /var/log as a suggested default, and making the default fstab options for / include ro, thus increasing default gentoo system data robustness dramatically. Of course the system-updates/portage discussion would then need a reminder to remount / rw, but with /etc/mtab a symlink, further necessary changes are minor, and it really will improve gentoo system robustness dramatically, likely saving a number of users the headache of having to recover a screwed up root, simply because it was mounted writable and didn't happen to be in a consistent state when the system crashed. (Arguably that should be a (sub-)thread of its own, thus the retitled subthread, already top-level.) -- 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
