Re: deprecating /usr as a standalone filesystem?
On Wednesday 06 May 2009 03:39:40 Steve Langasek wrote: On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). This is false for Ubuntu. Not only is it supported, but significant effort was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as pertains to wpasupplicant. Are the same changes (moving of runtime libs wpasupplicant uses to /lib) likely to be handed back to Debian? The same /usr-as-separate-mount bug is likely to strike iw and crda as well as it did wpasupplicant. Thanks, Kel.
Re: deprecating /usr as a standalone filesystem?
On Mon, May 18, 2009 at 06:25:07AM +1000, Kel Modderman wrote: On Wednesday 06 May 2009 03:39:40 Steve Langasek wrote: On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). This is false for Ubuntu. Not only is it supported, but significant effort was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as pertains to wpasupplicant. Are the same changes (moving of runtime libs wpasupplicant uses to /lib) likely to be handed back to Debian? That would be the goal, but of course there are more maintainers who need to be coordinated with in the case of Debian so there's no telling how much longer it will take to get all the changes in. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Marco d'Itri wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). BTW, last month Lennart Poettering began a discussion on fedora-devel-list about deprecating /usr completely, i.e. symlinking it to /: https://www.redhat.com/archives/fedora-devel-list/2009-April/msg01063.html It seems that most of the arguments on that thread against that change were but we won't be able to mount /usr separately that way!. I'm no Fedora expert, but it sounds like it is actually a supported configuration in Fedora. Regards, Faidon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote: it is the principle of the thing. /root is the home directory for the root user. Home directories are mutable, programs may store configuration files there, as may the user, by themselves. The root user should not be more constrained than other users on the machine are; making wirking as root irritating, less customizable, and harder does not help the end user admin any. Ideally, we should map /root somewhere persistent, writable, and also a location available in single user mode; and there are few pleasing solutions that meet that criteria; though less than perfect solutions exist. I fail to see how root is different to any other random user in this regard. If you want / to be read-only, then you should ensure that /home points to something writable. The same thing holds for /root. You can make /home and /root to be separate filesystems, or bind mounts or symlinks pointing to a writable location. If you can handle /home today then you can also handle /root exactly the same way. So the only thing to do is ensure that whatever code/documentation talks about /home should also talk about/handle /root as well. In fact, if / is supposed to be read-only, then I see absolutely no reason to use /root instead of /home/root. Maybe we need an option in the installer to set root's HOME directory to /home/root instead of /root? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Gabor Gombas wrote: On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote: it is the principle of the thing. /root is the home directory for the root user. Home directories are mutable, programs may store configuration files there, as may the user, by themselves. The root user should not be more constrained than other users on the machine are; making wirking as root irritating, less customizable, and harder does not help the end user admin any. Ideally, we should map /root somewhere persistent, writable, and also a location available in single user mode; and there are few pleasing solutions that meet that criteria; though less than perfect solutions exist. I fail to see how root is different to any other random user in this regard. If you want / to be read-only, then you should ensure that /home points to something writable. The same thing holds for /root. You can make /home and /root to be separate filesystems, or bind mounts or symlinks pointing to a writable location. If you can handle /home today then you can also handle /root exactly the same way. No, /root cannot be a separate filesystem. /root is part of very basic system, and it is required for super user when he/she is restoring the systems or doing some kind of administration (e.g. moving filesystems, etc.). Now with live CDw this is less relevant then in the past. OTOH usually sulogin will login (as super user) when / is still read-only, so basic tools (in /bin and /sbin) should works also on read-only /root. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Do den 14. Mai 2009 um 14:01 schrieb Gabor Gombas: I fail to see how root is different to any other random user in this regard. If you want / to be read-only, then you should ensure that /home points to something writable. The same thing holds for /root. That is not always true. root _is_ special as it might be needed in single user mode or in emergency mode. There might also software very early in the boot process that need a writable root-$HOME. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen kl...@ethgen.de Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSgwcWJ+OKpjRpO3lAQre9wf/XQ8A35N0aoaGi0D05c5qVtFbG7fMeI9t 9HOhV4YVTJT0QBkuJGnDBHvx8ZXCMggjjY/xRXe4k8XetwAbg2cm2ZAk4L8KOT5B vuwFxalyjmtt9XF6yegTPo5PfJtyPKRci8VqgeEzkTte0DYrlEyzMiA8rK+IdImz xm3rv7dpZ+AT1hjPwSHqWS0LVdZ9wbjFoWwYLaIikgJY9J018NHjeFNGTXvv9IeS LZ/JGa6QT9zvakUQlWUQDpctivSZbyE3mvDWKHIY0NxWUXiASw9hccbGqluS011M KW+6Y3j5F3fnZGkeVk/iWPCoRq5Pb9+Dm+kqI9mr09/0ciu/h5fU7A== =jKwZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote: Gabor Gombas wrote: On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote: it is the principle of the thing. /root is the home directory for the root user. Home directories are mutable, programs may store configuration files there, as may the user, by themselves. The root user should not be more constrained than other users on the machine are; making wirking as root irritating, less customizable, and harder does not help the end user admin any. Ideally, we should map /root somewhere persistent, writable, and also a location available in single user mode; and there are few pleasing solutions that meet that criteria; though less than perfect solutions exist. I fail to see how root is different to any other random user in this regard. If you want / to be read-only, then you should ensure that /home points to something writable. The same thing holds for /root. You can make /home and /root to be separate filesystems, or bind mounts or symlinks pointing to a writable location. If you can handle /home today then you can also handle /root exactly the same way. No, /root cannot be a separate filesystem. /root is part of very basic system, and it is required for super user when he/she is restoring the systems or doing some kind of administration (e.g. moving filesystems, etc.). Why do these tasks require a writable (or even present) /root? -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote: No, /root cannot be a separate filesystem. /root is part of very basic system, and it is required for super user when he/she is restoring the systems or doing some kind of administration (e.g. moving filesystems, etc.). Obviously not. If fscking / fails then / _will_ be read-only and you _must_ be able to fix it without being able to write under /root, so any system restoration task must work without /root being writeable. If you want to write to /root, then _make_ it writable! That's why you are the system administrator after all. If you want / to be read-only, then move /root to some other filesystem. If you want /root to be on the same filesystem as /, then do not make / read-only. Really, this is a Doctor, it hurts if I shoot myself in the foot - Don't do it, then kind of situation... Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Roger Leigh wrote: On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote: Gabor Gombas wrote: On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote: it is the principle of the thing. /root is the home directory for the root user. Home directories are mutable, programs may store configuration files there, as may the user, by themselves. The root user should not be more constrained than other users on the machine are; making wirking as root irritating, less customizable, and harder does not help the end user admin any. Ideally, we should map /root somewhere persistent, writable, and also a location available in single user mode; and there are few pleasing solutions that meet that criteria; though less than perfect solutions exist. I fail to see how root is different to any other random user in this regard. If you want / to be read-only, then you should ensure that /home points to something writable. The same thing holds for /root. You can make /home and /root to be separate filesystems, or bind mounts or symlinks pointing to a writable location. If you can handle /home today then you can also handle /root exactly the same way. No, /root cannot be a separate filesystem. /root is part of very basic system, and it is required for super user when he/she is restoring the systems or doing some kind of administration (e.g. moving filesystems, etc.). Why do these tasks require a writable (or even present) /root? Interesting question. I think none, but: - FHS - someone pointed they would like .bash_history (but this is a sysadmin preference), - On my system I've data from aptitude, vim, less, mc , but I think I these program can works also without root (BTW all in /usr) - mysql puts admin password in /root , so maybe it is required to to mysql maintenance (I expect: existence, but shoudl be ok for read-only) - ssh/scp: not sure, (but they are in /usr) ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Gabor Gombas wrote: On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote: No, /root cannot be a separate filesystem. /root is part of very basic system, and it is required for super user when he/she is restoring the systems or doing some kind of administration (e.g. moving filesystems, etc.). Obviously not. If fscking / fails then / _will_ be read-only and you _must_ be able to fix it without being able to write under /root, so any system restoration task must work without /root being writeable. If you want to write to /root, then _make_ it writable! That's why you are the system administrator after all. If you want / to be read-only, then move /root to some other filesystem. If you want /root to be on the same filesystem as /, then do not make / read-only. Really, this is a Doctor, it hurts if I shoot myself in the foot - Don't do it, then kind of situation... I totally agree that / (thus /root) could be read-only. I pointed out to you that /root is required to be in the same filesystem as / (FHS) and I gave you the rationale. I really prefer to allow / and /root read-only than to allow /root in a different filesystem (user could do also this choice, but outside debian support cases). ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Thu, May 14, 2009 at 04:21:53PM +0200, Giacomo A. Catenazzi wrote: I totally agree that / (thus /root) could be read-only. I pointed out to you that /root is required to be in the same filesystem as / (FHS) and I gave you the rationale. What's the FHS says is a little different: /root : Home directory for the root user (optional) Purpose The root account's home directory may be determined by developer or local preference, but this is the recommended default location. So the presence of /root is not required and root's home directory can be set to /home/root by the installer if a read-only / is wanted. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Gabor Gombas wrote: On Thu, May 14, 2009 at 04:21:53PM +0200, Giacomo A. Catenazzi wrote: I totally agree that / (thus /root) could be read-only. I pointed out to you that /root is required to be in the same filesystem as / (FHS) and I gave you the rationale. What's the FHS says is a little different: /root : Home directory for the root user (optional) Purpose The root account's home directory may be determined by developer or local preference, but this is the recommended default location. So the presence of /root is not required and root's home directory can be set to /home/root by the installer if a read-only / is wanted. Yes, you are right, and the optional is very nice! I was confusing with the following note (and maybe an older version): If the home directory of the root account is not stored on the root partition it will be necessary to make certain it will default to / if it can not be located. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Thu, May 14, 2009 at 02:27:52PM +0100, Klaus Ethgen wrote: There might also software very early in the boot process that need a writable root-$HOME. Nonsense. Any such software needs to be beaten severely. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Thu, May 14 2009, Gabor Gombas wrote: On Wed, May 13, 2009 at 12:38:45PM -0500, Manoj Srivastava wrote: it is the principle of the thing. /root is the home directory for the root user. Home directories are mutable, programs may store configuration files there, as may the user, by themselves. The root user should not be more constrained than other users on the machine are; making wirking as root irritating, less customizable, and harder does not help the end user admin any. Ideally, we should map /root somewhere persistent, writable, and also a location available in single user mode; and there are few pleasing solutions that meet that criteria; though less than perfect solutions exist. I fail to see how root is different to any other random user in this regard. If you want / to be read-only, then you should ensure that /home points to something writable. The same thing holds for /root. You can make /home and /root to be separate filesystems, or bind mounts or symlinks pointing to a writable location. If you can handle /home today then you can also handle /root exactly the same way. So the only thing to do is ensure that whatever code/documentation talks about /home should also talk about/handle /root as well. In fact, if / is supposed to be read-only, then I see absolutely no reason to use /root instead of /home/root. Maybe we need an option in the installer to set root's HOME directory to /home/root instead of /root? Sure. I can hack things so that I have a writable home directory for root while having a read only /. But then it is incorrect to state that it works out of the box. manoj -- The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Giacomo A. Catenazzi c...@debian.org writes: Gabor Gombas wrote: On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote: No, /root cannot be a separate filesystem. /root is part of very basic system, and it is required for super user when he/she is restoring the systems or doing some kind of administration (e.g. moving filesystems, etc.). Obviously not. If fscking / fails then / _will_ be read-only and you _must_ be able to fix it without being able to write under /root, so any system restoration task must work without /root being writeable. If you want to write to /root, then _make_ it writable! That's why you are the system administrator after all. If you want / to be read-only, then move /root to some other filesystem. If you want /root to be on the same filesystem as /, then do not make / read-only. Really, this is a Doctor, it hurts if I shoot myself in the foot - Don't do it, then kind of situation... I totally agree that / (thus /root) could be read-only. I pointed out to you that /root is required to be in the same filesystem as / (FHS) and I gave you the rationale. I really prefer to allow / and /root read-only than to allow /root in a different filesystem (user could do also this choice, but outside debian support cases). ciao cate There is absolutely no reason why you can not mount a filesystem over /root later in the boot process. I agree that /root should/must exist at all time so one can login when for example fsck fails. But that works perfectly fine with /root being an empty directory on / and later having a filesystem mounted there. So I would be against /home/root, as one would have to create that on / before /home gets mounted so it is always available. That kind of shadowed directory is harder to create for DI and wouldn't show up in a backup and be missing after a restore. I would rather bind mount /home/root to /root to make /root read-write. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Manoj Srivastava sriva...@debian.org writes: Sure. I can hack things so that I have a writable home directory for root while having a read only /. But then it is incorrect to state that it works out of the box. manoj If you have a read-only / you need to have /var and /home as seperate filesystem. Requireing to have /root seperate as well is no different. That is still out of the box for me. Also I don't consider writing to /root normal. Works out of the box for normal operations if you will. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Fri, May 15, 2009 at 07:12:59AM +0200, Goswin von Brederlow wrote: There is absolutely no reason why you can not mount a filesystem over /root later in the boot process. I agree that /root should/must exist at all time so one can login when for example fsck fails. No, you must be able to log in even if /root have ended up in /lost+found. Anything that relies on the existence of /root is bogus and should be fixed. Note 17 in the FHS (that Giaocomo already quoted) specifies how the system should handle the case when root's home cannot be located - it must just work. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, May 12 2009, Goswin von Brederlow wrote: I don't know if there are more blocker. Oh, and /root is a home directory; unless we move that, a read only / would affect root negatively. How so? Only thing I can think of is the bash history. But it is not like we force a read-only /. That is a choice. it is the principle of the thing. /root is the home directory for the root user. Home directories are mutable, programs may store configuration files there, as may the user, by themselves. The root user should not be more constrained than other users on the machine are; making wirking as root irritating, less customizable, and harder does not help the end user admin any. Ideally, we should map /root somewhere persistent, writable, and also a location available in single user mode; and there are few pleasing solutions that meet that criteria; though less than perfect solutions exist. manoj -- Success is relative: It is what we can make of the mess we have made of things. T.S. Eliot, The Family Reunion Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Manoj Srivastava sriva...@debian.org writes: On Tue, May 12 2009, Goswin von Brederlow wrote: I don't know if there are more blocker. Oh, and /root is a home directory; unless we move that, a read only / would affect root negatively. How so? Only thing I can think of is the bash history. But it is not like we force a read-only /. That is a choice. it is the principle of the thing. /root is the home directory for the root user. Home directories are mutable, programs may store configuration files there, as may the user, by themselves. The root user should not be more constrained than other users on the machine are; making wirking as root irritating, less customizable, and harder does not help the end user admin any. Ideally, we should map /root somewhere persistent, writable, and also a location available in single user mode; and there are few pleasing solutions that meet that criteria; though less than perfect solutions exist. manoj You can always (bind) mount something on /root. If you want read-only / but can't live with read-only /root then that is the way to go. Alternatively you can change roots hoomedir or create a toor user with id 0 and /home/toor or something. I for my part don't work as root making use of sudo where required. Never felt a great need to use /root. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Manoj Srivastava sriva...@debian.org writes: On Mon, May 11 2009, Goswin von Brederlow wrote: Henrique de Moraes Holschuh h...@debian.org writes: On Mon, 11 May 2009, Goswin von Brederlow wrote: A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). A read-only / does the trick just as well. And if you don't want writes to /usr you probably don't want writes to /bin or /sbin either. So read-only / is really the way to go. Not a strong argument for a seperate /usr. No, RO / is a lot more difficult to pull off (remember: some of us don't want initrds), while RO /usr is really just a three-char change on fstab (and if you want apt to remount things automatically, two lines in a config file). Why would you need an initrd for a read-only /? A read-only / should work out of the box just like a read-only /usr. I Except it does not. I said should. :) Last I set one up it still needed some assembly but that is being worked on. It is certainly within reach for Squeeze. haven't installed a fresh one in a long while though so if you know of problems speak up so bugs can be filed and packages can be fixed. There is the /etc/mtab issue, and then there are things like resolvconf that try to scribble in /etc. I have not tried recently, so The /etc/mtab problem is finaly solved for all cases (like quota users) with kernel 2.6.26. There is a bug report about it and that is hopefully soon to be made to work out of the box. No assembly required then anymore. Resolvconf uses /lib/init/rw so that isn't a stoper anymore. ifup/down has some code for read-only / in it too. I don't know if there are more blocker. Oh, and /root is a home directory; unless we move that, a read only / would affect root negatively. How so? Only thing I can think of is the bash history. But it is not like we force a read-only /. That is a choice. A read-only / would be nice, but unless you try it on a real box, I don't think you assert it should be working out of the box. I'm sure there are some packages out there that still don't work right with read-only /. But none I use and thuse none I know about. As far as I know the /etc/mtab issue is the last pending thing. manoj MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Mon, May 11, 2009 at 12:32:40AM -0400, Daniel Dickinson wrote: On Tue, 5 May 2009 17:36:02 +0200 m...@linux.it (Marco d'Itri) wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? You can lvm resize a standalone /usr by booting single user (I've done it when my /usr got too small). You know you can do all that online nowadays? Just lvmresize and resize2fs (or the equivalent) while it's mounted; no single user mode required. -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Mon, 11 May 2009, Goswin von Brederlow wrote: A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). A read-only / does the trick just as well. And if you don't want writes to /usr you probably don't want writes to /bin or /sbin either. So read-only / is really the way to go. Not a strong argument for a seperate /usr. No, RO / is a lot more difficult to pull off (remember: some of us don't want initrds), while RO /usr is really just a three-char change on fstab (and if you want apt to remount things automatically, two lines in a config file). The other mount options like nodev or having a different filesystem type for /usr are stronger reasons. They're extra reasons, and strong ones at that, yes. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Henrique de Moraes Holschuh h...@debian.org writes: On Mon, 11 May 2009, Goswin von Brederlow wrote: A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). A read-only / does the trick just as well. And if you don't want writes to /usr you probably don't want writes to /bin or /sbin either. So read-only / is really the way to go. Not a strong argument for a seperate /usr. No, RO / is a lot more difficult to pull off (remember: some of us don't want initrds), while RO /usr is really just a three-char change on fstab (and if you want apt to remount things automatically, two lines in a config file). Why would you need an initrd for a read-only /? A read-only / should work out of the box just like a read-only /usr. I haven't installed a fresh one in a long while though so if you know of problems speak up so bugs can be filed and packages can be fixed. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Mon, 11 May 2009, Goswin von Brederlow wrote: A read-only / should work out of the box just like a read-only /usr. I haven't installed a fresh one in a long while though so if you know of problems speak up so bugs can be filed and packages can be fixed. Last time I tried it, /etc was a problem. I'd have to retry doing it, and frankly, I do not have the time to muck with that right now. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Mon, May 11, 2009 at 09:59:36AM -0300, Henrique de Moraes Holschuh wrote: On Mon, 11 May 2009, Goswin von Brederlow wrote: A read-only / should work out of the box just like a read-only /usr. I haven't installed a fresh one in a long while though so if you know of problems speak up so bugs can be filed and packages can be fixed. Last time I tried it, /etc was a problem. I'd have to retry doing it, and frankly, I do not have the time to muck with that right now. #494001 is the main blocker. It's just waiting for the patch to be applied AFAICT. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Mon, May 11 2009, Goswin von Brederlow wrote: Henrique de Moraes Holschuh h...@debian.org writes: On Mon, 11 May 2009, Goswin von Brederlow wrote: A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). A read-only / does the trick just as well. And if you don't want writes to /usr you probably don't want writes to /bin or /sbin either. So read-only / is really the way to go. Not a strong argument for a seperate /usr. No, RO / is a lot more difficult to pull off (remember: some of us don't want initrds), while RO /usr is really just a three-char change on fstab (and if you want apt to remount things automatically, two lines in a config file). Why would you need an initrd for a read-only /? A read-only / should work out of the box just like a read-only /usr. I Except it does not. haven't installed a fresh one in a long while though so if you know of problems speak up so bugs can be filed and packages can be fixed. There is the /etc/mtab issue, and then there are things like resolvconf that try to scribble in /etc. I have not tried recently, so I don't know if there are more blocker. Oh, and /root is a home directory; unless we move that, a read only / would affect root negatively. A read-only / would be nice, but unless you try it on a real box, I don't think you assert it should be working out of the box. manoj -- Vendi, vidi, parenthesi -- I came, I saw, I programmed in Lisp! Dave W. Kimball Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Mon, May 11, 2009 at 09:20:44AM -0500, Manoj Srivastava wrote: On Mon, May 11 2009, Goswin von Brederlow wrote: Henrique de Moraes Holschuh h...@debian.org writes: On Mon, 11 May 2009, Goswin von Brederlow wrote: A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). A read-only / does the trick just as well. And if you don't want writes to /usr you probably don't want writes to /bin or /sbin either. So read-only / is really the way to go. Not a strong argument for a seperate /usr. No, RO / is a lot more difficult to pull off (remember: some of us don't want initrds), while RO /usr is really just a three-char change on fstab (and if you want apt to remount things automatically, two lines in a config file). Why would you need an initrd for a read-only /? A read-only / should work out of the box just like a read-only /usr. I Except it does not. haven't installed a fresh one in a long while though so if you know of problems speak up so bugs can be filed and packages can be fixed. There is the /etc/mtab issue, and then there are things like resolvconf that try to scribble in /etc. I have not tried recently, so I don't know if there are more blocker. resolvconf uses /lib/init/rw nowadays, so no /etc writing is needed. There's a patch for /etc/mtab elimination; it's totally unneeded nowadays. There may be a few other minor issues, but a read-only root is well in reach for Squeeze if people try it out and report any remaining cases. -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Mon, May 11, 2009 at 04:38:59PM +0100, Roger Leigh rle...@codelibre.net wrote: There's a patch for /etc/mtab elimination; it's totally unneeded nowadays. More than unneeded, it is absolutely irrelevant when using mount namespaces. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Roger Leigh rle...@codelibre.net writes: On Mon, May 11, 2009 at 09:59:36AM -0300, Henrique de Moraes Holschuh wrote: On Mon, 11 May 2009, Goswin von Brederlow wrote: A read-only / should work out of the box just like a read-only /usr. I haven't installed a fresh one in a long while though so if you know of problems speak up so bugs can be filed and packages can be fixed. Last time I tried it, /etc was a problem. I'd have to retry doing it, and frankly, I do not have the time to muck with that right now. #494001 is the main blocker. It's just waiting for the patch to be applied AFAICT. Ok, that one doesn't work out of the box but is easily rectified by the admin. But it has been known a long time and is finaly fixable. Should have said unknown bugs. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Fri, 08 May 2009, David Weinehall wrote: No. But we do leave /usr read-only the rest of the time, which is often 99.999% of the time. A separate /usr is required for this. Uhm, no? mount --bind /usr /usr First, you'd need a RO bind mount (yes, it exists, but your command doesn't do it). Second, the filesystem is still RW, so it gains you very little as far as data safety goes. A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Sun, May 10, 2009 at 08:51:33AM -0300, Henrique de Moraes Holschuh wrote: On Fri, 08 May 2009, David Weinehall wrote: No. But we do leave /usr read-only the rest of the time, which is often 99.999% of the time. A separate /usr is required for this. Uhm, no? mount --bind /usr /usr First, you'd need a RO bind mount (yes, it exists, but your command doesn't do it). Second, the filesystem is still RW, so it gains you very little as far as data safety goes. That's because you neatly trimmed off the rest of my message, which was: Should do the trick (the same mount -o remount,rw / remount,ro then applies). all thanks to the magic of subtrees :) A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). I'm not opposing this, and I definitely don't support Marco's idea. I just pointed out that a separate filesystem isn't required to make a mountpoint read-only. Regards: David -- /) David Weinehall t...@debian.org /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, 5 May 2009 17:36:02 +0200 m...@linux.it (Marco d'Itri) wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? If you do, please provide a detailed real-world use case. A partial list of invalid reasons is: - I heard that this was popular in 1998 - it's a longstanding tradition to support this - it's really useful on my 386 SX with a 40 MB hard disk This thread has been going on for quite some time without any insight into what the actual problem with a separate /usr might be. Could you please elaborate? The only issues I can think of are hard links and atomic renames. Though I can't think of any use-case where you would need this between /usr and some place outside /usr. Cheers, harry signature.asc Description: PGP signature
Re: deprecating /usr as a standalone filesystem?
Henrique de Moraes Holschuh h...@debian.org writes: On Fri, 08 May 2009, David Weinehall wrote: No. But we do leave /usr read-only the rest of the time, which is often 99.999% of the time. A separate /usr is required for this. Uhm, no? mount --bind /usr /usr First, you'd need a RO bind mount (yes, it exists, but your command doesn't do it). Second, the filesystem is still RW, so it gains you very little as far as data safety goes. A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). A read-only / does the trick just as well. And if you don't want writes to /usr you probably don't want writes to /bin or /sbin either. So read-only / is really the way to go. Not a strong argument for a seperate /usr. The other mount options like nodev or having a different filesystem type for /usr are stronger reasons. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, 5 May 2009 17:36:02 +0200 m...@linux.it (Marco d'Itri) wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? You can lvm resize a standalone /usr by booting single user (I've done it when my /usr got too small). In addition getting rid of a standalone /usr will break existing configurations. It would break mine, for instance, because I partitioned my hard drive based on the knowledge that /usr could be a separate filesystem. What about nfs-served /usr? Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com signature.asc Description: PGP signature
Re: deprecating /usr as a standalone filesystem?
On Thu, May 07, 2009 at 07:27:08PM -0500, Manoj Srivastava wrote:
On Thu, May 07 2009, Ben Finney wrote:
Manoj Srivastava sriva...@debian.org writes:
On Thu, May 07 2009, Josselin Mouette wrote:
Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
Those who want a read-only ‘/usr’ don't seriously try to leave it
read-only while installing or upgrading packages, do they?
,[ Excerpt from /etc/apt/apt.conf ]
| DPkg
| {
|// Auto re-mounting of a readonly /usr
|Pre-Invoke {mount -o remount,rw /usr;};
|Post-Invoke {mount -o remount,ro /usr;};
| };
`
Exactly. So this is *not* “leave /usr read-only while installing or
upgrading packages”. Thanks for providing another case in point.
No. But we do leave /usr read-only the rest of the time, which
is often 99.999% of the time. A separate /usr is required for this.
Uhm, no?
mount --bind /usr /usr
Should do the trick (the same mount -o remount,rw / remount,ro then
applies). all thanks to the magic of subtrees :)
Regards: David
--
/) David Weinehall t...@debian.org /) Rime on my window (\
// ~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Fri, 08 May 2009, David Weinehall wrote: On Thu, May 07, 2009 at 07:27:08PM -0500, Manoj Srivastava wrote: No. But we do leave /usr read-only the rest of the time, which is often 99.999% of the time. A separate /usr is required for this. Uhm, no? mount --bind /usr /usr Should do the trick (the same mount -o remount,rw / remount,ro then applies). all thanks to the magic of subtrees :) Yeah. Right. wea...@intrepid:~/tmp$ mkdir foo wea...@intrepid:~/tmp$ touch foo/bar wea...@intrepid:~/tmp$ sudo mount -o bind,ro foo foo wea...@intrepid:~/tmp$ touch foo/baz wea...@intrepid:~/tmp$ bind mounts don't do ro. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Fri, 08 May 2009, Peter Palfrader wrote: wea...@intrepid:~/tmp$ mkdir foo wea...@intrepid:~/tmp$ touch foo/bar wea...@intrepid:~/tmp$ sudo mount -o bind,ro foo foo wea...@intrepid:~/tmp$ touch foo/baz wea...@intrepid:~/tmp$ bind mounts don't do ro. I have been told, that starting with 2.6.26 they do. But only *iff* the ro is done with a remount after the initial bind mounting. How very not useful. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On 08 May 14:35, Peter Palfrader wrote: On Fri, 08 May 2009, David Weinehall wrote: On Thu, May 07, 2009 at 07:27:08PM -0500, Manoj Srivastava wrote: No. But we do leave /usr read-only the rest of the time, which is often 99.999% of the time. A separate /usr is required for this. Uhm, no? mount --bind /usr /usr Should do the trick (the same mount -o remount,rw / remount,ro then applies). all thanks to the magic of subtrees :) Yeah. Right. wea...@intrepid:~/tmp$ mkdir foo wea...@intrepid:~/tmp$ touch foo/bar wea...@intrepid:~/tmp$ sudo mount -o bind,ro foo foo wea...@intrepid:~/tmp$ touch foo/baz wea...@intrepid:~/tmp$ bind mounts don't do ro. http://lwn.net/Articles/281157/ As of 2.6.26 it's possible, but still not right: fleur:/tmp# rmdir foo fleur:/tmp# mkdir foo fleur:/tmp# touch foo/blah fleur:/tmp# mount -o bind foo foo fleur:/tmp# mount -o remount,ro foo fleur:/tmp# touch foo/blah touch: cannot touch `foo/blah': Read-only file system fleur:/tmp# umount foo fleur:/tmp# touch foo/blah fleur:/tmp# So it works, just not quite as you'd expect :/ Cheers, -- Brett Parker -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
m...@linux.it (Marco d'Itri) writes: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? If you do, please provide a detailed real-world use case. A partial list of invalid reasons is: - I heard that this was popular in 1998 - it's a longstanding tradition to support this - it's really useful on my 386 SX with a 40 MB hard disk -- ciao, Marco Home case: / is a small raid1 that is directly booted into without initramfs /usr is on lvm on raid5 Without a seperate /usr this would require the use of an initramfs and seperate /boot partition or much more space. Work case: / is an initramfs /usr is shared over network for many hosts Useability reasons: - If fsck repairs anything while checking / the system has to reboot. All other filesystems can just continue. By splitting / and /usr there is less of a chance of / needing repair saving the reboot. - Fsck for / is run first and then other filesystems can run in parallel. - Less chance of filesystem corruption on / if /usr is another filesystem. That also means I can still boot even when /usr is damaged and then try to repair it. - / is small and relatively constant while /usr grows all the time. With / outside LVM it can be booted directly and /usr inside LVM allows easy resize when more space is needed. - / contains data that might need to be encrypted (/etc) while /usr can be left plain for more speed/less cpu usage. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Roger Leigh rle...@codelibre.net writes: On Tue, May 05, 2009 at 06:49:47PM +0200, Josselin Mouette wrote: Le mardi 05 mai 2009 à 17:24 +0100, Roger Leigh a écrit : That might have been a traditional reason for a shared /usr. However, the package manager can't cope with this setup since you have some components of a package installed locally and some remotely for all systems using the shared part. It's an impossible situation to actually cater for in real life. Has anyone ever actually *done* this? Of course, you just need to think the image you actually update as a master image, after which it is replicated by any means necessary (be it systemimager or NFS). Sure, but you effectively only have one master image. You don't have multiple users of /usr with differing /etc or /var. They are all kept in sync. This kind of makes /usr redundant since it is sharable but only among identical systems or else you will run into problems. The important part would be that a small / is replicated across all hosts. Possibly automatically on boot whenever it changed. The large /usr on the other hand is exported via NFS. This keeps the amount of data being replicated small. As for NFS, Iâd use root NFS instead of complicating my life with two different methods for / and /usr, but I guess some are doing it this way. On the compute cluster I helped set up for biological modelling, we opted to use Debian Live images on the cluster. It IIRC NFS mounts a read-only cramfs filesystem and uses aufs on top of that. There's just the one big filesystem (plus some site-specific mounts for shared data and a big scratch area all the nodes can access). We certainly saw no point in making just /usr mountable since you need a matching rootfs to accompany it. I have a setup with unionfs-fuse for xen/kvm instances here. I have one master tree that every instance mounts read-only and unionfs-fuse overlays a read-write branch from server:/srv/rw/ip/. But just like you I don't need a seperate /usr for that. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Giacomo Catenazzi c...@debian.org writes: Roger Leigh wrote: On Tue, May 05, 2009 at 05:41:06PM +0200, Stéphane Glondu wrote: Marco d'Itri a écrit : I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. A partial list of invalid reasons is: [...] How about: my /usr is shared by many machines over NFS? That might have been a traditional reason for a shared /usr. However, the package manager can't cope with this setup since you have some components of a package installed locally and some remotely for all systems using the shared part. It's an impossible situation to actually cater for in real life. Has anyone ever actually *done* this? So why we created /usr/share (and moved documentation) ? .oO(preparing for Multiarch support :) I see a lot of parallel installed system, so in this case I see no problem on sharing /usr. [BTW one of the most important conference is not LISA, about such configurations?] But also I don't think it is a problem sharing usr on multiple system with multiple configurations. On non public working stations, one doesn't run randomly programs. If I installed mysql-server on a system, it will work on such system, but if I install on an other system, it work also on the other system, occupying only one instance. I don't see problem from package management (also because we have a nullpotent dpkg), so we can upgrade from multiple system without problems. apt-get install libmysqlclient16 apt-get remove --purge libmysqlclient16 and suddenly your other system has a broken mysql-server. With your setup you can only install packages savely but not remove them. Which one can decide to live with. Looking at GNU/Hurd, /usr is a symlink to /. If we were to make /usr non-separable, maybe this would be the way to go. or plan9, which bind mount all /*/bin into the main /bin. I can live with such solution, but please allow us to use /usr in a different (maybe shared) partition. ciao cate MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem? [386 support]
Josselin Mouette j...@debian.org writes: Le mardi 05 mai 2009 à 23:38 +0200, Frank Lin PIAT a écrit : Interesting. I thought 386 wasn't supported anymore (?) AFAIK the kernel is able to emulate a 486 when running on a 386. Afaik only when properly patched to do so and including glibc patches. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Stefano Zacchiroli z...@debian.org writes: On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote: So, does anybody still see reasons to continue supporting a standalone /usr? There had been lots of responses to that. Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. On the NFS server you install a full system in a chroot (or run it as xen/kvm/... instace for maintainance). On clients during boot you run rsync -avPSHx --exclude-from=host-files server:chroot/ / The host-files lists some files in /etc/ and /var and also /usr and /home and other directories you NFS mount. Of course the problem is that if you update on the NFS server, then related /etc and /var files [1] will not get updated on the NFS client machines and you need to propagate changes there. I see as quite pointless to use let's export /usr via NFS as an argument, if Debian does not provide a way to make that setup tenable. ACK. There is really not much point in having / local. It is easy enough to use nfs-root and overlay a host specific /etc and /var. People might just not be used to it. Networking is not a good argument why /usr must be kept seperate. Stick to the other reasons mentioned. ACK on your second clarification request, though. Cheers. [1] Or anything else actually, given that maintainer scripts can affect basically all the filesystem. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
So, does anybody still see reasons to continue supporting a standalone /usr? There had been lots of responses to that. You havent presented any supporting your request, so why do you want it? Please provide a detailed real-world case. A partial list of invalid reasons is: - Some upstream wont fix his software to be FHS compatible As there is still not a single response from the original proposer as to why this should be done, I think this is a dead issue. If not even the proposer cares enough to present some real world use cases why one wants to do it, why should Debian at a whole care? -- bye, Joerg liw I'm kinky and perverse, but my illness is laziness -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit : Those who want a read-only ‘/usr’ don't seriously try to leave it read-only while installing or upgrading packages, do they? But with RPM this works! -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: deprecating /usr as a standalone filesystem?
This one time, at band camp, Josselin Mouette said: Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit : Those who want a read-only ‘/usr’ don't seriously try to leave it read-only while installing or upgrading packages, do they? But with RPM this works! If that is the case, that's about the only thing that works with RPM. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
Stephen Gran wrote: This one time, at band camp, Josselin Mouette said: Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit : Those who want a read-only ‘/usr’ don't seriously try to leave it read-only while installing or upgrading packages, do they? But with RPM this works! If that is the case, that's about the only thing that works with RPM. *works* ? I don't think this is a feature. IMHO the right thing is like debian: admins explicitly add hook to remount partition rw, before installing package. I don't like that by default a package management will override mount options. Or I missed what RPM do with read-only partitions? ciao cate PS: moving to d-curiosa? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Le jeudi 07 mai 2009 à 09:37 +0200, Giacomo A. Catenazzi a écrit : Stephen Gran wrote: But with RPM this works! If that is the case, that's about the only thing that works with RPM. Or I missed what RPM do with read-only partitions? Next time I’ll add the irony tags. There has been a discussion some time ago about RPM updating the database and marking the package as upgraded while nothing had changed on the filesystem because it is mounted read-only. I don’t know whether this has been fixed in RPM since then. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: deprecating /usr as a standalone filesystem?
On Thu, 07 May 2009, Ben Finney wrote: Those who want a read-only ???/usr??? don't seriously try to leave it read-only while installing or upgrading packages, do they? No. And we hook apt to automatically remount stuff rw before it, and try to remount ro after. It is easy, it works *perfectly*, and it has done so for longer than I care to remember. When the ro remount fails, you know you have some checkrestart work to do to get all updates in core, so it has helped our security upgrade team as well, even if their procedure sheet already tells them to check for old processes and libraries anyway. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, 5 May 2009, Russ Allbery wrote: Stefano Zacchiroli z...@debian.org writes: Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. It's not particularly difficult. You update the system master and push that update into NFS, synchronizing any non-/usr data as you need to across all the systems mounting that NFS partition. If you don't want to take downtime, you have two chroots on the NFS server and pivot systems back and forth between the two chroots as you do updates. I have parts of /usr and /var shared via NFS and use cfengine to push/pull related updates to /etc and other non-shared locations. cfengine will keep the non-shared portions synchronized, and restart services when their config files are updated. People did and still do this all the time with AFS. It's pretty well-established how to make it work. 'Tis a little harder now with my servers being split betwixt i686 and amd64 machines (db format differs, so I had to use inn peering, not shared spool, etc). I personally don't care any more because hard drives have gotten a lot bigger, but it's technically quite feasible. Yes, but I see this as an management of space/time/etc trade-off. For me the big items for standalone /usr are mentioned elsewhere - I tend to have a separate /boot and put everthing else in a (encrypted for laptops) LVM where resizing/moving/backup/security/etc all argure for independant partitions. I see as quite pointless to use let's export /usr via NFS as an argument, if Debian does not provide a way to make that setup tenable. Certainly looks tenable right now to me. Indeed, tenable - and working -- Rick Nelson miguel `You have been unsubscribed from the high energy personal protection devices mailing list' miguel I dont remember getting into the mailing list -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Thu, May 07 2009, Josselin Mouette wrote:
Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
Those who want a read-only ‘/usr’ don't seriously try to leave it
read-only while installing or upgrading packages, do they?
,[ Excerpt from /etc/apt/apt.conf ]
| DPkg
| {
|// Auto re-mounting of a readonly /usr
|Pre-Invoke {mount -o remount,rw /usr;};
|Post-Invoke {mount -o remount,ro /usr;};
| };
`
manoj
--
The rule on staying alive as a program manager is to give 'em a number
or give 'em a date, but never give 'em both at once.
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Manoj Srivastava sriva...@debian.org writes:
On Thu, May 07 2009, Josselin Mouette wrote:
Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
Those who want a read-only ‘/usr’ don't seriously try to leave it
read-only while installing or upgrading packages, do they?
,[ Excerpt from /etc/apt/apt.conf ]
| DPkg
| {
|// Auto re-mounting of a readonly /usr
|Pre-Invoke {mount -o remount,rw /usr;};
|Post-Invoke {mount -o remount,ro /usr;};
| };
`
Exactly. So this is *not* “leave /usr read-only while installing or
upgrading packages”. Thanks for providing another case in point.
--
\ “Some forms of reality are so horrible we refuse to face them, |
`\ unless we are trapped into it by comedy. To label any subject |
_o__)unsuitable for comedy is to admit defeat.” —Peter Sellers |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Thu, May 07 2009, Ben Finney wrote:
Manoj Srivastava sriva...@debian.org writes:
On Thu, May 07 2009, Josselin Mouette wrote:
Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
Those who want a read-only ‘/usr’ don't seriously try to leave it
read-only while installing or upgrading packages, do they?
,[ Excerpt from /etc/apt/apt.conf ]
| DPkg
| {
|// Auto re-mounting of a readonly /usr
|Pre-Invoke {mount -o remount,rw /usr;};
|Post-Invoke {mount -o remount,ro /usr;};
| };
`
Exactly. So this is *not* “leave /usr read-only while installing or
upgrading packages”. Thanks for providing another case in point.
No. But we do leave /usr read-only the rest of the time, which
is often 99.999% of the time. A separate /usr is required for this.
manoj
--
A complex system that works is invariably found to have evolved from a
simple system that worked. -- John Gall, _Systemantics_
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Ben Finney wrote:
Manoj Srivastava sriva...@debian.org writes:
On Thu, May 07 2009, Josselin Mouette wrote:
Le jeudi 07 mai 2009 à 11:02 +1000, Ben Finney a écrit :
Those who want a read-only ‘/usr’ don't seriously try to leave it
read-only while installing or upgrading packages, do they?
,[ Excerpt from /etc/apt/apt.conf ]
| DPkg
| {
|// Auto re-mounting of a readonly /usr
|Pre-Invoke {mount -o remount,rw /usr;};
|Post-Invoke {mount -o remount,ro /usr;};
| };
`
Exactly. So this is *not* “leave /usr read-only while installing or
upgrading packages”. Thanks for providing another case in point.
Sometime I wonder on which kind of list I'm subscribed.
ciao
cate
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Stefano Zacchiroli wrote: On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote: So, does anybody still see reasons to continue supporting a standalone /usr? There had been lots of responses to that. Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. Of course the problem is that if you update on the NFS server, then related /etc and /var files [1] will not get updated on the NFS client machines and you need to propagate changes there. I see as quite pointless to use let's export /usr via NFS as an argument, if Debian does not provide a way to make that setup tenable. 8-/ I really don't see the problems, and BTW debian provide also some tools. - On large parallel systems, people use something more than a base debian console installation. Usually on net you have a complete copy for root, var etc (in case of compromised computers. Very handy instead of reinstalling the system) So it is easier also to have a rsync script (without some dirs) And on infrequent security update where data format change, let sysadmin implement a tool to update such numberous systems. But such case is seldom. I really think that *most* debian machines are done in this way (because such systemns have huge number of debian machine, and debian is a very good distribution for such setups) - on homemade systems, Debian provide tools like apt-cron and other automatic update tools, which solve all problems (if one use only one distribution [like stable]). Also in this case, heuristic tell me that when we requires removing of a package, it is because it is substituted by an other, so no problems (when all systems are updated nearly at the same nightly time). It seems not a usual case that sysadmins remove packages from a single machine. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Giacomo Catenazzi c...@debian.org writes: - On large parallel systems, people use something more than a base debian console installation. Usually on net you have a complete copy for root, var etc (in case of compromised computers. Very handy instead of reinstalling the system) So it is easier also to have a rsync script (without some dirs) And on infrequent security update where data format change, let sysadmin implement a tool to update such numberous systems. But such case is seldom. I really think that *most* debian machines are done in this way (because such systemns have huge number of debian machine, and debian is a very good distribution for such setups) I think it's pretty unlikely that *most* Debian machines are done that way. There are a lot better tools for keeping large numbers of systems in sync these days than simple cloning from golden images, and a lot of drawbacks to the golden image approach. Also, reinstalling systems is completely trivial if you have a decent FAI infrastructure. It takes us about ten minutes to rebuild a server and reinstall all application software, and that's mostly waiting for the system BIOS boot-up checks and the small amount of manual keying we've not bothered to automate yet. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Well, some people argued for that. Like you, I'm wondering how one actually does this in practice! However there are some rather more reasonable uses which have been mentioned: - read-only /usr (for security) - backups - recovery (ability to mount root only; important if there's fs corruption) - on-line resizing - using LVM and/or RAID (Note: With modern Debian initramfs it is quite possible to have / on LVM [on RAID] since so long as /boot lives outside the initramfs can bring up RAID and initialise LVM to mount the rootfs. The system I'm physically typing this on has such a setup.) I keep a /usr because I suspect it gives more performance. unlike the rest of the disk, one doesn't read and write it all the time, so fragmentation should be less if it is kept separate. one can also use a filesystem type more suitable for this behaviour (reiserfs is probably not optimal) /Johan -- -- Johan Henriksson MSc Engineering PhD student, Karolinska Institutet http://mahogny.areta.org http://www.endrov.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem? [/usr on NFS]
On Tue, 2009-05-05 at 16:25 -0700, Russ Allbery wrote: Stefano Zacchiroli z...@debian.org writes: Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. It's not particularly difficult. You update the system master and push that update into NFS, synchronizing any non-/usr data as you need to across all the systems mounting that NFS partition. I have always been skeptical about sharing /usr on Debian, especially I've always wondered is how you upgrade the remote (nfs-mounted) systems? * How to upgrade /bin, /lib... files? * Can dpkg be told to not touch /usr on those machines? * Some (pre|post)(inst|rm) scripts use files in /usr... Aren't they guaranteed to behave in unpredictable way, if the version is /usr aren't the one expected by those scripts? I used lessdisk[1] in sarge, but it used to export the whole tree over NFS. Regards, Franklin P.S. I like the idea to use encrypted partition for the whole system, excepts /usr. [1] http://archive.debian.net/sarge/lessdisks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem? [/usr on NFS]
Frank Lin PIAT fp...@klabs.be writes: On Tue, 2009-05-05 at 16:25 -0700, Russ Allbery wrote: It's not particularly difficult. You update the system master and push that update into NFS, synchronizing any non-/usr data as you need to across all the systems mounting that NFS partition. I have always been skeptical about sharing /usr on Debian, especially I've always wondered is how you upgrade the remote (nfs-mounted) systems? * How to upgrade /bin, /lib... files? * Can dpkg be told to not touch /usr on those machines? * Some (pre|post)(inst|rm) scripts use files in /usr... Aren't they guaranteed to behave in unpredictable way, if the version is /usr aren't the one expected by those scripts? I think it would be fairly difficult without using a golden image approach, where there's one system (or chroot on an NFS server) that you upgrade and then push the non-/usr results to all the systems mounting /usr. Doing that is fairly straightforward, though. Don't get me wrong: I don't do this, nor do I have any plans to do this. Disk is too cheap to bother and there are better ways of keeping systems in sync these days, IMO. But it's a very long-standing sysadmin technique, I wouldn't be surprised if some people still use it, and it's certainly technically doable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 12:30:14AM +0200, Stefano Zacchiroli wrote: Of course the problem is that if you update on the NFS server, then related /etc and /var files [1] will not get updated on the NFS client machines and you need to propagate changes there. One thing to remember is when you export /usr (or /) over NFS, then you usually do not expect to install new software often (maybe once or twice a year), and security updates rarely bring big changes under /etc or /var. /etc can be managed with a couple of scripts; if you have a non-trivial amount of machines you already have the scripts to populate and customize it for a new machine. After an update, you just re-run that script for all the clients and you're done. /var is not an issue either. You can mount it read-only just like /usr and then you can mount some tmpfs instances over the locations where write access is really needed. /etc/fstab fragment: tmpfs /tmptmpfs size=100m,mode=1777 0 0 /tmp/var/tmpbindbind0 0 tmpfs /var/logtmpfs size=10m0 0 tmpfs /var/lib/gdmtmpfs size=10m0 0 tmpfs /var/lib/xkbtmpfs size=10m0 0 tmpfs /var/lib/nfstmpfs size=10m0 0 tmpfs /var/cache/hald tmpfs size=10m0 0 tmpfs /media tmpfs size=128k 0 0 You of course need a couple of mkdir/chown commands in an init script to create some required subdirectories. If you need persistence, then you mount a writable FS somewhere else, and you do something like mount --bind /home/terem/boinc-client/$HOSTNAME /var/lib/boinc-client (that's from a running cluster setup). If I take a look of what is actually under /var on that cluster, then I get: nfs-server# du -s . 147300 . nfs-server# du -s cache lib/apt lib/aptitude lib/dpkg log [...] 135616 total So even if you want a local /var on every machine, you can ignore over 92% of the data when you synchronize with say rsync (you can actually ignore even more, but then the above du -s line would have been too long). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Le mardi 05 mai 2009 à 16:25 -0700, Russ Allbery a écrit : It's not particularly difficult. You update the system master and push that update into NFS, synchronizing any non-/usr data as you need to across all the systems mounting that NFS partition. Sure, but what is the point of doing that instead of exporting / over NFS ? Remember, we support read-only root partition setups now. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: deprecating /usr as a standalone filesystem?
Le mardi 05 mai 2009 à 23:15 -0700, Russ Allbery a écrit : I think it's pretty unlikely that *most* Debian machines are done that way. There are a lot better tools for keeping large numbers of systems in sync these days than simple cloning from golden images, and a lot of drawbacks to the golden image approach. You’d be surprised to see the number of HPC people who are wasting their time with golden images. And the even larger number of HPC people who don’t even have an automated node deployment mechanism. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: deprecating /usr as a standalone filesystem?
On 2009-05-06, Russ Allbery r...@debian.org wrote: Giacomo Catenazzi c...@debian.org writes: - On large parallel systems, people use something more than a base debian console installation. Usually on net you have a complete copy for root, var etc (in case of compromised computers. Very handy instead of reinstalling the system) So it is easier also to have a rsync script (without some dirs) And on infrequent security update where data format change, let sysadmin implement a tool to update such numberous systems. But such case is seldom. I really think that *most* debian machines are done in this way (because such systemns have huge number of debian machine, and debian is a very good distribution for such setups) I think it's pretty unlikely that *most* Debian machines are done that way. There are a lot better tools for keeping large numbers of systems in sync these days than simple cloning from golden images, and a lot of drawbacks to the golden image approach. We do the same with ~12 clients. One master image that's declared stable by rsyncing it using hardlinks[0] on the server and from there rsynced to the clients which reboot automatically if there are pending updates. After the rsyncing it does local profile-based patching. I wonder about the drawbacks of this because it works really nice for us. (Of course there's the downtime problem, but that's no problem for us, as those are clients not servers.) Sadly rsync still does too much I/O on the servers in our setup, but if that gets a problem we'll probably go with aufs and have an image on the client which remainds static there. Also, reinstalling systems is completely trivial if you have a decent FAI infrastructure. It takes us about ten minutes to rebuild a server and reinstall all application software, and that's mostly waiting for the system BIOS boot-up checks and the small amount of manual keying we've not bothered to automate yet. But why bother to do a complete reinstall everytime something changed if you could just sync the delta. (And yes, I'm roughly aware that there are something like softupdates in FAI too, but still.) Kind regards, Philipp Kern [0] Actually there's one test image and the stable images are hardlinked within themselves, so that changes in the test image do not propagate to the stable images. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Em Qua, 2009-05-06 às 00:30 +0200, Stefano Zacchiroli escreveu: On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote: So, does anybody still see reasons to continue supporting a standalone /usr? There had been lots of responses to that. Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. Simple. You have a single /usr shared-mounted for several instances and a a / for each machine. Then you run the upgrade in one of those images and do the following: 1 - use a script to extract files not in /usr in that packages and install it in each root mount 2 - use a script to change the dpkg database in each root mount telling that the packages were unpacked but not configured. 3 - run dpkg --configure -a in each root mount to get the maint scripts to be run... 4 - profit daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On May 05, Steve Langasek vor...@debian.org wrote: This is false for Ubuntu. Not only is it supported, but significant effort was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as pertains to wpasupplicant. You may want to discuss this with Keybuk then, because he still disagrees. -- ciao, Marco signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 09:38:39AM -0300, Daniel Ruoso wrote:
Simple.
sarcasm
Sure, that's precisely what I'd call being properly supported in
Debian.
/sarcasm
In particular, from the replies to my question the picture I get is
that everybody is using ad hoc solutions to implement what some people
are pretending to be properly supported by Debian. I found it not
defendable, maybe it's just me, maybe it's just bad marketing.
Of the two one:
- We decide that mounting /usr remotely is a Debian goal.
If we do so, the mechanisms to make it work should not be as ad hoc
as this thread as hinted. We should provide a package explicitly
made to make this workflow tenable and point our users to it.
- We decide that if you want to mount /usr remotely you are on your
own.
If we do so, we should stop using mount /usr remotely as an
argument for keeping /usr as a single filesystem.
A few side notes:
* various people replying to my request mentioned that in such a
setup, you are not expected to upgrade too often the machine
exporting /usr
* everybody overlooked the subtle theoretical problem that our
maintainer scripts can potentially do *everything* on the file
system and *everywhere*, and that they are written in a Turing
complete language (shell script). This means that you cannot, in the
general case discover what they have touched. As a consequence you
can not simply rely on the dpkg database to know what you have to
propagate.
The trick of fiddling the dpkg database on the client machine and
then run dpkg --configure -a there is indeed nice. But again,
requesting our users to do that, potentially messing up with the
dpkg database, is IMO not something we can call being properly
supported in Debian. If it is supposed to work that way, we have to
provide higher level tools that do that for our users.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
Stefano Zacchiroli wrote: On Wed, May 06, 2009 at 09:38:39AM -0300, Daniel Ruoso wrote: Simple. sarcasm Sure, that's precisely what I'd call being properly supported in Debian. /sarcasm In particular, from the replies to my question the picture I get is that everybody is using ad hoc solutions to implement what some people are pretending to be properly supported by Debian. I found it not defendable, maybe it's just me, maybe it's just bad marketing. But system administration is per definition ad hoc solution. This is our power. Why we give sources? Also to allow us to tweak debian. Debian is a distribution, not a complete solution. I think we have a different idea of what is debian. Of the two one: - We decide that mounting /usr remotely is a Debian goal. If we do so, the mechanisms to make it work should not be as ad hoc as this thread as hinted. We should provide a package explicitly made to make this workflow tenable and point our users to it. - We decide that if you want to mount /usr remotely you are on your own. If we do so, we should stop using mount /usr remotely as an argument for keeping /usr as a single filesystem. But you are still selling us vapor! We still don't understand the problem! Was this a topic of last meeting of the Italian cabal? What is the problem: - remote /usr not supported? - /usr in a different partition ? - union mount could solve this? we cannot discuss without knowing the real problem! ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, 06 May 2009, Stefano Zacchiroli wrote: Of the two one: - We decide that mounting /usr remotely is a Debian goal. If we do so, the mechanisms to make it work should not be as ad hoc as this thread as hinted. We should provide a package explicitly made to make this workflow tenable and point our users to it. If we were limited by what debian (and d-i) can do out of the box this would be a sad world. And it'd make most software and Debian pretty useless in a lot of cases. It's kind of the job of a sysadmin to take what Debian (or any other vendor) gives them and integrate this into an environment that fulfill's the local requirements. The level of support that Debian provides for mounting remote /usr filesystems is apparently just fine or at least sufficient for the kind of user that makes use of it. Just don't break crap that has worked for years for no other reason than I want to. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Stefano Zacchiroli wrote: A few side notes: * everybody overlooked the subtle theoretical problem that our maintainer scripts can potentially do *everything* on the file system and *everywhere*, and that they are written in a Turing complete language (shell script). This means that you cannot, in the general case discover what they have touched. As a consequence you can not simply rely on the dpkg database to know what you have to propagate. But package installation is nullpotent. You can install again on every system. You still have one /usr, but right data in other places. Is it so important a consistent database? Things will still work. Remember that our policy require not to hardcore paths, so that a sysadmin can overwrite program using /usr/local. This means indirectly that what it is in database and what it is installed doesn't need to be consistent with what it is really used. And I don't understand why the dpkg database MUST be accurate. dpkg is smart enough to do the right things anyways. The trick of fiddling the dpkg database on the client machine and then run dpkg --configure -a there is indeed nice. But again, requesting our users to do that, potentially messing up with the dpkg database, is IMO not something we can call being properly supported in Debian. If it is supposed to work that way, we have to provide higher level tools that do that for our users. I agree that we must not support (helping users) such systems (but usually they have good sysadmins), but I find stupid to make life harder to such sysadmins. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
[Stefano Zacchiroli] The trick of fiddling the dpkg database on the client machine and then run dpkg --configure -a there is indeed nice. But again, requesting our users to do that, potentially messing up with the dpkg database, is IMO not something we can call being properly supported in Debian. If it is supposed to work that way, we have to provide higher level tools that do that for our users. Also, this procedure would be much more reliable if we said, in Policy, that maintainer scripts are not allowed to fail if /usr is not writable. (mount -o ro, SELinux, chattr +i, NFS root_squash, whatever.) Would you support that policy? I suspect ldconfig would have to be patched in some way. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 03:06:34PM +0200, Giacomo A. Catenazzi wrote:
But system administration is per definition ad hoc solution.
This is our power. Why we give sources? Also to allow us
to tweak debian.
This is a utterly poor argument.
I can easily twist it against you by saying why we give binaries?
We can just offer sources, system administrators will be able to
compile them.
A distribution is about integration of unrelated softwares and is
about making easier / more manageable tasks for various kind of users,
including system administrators.
Debian is a distribution, not a complete solution.
I think we have a different idea of what is debian.
Maybe we have.
Was this a topic of last meeting of the Italian cabal?
Is there anything useful in raising the Italian cabal here? The fact
I'm Italian has nothing to do with my arguments, pretty much as your
nationality has nothing to do with yours.
Or else add smileys if it was meant to be a joke.
But you are still selling us vapor!
We still don't understand the problem!
Anyhow, *you* don't understand the problem and you are probably the
only one thinking I'm selling vapor. From other people's replies I
conclude that the problem is quite clear and my vapor was so concrete
that others hinted at technical solutions. But let me spell the
problem out for you, as you are raising the tone of the discussion
with exclamation marks (which was not my intention).
The problem is that our package manager (dpkg) assumes it is in charge
of files which reside on different top-level FHS directories: /usr,
/var, /boot, /bin, /sbin, /lib, /lib64, ...
In a scenario where /usr is remotely exported for NFS mounting, if you
use dpkg on the exporting machine, client machines will get out of
sync. Some files need to be copied over statically and, more
interestingly, maintainer scripts will need to be re-run on client
machines to deliver their side effects to all machines. Also the
status of the dpkg database need to be synced with clients.
My argument is mainly that we should not ask our user to do the above
sync by hand, still claiming we support it.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
Stefano Zacchiroli wrote: On Wed, May 06, 2009 at 03:06:34PM +0200, Giacomo A. Catenazzi wrote: But system administration is per definition ad hoc solution. This is our power. Why we give sources? Also to allow us to tweak debian. This is a utterly poor argument. I can easily twist it against you by saying why we give binaries? We can just offer sources, system administrators will be able to compile them. I said *also*. 10 years ago this was a real argument: use Linux because you can adapt to your local needs. I never installed a Debian system, which is 100% Debian. It always have some of my personality. For this case I mean: I don't think we should support directly, but we should allow our sysadmin to tweak /usr Was this a topic of last meeting of the Italian cabal? Is there anything useful in raising the Italian cabal here? The fact I'm Italian has nothing to do with my arguments, pretty much as your nationality has nothing to do with yours. Or else add smileys if it was meant to be a joke. sorry! Yes, it was meant as a joke. But you are still selling us vapor! We still don't understand the problem! Anyhow, *you* don't understand the problem and you are probably the only one thinking I'm selling vapor. From other people's replies I conclude that the problem is quite clear and my vapor was so concrete that others hinted at technical solutions. But let me spell the problem out for you, as you are raising the tone of the discussion with exclamation marks (which was not my intention). The problem is that our package manager (dpkg) assumes it is in charge of files which reside on different top-level FHS directories: /usr, /var, /boot, /bin, /sbin, /lib, /lib64, ... In a scenario where /usr is remotely exported for NFS mounting, if you use dpkg on the exporting machine, client machines will get out of sync. Some files need to be copied over statically and, more interestingly, maintainer scripts will need to be re-run on client machines to deliver their side effects to all machines. Also the status of the dpkg database need to be synced with clients. No. So I think also you did not understand the real problem. The /usr in NFS is one interpretation, but I really think it was not the original problem. Such ad hoc methods was never supported. [BTW we saw in the thread that we could share also / on multiple systems!] I think the problem is having /usr in an other partition (a larger set of configuration, and in this case, we supported it), thus having problem at boot, on what the init script could expect (program and libraries). Sorry for my tone, but we are disturbed on the fact that a proposal was done without giving reasons. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 03:31:23PM +0200, Stefano Zacchiroli wrote: Anyhow, *you* don't understand the problem and you are probably the only one thinking I'm selling vapor. From other people's replies I conclude that the problem is quite clear and my vapor was so concrete that others hinted at technical solutions. But let me spell the problem out for you, as you are raising the tone of the discussion with exclamation marks (which was not my intention). The problem is that our package manager (dpkg) assumes it is in charge of files which reside on different top-level FHS directories: /usr, /var, /boot, /bin, /sbin, /lib, /lib64, ... In a scenario where /usr is remotely exported for NFS mounting, if you use dpkg on the exporting machine, client machines will get out of sync. Some files need to be copied over statically and, more interestingly, maintainer scripts will need to be re-run on client machines to deliver their side effects to all machines. Also the status of the dpkg database need to be synced with clients. My argument is mainly that we should not ask our user to do the above sync by hand, still claiming we support it. But _NOBODY_ said to support the sync part in Debian. Just leave things as-is, i.e. let it possible to have /usr as a separate filesystem. We can do the rest, thank you very much. The fact that clients can get out of sync is perfectly understood and handled when needed. There is nothing new here; mounting /usr over NFS on Solaris boxes a decade ago had exactly the same basic issues. Don't ask users to do the sync by hand. Just _let_ them do it if they wish. Mounting /usr over NFS is an old technique. I wouldn't recommend it to anyone today but it exists and deliberately breaking it just because you do not like it is stupid. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Le mercredi 06 mai 2009 à 08:57 -0500, Peter Samuelson a écrit : Also, this procedure would be much more reliable if we said, in Policy, that maintainer scripts are not allowed to fail if /usr is not writable. (mount -o ro, SELinux, chattr +i, NFS root_squash, whatever.) Would you support that policy? I suspect ldconfig would have to be patched in some way. So, after people pestered me so that I moved python-support files from /var to /usr, now others will complain again and require them to go again to /var? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: deprecating /usr as a standalone filesystem?
On Tue, 05 May 2009, Marco d'Itri wrote: I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. I wonder what these are, and I hope you will start a separate thread with that information. So, does anybody still see reasons to continue supporting a standalone /usr? Yes. We use that mode in _ALL_ servers. We keep it read-only except while applying security updates. This means it *never* gets hosed by crashes, and it is less vulnerable to accidental damage. / is also protected, using different strategies: it has to be read-write if you want to keep sane right now, so we have in / only /root, /boot, /etc, /bin and /sbin, plus mountpoints. These almost never change, so the filesystem is rarely modified. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Le 6 mai 09 à 00:30, Stefano Zacchiroli a écrit : On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote: So, does anybody still see reasons to continue supporting a standalone /usr? There had been lots of responses to that. Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. I guess there is a way if you want to upgrade your machines one by one : temporarily have 3 instances of /usr. The not-yet-upgraded machines will use /usr(old), the upgraded machines /usr(new), and the machine currently being upgraded will work on a /usr(tmp) which is a copy of /usr(old) and which it will upgrade into a copy of /usr(new). Now there is another way, which is to upgrade just one machine and clone its hard drive (except for the couple of files which need to be different). So that's two fairly easy ways to do it. There may be more clever ones. T. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 02:56:20PM +0200, Stefano Zacchiroli wrote: In particular, from the replies to my question the picture I get is that everybody is using ad hoc solutions to implement what some people are pretending to be properly supported by Debian. I found it not defendable, maybe it's just me, maybe it's just bad marketing. Of the two one: - We decide that mounting /usr remotely is a Debian goal. If we do so, the mechanisms to make it work should not be as ad hoc as this thread as hinted. We should provide a package explicitly made to make this workflow tenable and point our users to it. - We decide that if you want to mount /usr remotely you are on your own. If we do so, we should stop using mount /usr remotely as an argument for keeping /usr as a single filesystem. What about the (many) arguments made here about the *other* reasons to have /usr a separate filesystem? regards, iustin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Philipp Kern tr...@philkern.de writes: On 2009-05-06, Russ Allbery r...@debian.org wrote: I think it's pretty unlikely that *most* Debian machines are done that way. There are a lot better tools for keeping large numbers of systems in sync these days than simple cloning from golden images, and a lot of drawbacks to the golden image approach. We do the same with ~12 clients. One master image that's declared stable by rsyncing it using hardlinks[0] on the server and from there rsynced to the clients which reboot automatically if there are pending updates. After the rsyncing it does local profile-based patching. I wonder about the drawbacks of this because it works really nice for us. (Of course there's the downtime problem, but that's no problem for us, as those are clients not servers.) If you start getting node variation, it turns into a headache. If you're in a situation where you're assured of no node variation, it works fairly well within that situation, but we want one solution that works for *all* types of servers we run, whether clusters or one-offs or smaller sets of load-balanced servers. You can also get a slow accumulation of cruft in your golden image over time, and if you don't keep good documentation, it's really easy to discover that you no longer know exactly how to rebuild your golden image if you need to (such as for a new OS release). But why bother to do a complete reinstall everytime something changed if you could just sync the delta. (And yes, I'm roughly aware that there are something like softupdates in FAI too, but still.) We don't do it every time something changes; usually we use Puppet to push incremental changes. We rebuild systems whenever we repurpose them or whenever we do a major OS upgrade. I like rebuilding systems from first principles for exactly the same reason that I like recompiling the whole Debian archive. It tests your process. Having a complete process for building a system rather than a static system image that you may or may not be able to reproduce makes it much easier to migrate to new releases of the OS (because you can layer most of your policy on top of the new release), change any part of the process, etc. I've done this pretty much every different way you can with a lot of versions of UNIX: golden images, portions of the file system in network file systems, specific change application scripts, everything with native packages, mixes of native packaging and configuration management systems, etc. For a fairly heterogeneous mix of servers that may include some clusters of identical systems, I think FAI plus a good configuration management system like Puppet is the way to go. It makes me feel the most comfortable about the upgrade path, the testing of the whole system, and the robustness of the environment. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem? [386 support]
Le mardi 05 mai 2009 à 23:38 +0200, Frank Lin PIAT a écrit : Interesting. I thought 386 wasn't supported anymore (?) AFAIK the kernel is able to emulate a 486 when running on a 386. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 09:36:56PM +0200, Iustin Pop wrote:
- We decide that if you want to mount /usr remotely you are on your
own.
If we do so, we should stop using mount /usr remotely as an
argument for keeping /usr as a single filesystem.
What about the (many) arguments made here about the *other* reasons to
have /usr a separate filesystem?
I've nothing against them, I was countering only this precise
argument. FWIW, I haven't seen that many, though the one about
read-only /usr was appropriate.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
On Thu May 07 00:38, Stefano Zacchiroli wrote: What about the (many) arguments made here about the *other* reasons to have /usr a separate filesystem? I've nothing against them, I was countering only this precise argument. FWIW, I haven't seen that many, though the one about read-only /usr was appropriate. More to the point, has anyone actually presented any real arguments why _not_ to allow it? I've not actually seen anything other than the OP saying things might need changing to support it and then refusing to go into detail. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
Peter Samuelson pe...@p12n.org writes: Also, this procedure would be much more reliable if we said, in Policy, that maintainer scripts are not allowed to fail if /usr is not writable. (mount -o ro, SELinux, chattr +i, NFS root_squash, whatever.) Would you support that policy? I suspect ldconfig would have to be patched in some way. I certainly wouldn't. The maintainer scripts need to be able to do whatever they need to do in order to get the package set up on the system. That certainly includes changing things in ‘/usr’, which requires that filesystem to be writable during package management. Those who want a read-only ‘/usr’ don't seriously try to leave it read-only while installing or upgrading packages, do they? -- \ “The optimist thinks this is the best of all possible worlds. | `\ The pessimist fears it is true.” —J. Robert Oppenheimer | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
deprecating /usr as a standalone filesystem?
I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? If you do, please provide a detailed real-world use case. A partial list of invalid reasons is: - I heard that this was popular in 1998 - it's a longstanding tradition to support this - it's really useful on my 386 SX with a 40 MB hard disk -- ciao, Marco signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
Marco d'Itri a écrit : I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. Could you elaborate on the kind of large changes there are in Debian to support this? A partial list of invalid reasons is: [...] How about: my /usr is shared by many machines over NFS? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On May 05, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: - NFS This is not detailed. - for my wifi box (ie a 386 SX with 8MB of flash) This is not real world. -- ciao, Marco signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
Le mardi 05 mai 2009 à 17:36 +0200, Marco d'Itri a écrit : I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). Just for the record, what kind of issues is it causing? Is it about some libraries needing to lie in /lib? So, does anybody still see reasons to continue supporting a standalone /usr? If you do, please provide a detailed real-world use case. On my laptop, / is an encrypted partition while /usr is not. There is nothing secret in my /usr, while there is in my /etc, and OTOH /usr being unencrypted gives better performance. Frankly, I could live without it. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: deprecating /usr as a standalone filesystem?
On Tue, May 5, 2009 at 5:36 PM, Marco d'Itri m...@linux.it wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? If you do, please provide a detailed real-world use case. A partial list of invalid reasons is: - I heard that this was popular in 1998 - it's a longstanding tradition to support this - it's really useful on my 386 SX with a 40 MB hard disk - NFS - for my wifi box (ie a 386 SX with 8MB of flash) Regards Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On May 05, Stéphane Glondu st...@glondu.net wrote: Could you elaborate on the kind of large changes there are in Debian to support this? I'd rather not change subject. A partial list of invalid reasons is: [...] How about: my /usr is shared by many machines over NFS? Do you actually *do* this? On how many systems? How do you manage upgrades? -- ciao, Marco signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
Marco d'Itri wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? On several server (and my desktop) I mount /usr as a separate partition and read-only (with some hook in /etc/apt/ to temporary remount it). Could you explain us why you want to discontinue supporting a standalone /usr? A partial invalid reason list: - other distro want it! (we are not other distro) - it is easier! (we are hard men/women) ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, May 5, 2009 at 5:43 PM, Marco d'Itri m...@linux.it wrote: On May 05, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: - NFS This is not detailed. /usr NFS shared. Scientific grid use this stuff and it is real world. But may be it is too big for debian ;) - for my wifi box (ie a 386 SX with 8MB of flash) This is not real world. I am not really sure that embeded development is not real world. And it will growth more than classical PC in the next ten year. Maybe too small for debian ;) If you believe that debian is only for new edge intel, I think that you will feed a big troll. Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, May 05, 2009 at 05:41:06PM +0200, Stéphane Glondu wrote: Marco d'Itri a écrit : I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. A partial list of invalid reasons is: [...] How about: my /usr is shared by many machines over NFS? That might have been a traditional reason for a shared /usr. However, the package manager can't cope with this setup since you have some components of a package installed locally and some remotely for all systems using the shared part. It's an impossible situation to actually cater for in real life. Has anyone ever actually *done* this? Just having /usr on NFS doesn't make it shared if it's only used by a single system, or unless you have a cluster using a common image, but even then it's not shared between systems since they are just clones of the same system--you wouldn't run dpkg on them. As an aid to the maintainability and security of a system, it's nice to be able to mount /usr readonly and also to run without it using a minimal /usr for recovery and troubleshooting purposes. Looking at GNU/Hurd, /usr is a symlink to /. If we were to make /usr non-separable, maybe this would be the way to go. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, May 05 2009, Marco d'Itri wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? - Security. + One may want to have /usr mounted read only + Other file systems can have different mount options. not possible if they needed to have /usr - Backups: having different partitions allows one to have different backup policies - corruption: easier to recover from corruption when paritions are smaller and targeted. - encryption: you might not want to encrypt the whole disk. ,[ /etc/fstab snippet ] | LABEL=1 / ext3 noatime,errors=remount-ro 0 1 | LABEL=2 /boot ext3 noatime,defaults,rw,noauto 0 2 | LABEL=3 /usrext3 noatime,defaults,ro 0 2 | LABEL=4 /home ext3 noatime,rw,nodev0 2 | LABEL=5 /usr/local ext3 noatime,rw,nosuid,nodev 0 2 | LABEL=6 /varext3 noatime,rw,nosuid 0 2 | LABEL=7 /var/spool ext3 noatime,rw,nosuid,nodev 0 2 | LABEL=8 /backup ext3 noatime,rw,nosuid,nodev 0 2 | LABEL=9 /scratchext3 noatime,rw 0 2 ` manoj -- Deliver yesterday, code today, think tomorrow. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Le mardi 05 mai 2009 à 17:24 +0100, Roger Leigh a écrit : That might have been a traditional reason for a shared /usr. However, the package manager can't cope with this setup since you have some components of a package installed locally and some remotely for all systems using the shared part. It's an impossible situation to actually cater for in real life. Has anyone ever actually *done* this? Of course, you just need to think the image you actually update as a master image, after which it is replicated by any means necessary (be it systemimager or NFS). As for NFS, I’d use root NFS instead of complicating my life with two different methods for / and /usr, but I guess some are doing it this way. Looking at GNU/Hurd, /usr is a symlink to /. If we were to make /usr non-separable, maybe this would be the way to go. Quite true. If we stop supporting /usr on a separate partition, it entirely removes the need for /usr. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: deprecating /usr as a standalone filesystem?
Roger Leigh wrote: On Tue, May 05, 2009 at 05:41:06PM +0200, Stéphane Glondu wrote: Marco d'Itri a écrit : I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. A partial list of invalid reasons is: [...] How about: my /usr is shared by many machines over NFS? That might have been a traditional reason for a shared /usr. However, the package manager can't cope with this setup since you have some components of a package installed locally and some remotely for all systems using the shared part. It's an impossible situation to actually cater for in real life. Has anyone ever actually *done* this? So why we created /usr/share (and moved documentation) ? I see a lot of parallel installed system, so in this case I see no problem on sharing /usr. [BTW one of the most important conference is not LISA, about such configurations?] But also I don't think it is a problem sharing usr on multiple system with multiple configurations. On non public working stations, one doesn't run randomly programs. If I installed mysql-server on a system, it will work on such system, but if I install on an other system, it work also on the other system, occupying only one instance. I don't see problem from package management (also because we have a nullpotent dpkg), so we can upgrade from multiple system without problems. Looking at GNU/Hurd, /usr is a symlink to /. If we were to make /usr non-separable, maybe this would be the way to go. or plan9, which bind mount all /*/bin into the main /bin. I can live with such solution, but please allow us to use /usr in a different (maybe shared) partition. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On 05/05/09 at 17:58 +0200, Bastien ROUCARIES wrote: On Tue, May 5, 2009 at 5:43 PM, Marco d'Itri m...@linux.it wrote: On May 05, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: - NFS This is not detailed. /usr NFS shared. Scientific grid use this stuff and it is real world. But may be it is too big for debian ;) Do you actually do this? On which grid/cluster? - for my wifi box (ie a 386 SX with 8MB of flash) This is not real world. I am not really sure that embeded development is not real world. And it will growth more than classical PC in the next ten year. Maybe too small for debian ;) Have you compared the power consumption of your 386 SX with a more modern system? Also, I doubt that you will run Debian squeeze on your 386 SX ;) -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, May 05 2009, Marco d'Itri wrote: On May 05, Stéphane Glondu st...@glondu.net wrote: Could you elaborate on the kind of large changes there are in Debian to support this? I'd rather not change subject. This is not a change of subject. You are starting a haevy duty thread about changing how Debian does things, you need to provide motivation for even thinking of this change. Why should we bother? A partial list of invalid reasons is: [...] How about: my /usr is shared by many machines over NFS? Do you actually *do* this? Sure. On how many systems? About 30 or so. How do you manage upgrades? I have nothing to manage. This is POSIX, after all. Once the partitions have been setup, what management is there to be done? manoj -- Marriage is a great institution -- but I'm not ready for an institution yet. Mae West Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Marco d'Itri wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). Do you mean that: 1) /usr is dedicated to the system, (NFS sharing /usr across multiple independent systems would be out) -or- 2) /usr is part of the root partition, much like how /lib is now. The latter implies the former, of course. The last time I installed Red Hat Enterprise Linux (which was RHEL 5.2) I was still given the option of making a separate partition for /usr. I have never installed Fedora or SuSE. The last time I installed Ubuntu was multiple years ago, so I don't know what they are doing currently. Thank you for clearing up this point of confusion. -- John H. Robinson, IV jaq...@debian.org http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). This is false for Ubuntu. Not only is it supported, but significant effort was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as pertains to wpasupplicant. I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. What packages? Any upstream not supporting this is also incompatible with the FHS. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Tue, May 05, 2009 at 05:36:02PM +0200, Marco d'Itri wrote: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? If you do, please provide a detailed real-world use case. A partial list of invalid reasons is: - I heard that this was popular in 1998 - it's a longstanding tradition to support this - it's really useful on my 386 SX with a 40 MB hard disk Scenarion A, desktop - / on non-LVM, fixed size, as recovery from a broken LVM setup is way harder if / is on LVM - /usr on LVM, as it can grow significantly, and having it on LVM is much more flexible Scenario B, laptop/netbook - / non-encrypted, small, asks for passphrase to boot - everything else on dm-crypt+lvm This seems a very weird proposition to me. Separate /usr works, as is more flexible: needed space for / is 500MB, needed space for /usr is 4GB. regards, iustin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Marco d'Itri wrote: On May 05, Bastien ROUCARIES roucaries.bast...@gmail.com wrote: - NFS This is not detailed. - for my wifi box (ie a 386 SX with 8MB of flash) This is not real world. It is. But as it seems you're living on a different world, so better don't start touching the real world where the rest of Debian lives in, kthnxgoodbye. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
