Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 04:05:19PM +0100, Matthew Garrett wrote: On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote: another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop) I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc? There is also /root and if you do not have /var on a separate partition, there might be application data on /var or temporary files in /var/tmp or /tmp. Regards Till pgpn9958UfRbk.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 04:50:43PM -0400, seth vidal wrote: On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote: Once upon a time, James Antill ja...@fedoraproject.org said: Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that? On a multi-user server (and that includes web access like PHP or CGI), you really don't want user-writable directories on a filesystem with anything important, especially security-sensitive things like setuid binaries. Hard-link tricks are evil. I run with a separate /tmp (usually tmpfs now) and bind mount it to /var/tmp as well. Not to get too far off into the weeds but Polyinstantianed tmpdir (pam_namespace) are a good idea here. Everyone gets their on /tmp and /var/tmp and no one else can see them. +1 ... we should have had this a long time ago. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Bill Nottingham wrote: Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, and so on were just symlinks to /usr/bin, /usr/lib, and so on. Tru64 (Yes, it's still supported!) does: gho...@seraph ~ % uname -a OSF1 seraph.tetraforge.com V5.1 2650 alpha gho...@seraph ~ % ls -l /bin /lib lrwxr-xr-x 1 root system 7 Apr 21 2010 /bin@ - usr/bin/ lrwxr-xr-x 1 root system 7 Apr 21 2010 /lib@ - usr/lib/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On 10/19/2010 04:13 PM, James Antill wrote: Also, are we sure that people don't want to change any options other than ro (the only thing you can tweak with the bind trick, AIUI)? I thought someone mentioned noatime... I don't really think noatime is as big of a consideration any more, now that we're normally mounting with relatime. -- Peter THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On 19/10/10 14:11, Rawhide Report wrote: anaconda-15.3-1.fc15 * Mon Oct 18 2010 Chris Lumensclum...@redhat.com - 15.3-1 - Don't recommend /usr as a mount point anymore (#643640). (clumens) This despite the FHS says (right at the top of Chapter 3, the Root Filesystem): /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this? Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote: This despite the FHS says (right at the top of Chapter 3, the Root Filesystem): /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this? What's the benefit in having /usr or /opt as separate filesystems? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
2010/10/19 Paul Howarth p...@city-fan.org: http://bugzilla.redhat.com/#626007 Comments are worth reading, I'm sure. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On 19/10/10 15:01, Chris Lumens wrote: This despite the FHS says (right at the top of Chapter 3, the Root Filesystem): /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. Neat. Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this? If you read the entire commit message, you'll see: commit 1ae53648c9e3460eb63837b4c20bc860018979f0 Author: Chris Lumensclum...@redhat.com Date: Mon Oct 18 11:09:36 2010 -0400 Don't recommend /usr as a mount point anymore (#643640). You can still use it if you really want (by inputting it manually), but the Installation Guide recommends against its use. In other words, you can still use any mount point you want. I did read that, which is why I added the reference to Bug #626007 (trimmed from your reply), which is where this change originated from; that is a bug that is being ignored on the basis that /usr is on a separate partition. I'm fine with setting up my own partitioning arrangements but I'd rather not see a system that doesn't work once installed this way. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote: This despite the FHS says (right at the top of Chapter 3, the Root Filesystem): /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this? What's the benefit in having /usr or /opt as separate filesystems? A smaller / that is written to less often is less susceptible to errors. If you don't allocate enough space for / up front, you can move /usr and /opt to separate filesystems later. /opt can be completely unpredictable in space usage, due to vendor RPMs dumping stuff in /opt (see Dell's OMSA, that puts everything, including logs, under /opt). When disk was expensive, /usr was often the biggest consumer of space, so it would be shared across the network, but that's not a big issue anymore (and RPM doesn't really support shared /usr IIRC). I personally don't use a separate /usr on desktops, only on servers. On my servers, /usr is mounted read-only, as an extra protection against accidental (or even intentional) screw-ups. It also means that I don't waste I/O cycles on updating atimes on often-used binaries and libraries (which of course could also be done with noatime). I've seen some boot-from-flash setups with /usr on a hard drive. Basically, if Fedora is going to follow the FHS at all, bugs like 626007 should be fixed, not ignored because somebody doesn't like a separate /usr. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 09:24:10AM -0500, Chris Adams wrote: A smaller / that is written to less often is less susceptible to errors. If you don't allocate enough space for / up front, you can move /usr and /opt to separate filesystems later. /opt can be completely unpredictable in space usage, due to vendor RPMs dumping stuff in /opt (see Dell's OMSA, that puts everything, including logs, under /opt). So, LVM? I personally don't use a separate /usr on desktops, only on servers. On my servers, /usr is mounted read-only, as an extra protection against accidental (or even intentional) screw-ups. It also means that I don't waste I/O cycles on updating atimes on often-used binaries and libraries (which of course could also be done with noatime). mount --bind /usr /usr mount -o ro,remount /usr I've seen some boot-from-flash setups with /usr on a hard drive. The rational thing there is for the flash to be /boot, not /. Basically, if Fedora is going to follow the FHS at all, bugs like 626007 should be fixed, not ignored because somebody doesn't like a separate /usr. I don't think we gain anything from following the FHS on this point other than the ability to have /usr as a separate partition, and think that's a pretty circular argument. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 19.10.10 14:43, Paul Howarth (p...@city-fan.org) wrote: On 19/10/10 14:11, Rawhide Report wrote: anaconda-15.3-1.fc15 * Mon Oct 18 2010 Chris Lumensclum...@redhat.com - 15.3-1 - Don't recommend /usr as a mount point anymore (#643640). (clumens) This despite the FHS says (right at the top of Chapter 3, the Root Filesystem): /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this? During my experimenting with readahead I noticed how many files are actually accessed during early boot that are in /usr. It's a lot more than udisks. It's also everything related to i18n, and a lot other stuff. Already if you run things this way you'll thus have serious functionality limitations. And I see little value in making this work again. Note that many other distributions gave up on seperate /usr already (for example, Gentoo do this, and even refers to Fedora that it wasn't supported here, which is technically true, but so far not officially). I think the whole approach of seperate /usr (which iiuc is done to make /usr r/o during normal runtime) is wrong anyway. It aims too low. If people want to make something r/o it should be the entirety of / read-only, and we probably should make that the default even eventually. That'd be a worthy goal. However, right now there's still a handful of programs that write around in /etc during runtime, such as NM, and stuff related to /etc/nologin, /forcefsck, /etc/mtab, /etc/securetty and similar files. (a couple of which will hopefully go away soonishly. i.e. /etc/nologin is being migrated to /var/run/nologin now, and /forcefsck has a kernel cmdline option forcefsck which is a lot more useful. util-linux-ng is working on getting rid of /etc/mtab and already works mostly when you link it to /proc/mounts. For the securetty hacks I sent a patch last week to PAM.) Debian in fact has been making great progress to make their OS work with read-only root by default: http://wiki.debian.org/ReadonlyRoot Also note that a number of commercial unixes symlink / and /usr these days, going one step further even. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 14:56 +0100, Matthew Garrett wrote: On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote: This despite the FHS says (right at the top of Chapter 3, the Root Filesystem): /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this? What's the benefit in having /usr or /opt as separate filesystems? /opt is a location filled with vendor detritus on a lot of systems - sometimes managed by rpms, sometimes not. It's not uncommon to have /opt automounted via nfs. Additionally, on some workstastion systems /opt is a separate drive managed by the 'local admin' of the machine and filled with whatever 3rd party software they need for their instance. /usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system. Additionally, since our software in fedora has a trickle down impact on users in rhel-land I think you'll find that this will have to be done, eventually for them. Finally, I'm more than a little concerned by the tone of comments in that bug report. It's troubling. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On 10/19/2010 04:37 PM, Lennart Poettering wrote: Note that many other distributions gave up on seperate /usr already (for example, Gentoo do this, and even refers to Fedora that it wasn't supported here, which is technically true, but so far not officially). Where did you get that idea? From Gentoo installation handbook: The number of partitions is highly dependent on your environment. For instance, if you have lots of users, you will most likely want to have your /home separate as it increases security and makes backups easier. If you are installing Gentoo to perform as a mailserver, your /var should be separate as all mails are stored inside /var. A good choice of filesystem will then maximise your performance. Gameservers will have a separate /opt as most gaming servers are installed there. The reason is similar for /home: security and backups. *You will definitely want to keep /usr big*: not only will it contain the majority of applications, the Portage tree alone takes around 500 Mbyte excluding the various sources that are stored in it. Before replying and saying that is just says /usr has to be big. Please read whole http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1chap=4 (part How Many and How Big?) I won't even comment on whole idea of not supporting separate /usr in Fedora...makes me sad. -- Stanislav Ochotnicky sochotni...@redhat.com Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 10:38:13AM -0400, seth vidal wrote: /opt is a location filled with vendor detritus on a lot of systems - sometimes managed by rpms, sometimes not. It's not uncommon to have /opt automounted via nfs. Additionally, on some workstastion systems /opt is a separate drive managed by the 'local admin' of the machine and filled with whatever 3rd party software they need for their instance. /opt being network shared seems like a reasonable thing to support. /usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system. That doesn't require it to be a separate partition. Additionally, since our software in fedora has a trickle down impact on users in rhel-land I think you'll find that this will have to be done, eventually for them. We have to support it because users want it is a poor argument. We have to understand why people want it to be a separate partition and then decide whether the simplest way (in terms of overall engineering effort) to support those desires is by supporting it as a separate partition. So far nobody's come up with a terribly plausible reason for why /usr should be separate. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tuesday, October 19, 2010 15:56:54 Matthew Garrett wrote: On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote: This despite the FHS says (right at the top of Chapter 3, the Root Filesystem): /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this? What's the benefit in having /usr or /opt as separate filesystems? another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote: another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop) I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 16:05 +0100, Matthew Garrett wrote: On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote: another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop) I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc? Yes to both of those. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 11:03:50AM -0400, seth vidal wrote: On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote: /usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system. That doesn't require it to be a separate partition. Mounting the location meaningfully as a readonly does. If you're doing it for security reasons. It doesn't. You can make it a read-only bind mount. We have to support it because users want it is a poor argument. We have to understand why people want it to be a separate partition and then decide whether the simplest way (in terms of overall engineering effort) to support those desires is by supporting it as a separate partition. So far nobody's come up with a terribly plausible reason for why /usr should be separate. I'm confused here - why is it we have to come up with a plausible reason? Why is the burden of proof on KEEPING /usr as a separatable partition? Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase. If I said tomorrow yum will not support feature foo or bar that have been in rpm and yum since the dawn of time I'd have to defend my rationale for that change. If yum removed features that provided functionality that could be achieved via other means, and in return various other features worked better, I'd be fine with that. So it seems like you need to explain why you think /usr should NOT be on a separate partition. Because it adds additional complexity for no obvious gain. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 11:07:24AM -0400, seth vidal wrote: On Tue, 2010-10-19 at 16:05 +0100, Matthew Garrett wrote: On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote: another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop) I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc? Yes to both of those. Well, I don't think people have suggested removing /var as a separate mountpoint. The stuff in /etc is a much more interesting case. Do you have some examples? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 16:11 +0100, Matthew Garrett wrote: On Tue, Oct 19, 2010 at 11:07:24AM -0400, seth vidal wrote: On Tue, 2010-10-19 at 16:05 +0100, Matthew Garrett wrote: On Tue, Oct 19, 2010 at 04:59:29PM +0200, Michal Hlavinka wrote: another benefit (not yet mentioned) is for filesystem encryption. I have / and /home encrypted and /usr not encrypted (for better performance of my laptop) I'm kind of curious about this. What's on / that benefits from being encrypted? Logfiles, some stuff in /etc? Yes to both of those. Well, I don't think people have suggested removing /var as a separate mountpoint. The stuff in /etc is a much more interesting case. Do you have some examples? Password/Shadow files? SSL Certs/SSL Keys for various kinds of daemons or clients. RHN ssl certificates and auth keys? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 16:08 +0100, Matthew Garrett wrote: On Tue, Oct 19, 2010 at 11:03:50AM -0400, seth vidal wrote: On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote: /usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system. That doesn't require it to be a separate partition. Mounting the location meaningfully as a readonly does. If you're doing it for security reasons. It doesn't. You can make it a read-only bind mount. If the files are still read-write at another location then something iterating over disks/locations can still find it. That's what I meant by meaningfully. I'm confused here - why is it we have to come up with a plausible reason? Why is the burden of proof on KEEPING /usr as a separatable partition? Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase. Hmm, So when this was broken a lot of bugs were triggered? Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase. You can't have it both ways. If I said tomorrow yum will not support feature foo or bar that have been in rpm and yum since the dawn of time I'd have to defend my rationale for that change. If yum removed features that provided functionality that could be achieved via other means, and in return various other features worked better, I'd be fine with that. It's not clear to me that other features work better in the case you're describing and it will mean retooling for what sounds like a good number of users. So it seems like you need to explain why you think /usr should NOT be on a separate partition. Because it adds additional complexity for no obvious gain. that's not plausible enough, imo. There is clear gain to enough users to file a 'number of bugs'. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On 10/19/2010 11:15 AM, seth vidal wrote: On Tue, 2010-10-19 at 16:08 +0100, Matthew Garrett wrote: On Tue, Oct 19, 2010 at 11:03:50AM -0400, seth vidal wrote: On Tue, 2010-10-19 at 15:56 +0100, Matthew Garrett wrote: /usr is frequently given different mount options (like noatime, for example) or mounted readonly to prevent unnecessary writes to the system. That doesn't require it to be a separate partition. Mounting the location meaningfully as a readonly does. If you're doing it for security reasons. It doesn't. You can make it a read-only bind mount. If the files are still read-write at another location then something iterating over disks/locations can still find it. That's what I meant by meaningfully. And it's entirely wrong, Seth. They're not at another location in this example. So it seems like you need to explain why you think /usr should NOT be on a separate partition. Because it adds additional complexity for no obvious gain. that's not plausible enough, imo. There is clear gain to enough users to file a 'number of bugs'. Presumably because they don't know about the other ways to accomplish the same goal that aren't as painful to support? -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 11:15:02AM -0400, seth vidal wrote: On Tue, 2010-10-19 at 16:08 +0100, Matthew Garrett wrote: It doesn't. You can make it a read-only bind mount. If the files are still read-write at another location then something iterating over disks/locations can still find it. That's what I meant by meaningfully. So do this at the top of init. It's still better than having /usr be entirely separate. Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase. Hmm, So when this was broken a lot of bugs were triggered? Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase. You can't have it both ways. Very few people do it. When they do, lots of things break. It's kind of like trying to run Fedora under the NetBSD Linux emulation. Nobody does it, but if they did they'd find that a surprising quantity of code wouldn't work. If yum removed features that provided functionality that could be achieved via other means, and in return various other features worked better, I'd be fine with that. It's not clear to me that other features work better in the case you're describing and it will mean retooling for what sounds like a good number of users. Every Fedora update requires significant retooling. The fact that these bugs exist indicates that there would be advantages to not supporting this, providing that in return we can satisfy all the existing user requirements. /usr is a separate partition is *not* a meaningful user requirement, any more than Fedora release names must start with a consonant. If we can provide better and more generalisable solutions for their requirements then that's a win for everyone. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 11:18 -0400, Peter Jones wrote: So it seems like you need to explain why you think /usr should NOT be on a separate partition. Because it adds additional complexity for no obvious gain. that's not plausible enough, imo. There is clear gain to enough users to file a 'number of bugs'. Presumably because they don't know about the other ways to accomplish the same goal that aren't as painful to support? Failure to document and explain to our users the virtues of the changes and the different ways of accomplishing those goals then squarely falls on our shoulders, Peter. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On 10/19/2010 11:22 AM, seth vidal wrote: On Tue, 2010-10-19 at 11:18 -0400, Peter Jones wrote: So it seems like you need to explain why you think /usr should NOT be on a separate partition. Because it adds additional complexity for no obvious gain. that's not plausible enough, imo. There is clear gain to enough users to file a 'number of bugs'. Presumably because they don't know about the other ways to accomplish the same goal that aren't as painful to support? Failure to document and explain to our users the virtues of the changes and the different ways of accomplishing those goals then squarely falls on our shoulders, Peter. Absolutely. -- Peter Hardware simply does not work like the manual says and no amount of Zen contemplation will ever make you at one with a 3c905B ethernet card. -- Alan 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 16:22 +0100, Matthew Garrett wrote: Hmm, So when this was broken a lot of bugs were triggered? Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase. You can't have it both ways. Very few people do it. When they do, lots of things break. It's kind of like trying to run Fedora under the NetBSD Linux emulation. Nobody does it, but if they did they'd find that a surprising quantity of code wouldn't work. you keep asserting this claim - and yet all the evidence in terms of concerned users comes to the contrary. Can you document or backup your assertion? Every Fedora update requires significant retooling. The fact that these bugs exist indicates that there would be advantages to not supporting this, providing that in return we can satisfy all the existing user requirements. /usr is a separate partition is *not* a meaningful user requirement, any more than Fedora release names must start with a consonant. If we can provide better and more generalisable solutions for their requirements then that's a win for everyone. Again - I'm going to ask you to stop making that assertion. You're stating it as an established fact when it is CLEARLY the point in contention. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 19.10.10 16:51, Stanislav Ochotnicky (sochotni...@redhat.com) wrote: On 10/19/2010 04:37 PM, Lennart Poettering wrote: Note that many other distributions gave up on seperate /usr already (for example, Gentoo do this, and even refers to Fedora that it wasn't supported here, which is technically true, but so far not officially). Where did you get that idea? From Gentoo installation handbook: Well, some Gentoo devs involved with integrating systemd on gentoo pointed this out to me. The context was that the systemd tool to initialize the console expects loadkeys to be in /bin, while on Gentoo it is in /usr/bin. And I asked them to unify the location to /bin so that we have less ugly glue code in the systemd build system, and the gentoo folks ultimately refused, saying that seperate /usr wasn't supported anyway. Basically, on gentoo you don't get a correct keymapping before /usr is around, which means you cannot even type your hdd password in properly unless you are a lucky american. There's even a Gentoo bug about this somewhere. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase. And how many of those bugs are exclusively a /usr-is-separate problem vs. how many of them are didn't-anticipate-alternate-partitioning problems? I don't understand how separate /usr can be the sole trigger for all these many bugs. The only type of bug I can see attributed only to separate /usr are bootup requiring things in /usr before non-root filesystems are mounted. I expect other bugs attributed to separate /usr are really problems handling non-default partitioning schemes of many kinds. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On 10/19/2010 11:25 AM, seth vidal wrote: On Tue, 2010-10-19 at 16:22 +0100, Matthew Garrett wrote: Hmm, So when this was broken a lot of bugs were triggered? Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase. You can't have it both ways. Very few people do it. When they do, lots of things break. It's kind of like trying to run Fedora under the NetBSD Linux emulation. Nobody does it, but if they did they'd find that a surprising quantity of code wouldn't work. you keep asserting this claim - and yet all the evidence in terms of concerned users comes to the contrary. Can you document or backup your assertion? This seems like a question smolt should be able to answer... Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 19 Oct 2010, Nathaniel McCallum wrote: On 10/19/2010 11:25 AM, seth vidal wrote: On Tue, 2010-10-19 at 16:22 +0100, Matthew Garrett wrote: Hmm, So when this was broken a lot of bugs were triggered? Sure seems like if a lot of bugs are being triggered then it is NOT a niche usecase. You can't have it both ways. Very few people do it. When they do, lots of things break. It's kind of like trying to run Fedora under the NetBSD Linux emulation. Nobody does it, but if they did they'd find that a surprising quantity of code wouldn't work. you keep asserting this claim - and yet all the evidence in terms of concerned users comes to the contrary. Can you document or backup your assertion? This seems like a question smolt should be able to answer... This is what is currently in the wild for /usr: mysql select mnt_pnt,count(*) as cnt from file_systems where mnt_pnt like '/usr%' group by mnt_pnt order by cnt; +---+---+ | mnt_pnt | cnt | +---+---+ | /usr/share/dict | 1 | | /usr/src/debug| 1 | | /usr/tmp | 1 | | /usr/share/icons | 1 | | /usr/local/sbin | 1 | | /usr/sbin | 2 | | /usr/include | 2 | | /usr/src/packages | 3 | | /usr/local/bin| 5 | | /usr/X11R6| 6 | | /usr/local/share | 9 | | /usr/bin |11 | | /usr/share/doc|14 | | /usr/games|16 | | /usr/lib64|30 | | /usr/local/src|33 | | /usr/lib |41 | | /usr/local/games |43 | | /usr/share| 163 | | /usr/src | 329 | | /usr/local| 12814 | | /usr | 37171 | +---+---+ 22 rows in set (3.25 sec) This is out of 1,702,459 submissions of profiles that included filesystem data. So about 3% of users have something mounted in /usr and about 2.2% have /usr mounted directly. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On 10/19/2010 01:01 PM, Matthew Miller wrote: On Tue, Oct 19, 2010 at 11:43:49AM -0500, Mike McGrath wrote: This is out of 1,702,459 submissions of profiles that included filesystem data. So about 3% of users have something mounted in /usr and about 2.2% have /usr mounted directly. Given that you have to go out of your way to do it, that's a pretty significant number. Yes and no - I'm curious as to how this number will change without anaconda recommending that it's a thing you might want to do. I think there's a sizeable contention that creates mountpoints out of habbit, not any specific need or requirement, and it only stands to reason that some people must be choosing which ones to create based on the list in front of them. It'll be interesting to see how that number changes once we no longer have it on anaconda's list - that should show us how many people actually have a specific desire for /usr to be separate. That is - Chris's anaconda change may allow us to collect data on just how many people /usr being separate is *actually* important to. We still won't know why, though. -- Peter Power corrupts. Absolute power is kind of neat. -- John Lehman, Secretary of the Navy, 1981-1987 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On 10/19/2010 11:28 AM, Chris Adams wrote: Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: Because it takes more engineering effort to keep it as a separate partition, as evidenced by the number of bugs that keep appearing that are only triggered by this niche usecase. And how many of those bugs are exclusively a /usr-is-separate problem vs. how many of them are didn't-anticipate-alternate-partitioning problems? If I understand your distinction correctly, then the overwhelming majority of them are the former. I don't understand how separate /usr can be the sole trigger for all these many bugs. The only type of bug I can see attributed only to separate /usr are bootup requiring things in /usr before non-root filesystems are mounted. And that's exactly what gets hit over and over. I expect other bugs attributed to separate /usr are really problems handling non-default partitioning schemes of many kinds. There aren't a lot of other bugs about it. -- Peter Power corrupts. Absolute power is kind of neat. -- John Lehman, Secretary of the Navy, 1981-1987 01234567890123456789012345678901234567890123456789012345678901234567890123456789 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Le mardi 19 octobre 2010 à 14:56 +0100, Matthew Garrett a écrit : On Tue, Oct 19, 2010 at 02:43:33PM +0100, Paul Howarth wrote: This despite the FHS says (right at the top of Chapter 3, the Root Filesystem): /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. Do we *really* want to head this way, ignoring bugs resulting from having /usr on a different partition such as http://bugzilla.redhat.com/#626007, which is what led to this? What's the benefit in having /usr or /opt as separate filesystems? When one actually uses /opt, it really wants to be on a separate filesystem, so you can dump huge (gigs of binaries and other data) proprietary software there without polluting the (sane) base system It matters a lot when you have simple backup procedures for the base system that explode if you accidentally scope Oracle/SAP/IBM bloatware. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 11:12 -0400, seth vidal wrote: Well, I don't think people have suggested removing /var as a separate mountpoint. The stuff in /etc is a much more interesting case. Do you have some examples? Password/Shadow files? SSL Certs/SSL Keys for various kinds of daemons or clients. RHN ssl certificates and auth keys? wifi keys, VPN passwords... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Once upon a time, Peter Jones pjo...@redhat.com said:
On 10/19/2010 11:28 AM, Chris Adams wrote:
And how many of those bugs are exclusively a /usr-is-separate problem
vs. how many of them are didn't-anticipate-alternate-partitioning
problems?
If I understand your distinction correctly, then the overwhelming majority
of them are the former.
The one that led to this discussion (626007) doesn't seem to be.
The /usr/sbin/foo is needed before FSes are mounted is a fairly
trivial problem to solve in the majority of cases; I don't see that as a
big deal.
If separate /usr isn't considered a valid configuration, why do we have
separate /bin, /sbin, /lib{,64}?
--
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/19/2010 11:25 AM, Chris Adams wrote:
If separate /usr isn't considered a valid configuration, why do we have
separate /bin, /sbin, /lib{,64}?
Today it isn't necessarily valid. Things do progress, and the reasons
for separate /usr back in the day may be more easily solvable without an
actual separate /usr. As for /bin vs /usr/bin and lib vs /usr/lib these
are all fallout from making /usr/ a separate system, fallout that can
be removed and complexity that can be reduced.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAky968wACgkQ4v2HLvE71NUa/wCggTz/5YZrOPa7jREiOUNhj3qq
t10AoLPF4xB57wzjMbEWh3MOFZMnYom0
=87Ch
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 16:11 +0100, Matthew Garrett wrote: Well, I don't think people have suggested removing /var as a separate mountpoint. The stuff in /etc is a much more interesting case. Do you have some examples? So first off, I personally don't care if /usr is allowed to be separate or not (though breaking the FHS on a whim seems a tad excessive) ... but I don't see how /var is significantly different. udisks (why I'm reading this thread at all) certainly looks like it needs /var to be mounted. Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that? Also, are we sure that people don't want to change any options other than ro (the only thing you can tweak with the bind trick, AIUI)? I thought someone mentioned noatime... -- James Antill - ja...@fedoraproject.org ... so the consumable rawhide is likely not to get as many updates as its users would like to have. -- Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: rawhide report: 20101019 changes
-Original Message- From: devel-boun...@lists.fedoraproject.org [mailto:devel-boun...@lists.fedoraproject.org] On Behalf Of Lennart Poettering Sent: Tuesday, October 19, 2010 7:38 AM To: Development discussions related to Fedora Subject: Re: rawhide report: 20101019 changes I think the whole approach of seperate /usr (which iiuc is done to make /usr r/o during normal runtime) is wrong anyway. It aims too low. If people want to make something r/o it should be the entirety of / read-only, and we probably should make that the default even eventually. That'd be a worthy goal. However, right now there's still a handful of programs that write around in /etc during runtime, such as NM, and stuff related to /etc/nologin, /forcefsck, /etc/mtab, /etc/securetty and similar files. (a couple of which will hopefully go away soonishly. i.e. /etc/nologin is being migrated to /var/run/nologin now, and /forcefsck has a kernel cmdline option forcefsck which is a lot more useful. util-linux-ng is working on getting rid of /etc/mtab and already works mostly when you link it to /proc/mounts. For the securetty hacks I sent a patch last week to PAM.) Debian in fact has been making great progress to make their OS work with read-only root by default: http://wiki.debian.org/ReadonlyRoot Also note that a number of commercial unixes symlink / and /usr these days, going one step further even. Lennart A ton of this work was already done in initscripts through the use of the /etc/sysconfig/readonly-root hooks. Isn't that already working well enough now for that purpose, future systemd changes aside? -jc -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Once upon a time, James Antill ja...@fedoraproject.org said: Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that? On a multi-user server (and that includes web access like PHP or CGI), you really don't want user-writable directories on a filesystem with anything important, especially security-sensitive things like setuid binaries. Hard-link tricks are evil. I run with a separate /tmp (usually tmpfs now) and bind mount it to /var/tmp as well. You generally don't want logs (which are indirectly user-writable) on a filesystem with other system-critical things, as it leaves you open to DoS. This is really separate from / vs. /usr though, as neither should have directly or indirectly user-writable files (assuming separate /tmp and /var). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote: Once upon a time, James Antill ja...@fedoraproject.org said: Putting my really old sysadmin hat on, one other reason for having /tmp, /var and /usr as separate mount points was so that you could allocate different disk space to each (and they couldn't break each other) ... do we have other solutions for that? On a multi-user server (and that includes web access like PHP or CGI), you really don't want user-writable directories on a filesystem with anything important, especially security-sensitive things like setuid binaries. Hard-link tricks are evil. I run with a separate /tmp (usually tmpfs now) and bind mount it to /var/tmp as well. Not to get too far off into the weeds but Polyinstantianed tmpdir (pam_namespace) are a good idea here. Everyone gets their on /tmp and /var/tmp and no one else can see them. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Peter Jones (pjo...@redhat.com) said: Because we haven't decided to merge those together. That's really the only reason - there's no over-arching technical reason they need to be separate. It's entirely a historical consideration. Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, and so on were just symlinks to /usr/bin, /usr/lib, and so on. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Cleaver, Japheth (jclea...@soe.sony.com) said: A ton of this work was already done in initscripts through the use of the /etc/sysconfig/readonly-root hooks. Isn't that already working well enough now for that purpose, future systemd changes aside? Given that it involves bind-mounting *files* in some cases (which imparts some truly odd semantics that confuse programs), it's not quite enough for generalizing to any use. It certainly can be made to work, though. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
Once upon a time, Bill Nottingham nott...@redhat.com said: Peter Jones (pjo...@redhat.com) said: Because we haven't decided to merge those together. That's really the only reason - there's no over-arching technical reason they need to be separate. It's entirely a historical consideration. Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, and so on were just symlinks to /usr/bin, /usr/lib, and so on. On Tru64 (aka Digital Unix aka OSF/1 aka ...), /bin is a symlink to /usr/bin, and /lib to /usr/lib (but shared libraries are in /shlib and /usr/shlib, and they are separate; the lib directory is primarily for compiling). All the stuff needed for early booting is in /sbin (separate from /usr/sbin). I don't even think you can install with /usr (or /var) on the same filesystem as /. However, with AdvFS, the root file domain is special (with extra restrictions due to the bootloader and other things), so you really don't want anything else in there. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tue, Oct 19, 2010 at 19:58, Bill Nottingham nott...@redhat.com wrote: Peter Jones (pjo...@redhat.com) said: Because we haven't decided to merge those together. That's really the only reason - there's no over-arching technical reason they need to be separate. It's entirely a historical consideration. Somewhere in the recesses of my memory I remember a UNIX where /bin, /lib, and so on were just symlinks to /usr/bin, /usr/lib, and so on. There were several depending on how it was implemented. The Convex I remember having a minimal /etc and /bin and then mounting the real ones later in the boot but really in /usr/etc, /usr/bin etc. The OSF/1 systems I think did it with symlinks. But out of the weeds.. the big areas I know were using separate /usr with Fedora were disk-less systems. The /usr , /opt and some other items were NFS mounted from a central system. It was mostly a relic of how Sun had done it in the good old days but no one had come up with a better 'supported' way and so it was still in use til quite recently. /usr ends up being mounted separate mostly for business case reasons. The compliance documents say /usr on all systems in some place must be a seperate partition and until they get updated that is how it will be. On other areas it is separated out because the business software requires it or it won't install. [Yes brain dead but it is what it is.] Neither of those are really in Fedora's sphere since it is more of a cutting edge versus practical OS. [Yes that is a dig.. I am allowed one per year.] If we are going to 'break' FHS, let us do it in a large way versus a death by a thousand cuts. Change the directory names to something like: /configurations /vendor-binaries /vendor-data /user-stuff or any of the other proposals over the years to make things more intuitive in a 21st century way :). -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20101019 changes
On Tuesday 19 October 2010, Cleaver, Japheth wrote: A ton of this work was already done in initscripts through the use of the /etc/sysconfig/readonly-root hooks. Isn't that already working well enough now for that purpose, future systemd changes aside? Not sure if it's directly related to this discussion, but for what I'd like to use it for [0] there's one essential piece missing, persisting temporary state back to disk: https://bugzilla.redhat.com/show_bug.cgi?id=223722 [0] To keep rotational disks spun down as much as possible and avoiding writes on cheap flash devices that can't take that much writing in the long run. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
