Re: from / to /usr/: a summary
On Sat, Jan 28, 2012 at 09:41:37PM +0100, Marco d'Itri wrote: On Jan 27, Wouter Verhelst wou...@debian.org wrote: Do I understand you correctly that an empty configuration file in /etc will override its 'full' equivalent in /usr? I.e., just an empty file full of comments saying this is what you can do with this file will break some things? This is correct. If so, are there some things in udev which intrinsically depend on that behaviour? Documentation and consistency with all other distributions. I wasn't trying to suggest Debian-specific changes. Upstream mistakes (if they are that) should be fixed upstream, not in Debian. The only alternative solution which I consider acceptable would be to move everything back to /etc and then symlink the /usr/lib/ directory to the /etc/ directory. But I am sure that you can understand why this transition would be hard and messy for the maintainers of the affected packages at this point in time. Sure. BTW, I want to point out that Rusty Russell neatly summarized the points of the / to /usr argument: http://rusty.ozlabs.org/?p=236 . Yes, though it's a fairly silly representation of the anti side. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120129212319.gd4...@grep.be
Re: from / to /usr/: a summary
On Jan 27, Wouter Verhelst wou...@debian.org wrote: Do I understand you correctly that an empty configuration file in /etc will override its 'full' equivalent in /usr? I.e., just an empty file full of comments saying this is what you can do with this file will break some things? This is correct. If so, are there some things in udev which intrinsically depend on that behaviour? Documentation and consistency with all other distributions. The only alternative solution which I consider acceptable would be to move everything back to /etc and then symlink the /usr/lib/ directory to the /etc/ directory. But I am sure that you can understand why this transition would be hard and messy for the maintainers of the affected packages at this point in time. BTW, I want to point out that Rusty Russell neatly summarized the points of the / to /usr argument: http://rusty.ozlabs.org/?p=236 . -- ciao, Marco signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Sat, 28 Jan 2012 21:41:37 +0100, Marco d'Itri m...@linux.it wrote: On Jan 27, Wouter Verhelst wou...@debian.org wrote: Do I understand you correctly that an empty configuration file in /etc will override its 'full' equivalent in /usr? I.e., just an empty file full of comments saying this is what you can do with this file will break some things? This is correct. If so, are there some things in udev which intrinsically depend on that behaviour? Documentation and consistency with all other distributions. The only alternative solution which I consider acceptable would be to move everything back to /etc and then symlink the /usr/lib/ directory to the /etc/ directory. But I am sure that you can understand why this transition would be hard and messy for the maintainers of the affected packages at this point in time. BTW, I want to point out that Rusty Russell neatly summarized the points of the / to /usr argument: http://rusty.ozlabs.org/?p=236 . Marvelous -- I particularly like his Separate /usr has become increasingly unsupported anyway. which reminds me of the argument for Software Patents in Europe, which is that the EPO have been issuing Software Patents in defiance of the law for ages, so clearly the right thing to do is to change the law to fit the facts. Thanks for moving the argument forward by pointing out such cogent reasoning. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpAHlUsL3fqC.pgp Description: PGP signature
Re: from / to /usr/: a summary
On Jan 28, Philip Hands p...@hands.com wrote: Marvelous -- I particularly like his Separate /usr has become increasingly unsupported anyway. which reminds me of the argument for Software Patents in Europe, which is that the EPO have been issuing Software Patents in defiance of the law for ages, so clearly the right thing to do is to change the law to fit the facts. The difference is that you are not going to be able to influence Red Hat in supporting systems with /usr not available after the initramfs, while there is a political process to influence the creation of better laws which even the EPO must follow. (I am not singling Red Hat as the bad guy here, but it is the distribution which controls the development of most low level system components and so their design decisions have a significant impact on others.) -- ciao, Marco signature.asc Description: Digital signature
Re: from / to /usr/: a summary
Sorry for picking up this old thread, but...
On Mon, Jan 02, 2012 at 01:38:56AM +0100, Marco d'Itri wrote:
On Dec 31, Russ Allbery r...@debian.org wrote:
Note that Steve's point, namely that he (if I'm reading him right) thinks
that the upstream changes are being overstated and that upstream's
direction isn't actually going to cause problems for us, is an entirely
separate one and not something I'm addressing in the above. And is
certainly something to explore before we start arguing over who's going to
fork something that may not be an issue at all.
Unsurprisingly, this is not a black or white issue: there are many
different issues in different parts of the stack and with different
levels of complexity.
In some cases I have been able to keep old code around (e.g. to support
older kernels than upstream did), but in others it is intrinsecally
impossible (e.g. when udev needs to IMPORT{} data from something which
lives in /usr).
While I agree that forking upstream is not necessarily the right thing
to do, allow me to ask some things just so I understand things
better...
Do I understand you correctly that an empty configuration file in /etc
will override its 'full' equivalent in /usr? I.e., just an empty file
full of comments saying this is what you can do with this file will
break some things?
If so, are there some things in udev which intrinsically depend on that
behaviour? Or could you give me a rough gut-feeling estimation of the
amount of work that would be required to change it so it would work in
that way?
I think it's unfortunate that defaults are living outside of etc, but at
least if the files there can be made to exist in such a way that a
sysadmin knows where to look if he wants to change the defaults, then
the pain wouldn't be so bad.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120127094607.gd21...@grep.be
Re: from / to /usr/: a summary
On Fri, Jan 27, 2012 at 10:46:07AM +0100, Wouter Verhelst wrote: While I agree that forking upstream is not necessarily the right thing to do, allow me to ask some things just so I understand things better... Do I understand you correctly that an empty configuration file in /etc will override its 'full' equivalent in /usr? I.e., just an empty file full of comments saying this is what you can do with this file will break some things? If so, are there some things in udev which intrinsically depend on that behaviour? I can give an example of this one. Placing an empty 75-persistent-net-generator.rules in /etc/udev/rules.d is the recommended way to prevent udev from allocating your network devices to fixed static MAC addresses (something it otherwise does which is the bane of a virtual machine admin's life, and which makes things generally harder when you want to help non-Linux people in swapping network cards over). Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120127124040.ga32...@leverton.org
Re: from / to /usr/: a summary
Thomas Goirand z...@debian.org writes: On 12/22/2011 07:07 PM, Russell Coker wrote: It seems to me that wanting to have / outside LVM but /usr inside LVM is a fairly obscure corner case. I have about 100 servers setup this way, and my laptops as well. I really don't see why this would be a corner case. Please understand that many different people have many different configuration, and that in today's Debian, *absolutely everything is allowed*, and never, ever, Debian said that one type of setup would one day be forbidden. Taking decisions that some setup are not supported would be a bad move whatever the partitioning we are talking about. Please don't do that, there's no reason why Debian would take such move. Thomas The reason for such a setup is, historically, so that you could boot without initramfs. A small / (including /boot) to boot from and start up lvm before mounting /usr, /var and /home. Prior to grub2, which can now boot from LVM directly, this was a verry sensible setup. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjjd9knn.fsf@frosties.localnet
Re: from / to /usr/: a summary
On Fri, Jan 6, 2012 at 4:56 AM, Romain Beauxis wrote: 2012/1/5 Paul Wise p...@debian.org: In my opinion it is a pretty ugly hack that we should discourage where possible. There is a trade-off to consider between patching every single webapp, having no writable location at all and placing files where they belong to. I consider that a good one (trade-off). Hence the where possible The right way to do things is something like how things are done with django-based applications. It would probably be more convincing if you'd take the time to explain what is done there.. Web server configuration that tells the app where to find its configuration. App configuration tells the app where to find its data, plugins etc. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6HpLV+Jwvze5GFZNftycdzUty+ghRzpRuNPnV1v01_=l...@mail.gmail.com
Re: from / to /usr/: a summary
Hi, 2012/1/5 Paul Wise p...@debian.org: On Thu, Jan 5, 2012 at 11:32 AM, Romain Beauxis wrote: I once proposed to push for a general policy regarding this symlink trick for webapps and even to write a debhelper but it did not seem to appeal to anyone. I am still convinced, though, that it should be standard practice. In my opinion it is a pretty ugly hack that we should discourage where possible. There is a trade-off to consider between patching every single webapp, having no writable location at all and placing files where they belong to. I consider that a good one (trade-off). The right way to do things is something like how things are done with django-based applications. It would probably be more convincing if you'd take the time to explain what is done there.. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CABWZ6OQu==c35kvivhcbxhodkad_rsndzqb1wf-pdrwujp7...@mail.gmail.com
Re: dokuwiki and /usr [WAS: from / to /usr/: a summary]
Enrico Weigelt, 2012-01-04 02:10+0100: Well, *I* would be *very* suprised by having packaged files under /var. So I would have changed the app to (additionally) look for plugins under /usr (in this case /usr/share/dokuwiki/plugin/) If you are willing to prepare a patch implementing that, I would be very glad to include it. -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Tanguy | `-'Debian Developer \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/je1hfo$7du$1...@dough.gmane.org
Re: from / to /usr/: a summary
On Sun, 01 Jan 2012 at 20:20:42 +, Tanguy Ortolo wrote: Enrico Weigelt, 2011-12-31 03:55+0100: IMHO this is completely wrong, those files should be under /usr/lib/... or maybe even /usr/share/... as they're not dynamic data. Well, when people install new plugins or new themes, they get installed on the same directory, so I decided that it was less surprising to have packaged files that people will not touch under /var than to have user files under /usr. Roundcube seems to be in a similar situation. In Debian, it installs to /etc and /usr (as appropriate for each file) but sets its home path to /var/something, then populates /var/something with a symlink farm. That might be a useful solution here? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104140027.gy22...@reptile.pseudorandom.co.uk
Re: from / to /usr/: a summary
Hi all, 2012/1/4 Simon McVittie s...@debian.org: On Sun, 01 Jan 2012 at 20:20:42 +, Tanguy Ortolo wrote: Enrico Weigelt, 2011-12-31 03:55+0100: IMHO this is completely wrong, those files should be under /usr/lib/... or maybe even /usr/share/... as they're not dynamic data. Well, when people install new plugins or new themes, they get installed on the same directory, so I decided that it was less surprising to have packaged files that people will not touch under /var than to have user files under /usr. Roundcube seems to be in a similar situation. In Debian, it installs to /etc and /usr (as appropriate for each file) but sets its home path to /var/something, then populates /var/something with a symlink farm. That might be a useful solution here? The same was also done for mediawiki at least when I was maintaining it. I also wish the wordpress packagers would do the same in order to be able to install plugins and themes simply. I once proposed to push for a general policy regarding this symlink trick for webapps and even to write a debhelper but it did not seem to appeal to anyone. I am still convinced, though, that it should be standard practice. Romain -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CABWZ6OQoF+gQioi_jtkp7nJYM0-6bQNF+9_3DeJE5=un7qp...@mail.gmail.com
Re: from / to /usr/: a summary
On Thu, Jan 5, 2012 at 11:32 AM, Romain Beauxis wrote: I once proposed to push for a general policy regarding this symlink trick for webapps and even to write a debhelper but it did not seem to appeal to anyone. I am still convinced, though, that it should be standard practice. In my opinion it is a pretty ugly hack that we should discourage where possible. The right way to do things is something like how things are done with django-based applications. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6eoa_egj7tyun6hkogqf7w7mj_iew1styl91fmreo2...@mail.gmail.com
Re: from / to /usr/: a summary
On Thu, 5 Jan 2012, Romain Beauxis to...@rastageeks.org wrote: The same was also done for mediawiki at least when I was maintaining it. I also wish the wordpress packagers would do the same in order to be able to install plugins and themes simply. I don't think it's desirable to have such a simple installation of plugins and themes. That would be of some use for systems where there is only one person running the blogs but that person doesn't have root access, but the person with root access could make the needed changes for that situation. I expect that the more common cases are where the one person is root and blog admin and the case where there are multiple blog admins on the same system. In those cases it's best to have all plugins and themes packaged. Plugins and themes typically have no release history so if you don't have them packaged (or run through a local VCS) then you will probably end up not knowing what changes were made. After my blog server was compromised and requred reinstallation I discovered that I had no record of some of the local changes made to plugins and themes and I couldn't get some of them working again afterwards. Now my blog looks quite different because in the amount of time available I couldn't make it do the same things as before. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201051456.54994.russ...@coker.com.au
Re: from / to /usr/: a summary
On Jan 03, Russ Allbery r...@debian.org wrote: Yes. But it needs to actually be a co-maintainer, or it needs to be someone who's offering to be a new upstream, not someone who is willing to produce a one-time fix to the problem. And we are not discussing a missing fix, but radically modifying its semantics and those of the upper components of the stack. -- ciao, Marco signature.asc Description: Digital signature
Re: from / to /usr/: a summary
* Fernando Lemos fernando...@gmail.com schrieb: Are you guys applying for maintainership for this huge delta you want to introduce between upstream and us? Actually, yes. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104005611.ga9...@mailgate.onlinehome-server.info
Re: from / to /usr/: a summary
* Russ Allbery r...@debian.org schrieb: That experience aside, we're not talking about patches here, assuming Marco's description of the situation is correct. We're talking about a full-blown fork and a need for a new udev upstream. Maybe a downstream-branch is enough. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104010205.gb9...@mailgate.onlinehome-server.info
dokuwiki and /usr [WAS: from / to /usr/: a summary]
* Tanguy Ortolo tanguy+deb...@ortolo.eu schrieb: Enrico Weigelt, 2011-12-31 03:55+0100: IMHO this is completely wrong, those files should be under /usr/lib/... or maybe even /usr/share/... as they're not dynamic data. Well, when people install new plugins or new themes, they get installed on the same directory, so I decided that it was less surprising to have packaged files that people will not touch under /var than to have user files under /usr. Well, *I* would be *very* suprised by having packaged files under /var. So I would have changed the app to (additionally) look for plugins under /usr (in this case /usr/share/dokuwiki/plugin/) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104011036.gc9...@mailgate.onlinehome-server.info
Re: from / to /usr/: a summary
* Russ Allbery r...@debian.org [120101 19:12]: If the maintainer refuses patches and only wants to fix brokeness if someone does a full blown upstream fork then this is a maintainer issue. I think this discussion is getting hopelessly muddled by excessive use of sweeping statements like this. As your mail seems to defend things I did not attack let me rephrase it to make clear what I do not like about some submissions to this thread. Let me it as a list of simple statements so people disagreeing with some part can more easily say which: 1) Debian contributors are volunteers, they are not be forced to do some work. 2) Packages, especially those not avoidable in a Debian installation, are no personal property. 3) Having little derivations from upstream is a good thing as it makes maintainance easier. 4) Debian is about a coherent system that is of use for out users, packages that do not fit in are broken. 5) Different cases of (4) can have different severities and must be weighted against other problems and costs and disadvantages. One such cost is (3), but (3) is no absolute to rule out anything, only a relative to throw into the scale. 6) (1) means a maintainer can say they will not do something, but they cannot say a package will not do it (because of (2)). Also it is no argument to silence discussions about what a package should do. 7) If the only remaining obstacle in (5) is lack of time for the current maintainer to allow derivation from upstream, then a new full blown upstream might be one solution. But another solution is some comaintainer to volunteer to forward-port those changes and handle the incoming Debian bug reports. 8) Some maintainer might not like (7), and say they will not do that (because of (6)), but that is no argument for a discussion. Because that would mean implying the maintainer cannot work with other people, which for a core package would rather be a reason to look for a new maintainer... And to turn down help and discurage volutneers harshly is not better than demanding volunteers to do a specific work. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120102223722.ga2...@server.brlink.eu
Re: from / to /usr/: a summary
Thank you for the list. That does make things clearer. Bernhard R. Link brl...@debian.org writes: 1) Debian contributors are volunteers, they are not be forced to do some work. 2) Packages, especially those not avoidable in a Debian installation, are no personal property. [...] 6) (1) means a maintainer can say they will not do something, but they cannot say a package will not do it (because of (2)). Also it is no argument to silence discussions about what a package should do. *However*, what is an argument to silence discussion about what a package would do is if no one is stepping forward to do the work on an *ongoing* basis, since divergences from upstream are not a one-time thing. 7) If the only remaining obstacle in (5) is lack of time for the current maintainer to allow derivation from upstream, then a new full blown upstream might be one solution. But another solution is some comaintainer to volunteer to forward-port those changes and handle the incoming Debian bug reports. Yes. But it needs to actually be a co-maintainer, or it needs to be someone who's offering to be a new upstream, not someone who is willing to produce a one-time fix to the problem. And what my point was about forking upstream is that an easier way to maintain *significant* changes to upstream without volunteering to do the rest of the packaging work and integration with Debian is to maintain an upstream fork and ask the Debian package maintainer to switch upstreams. -- 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 Archive: http://lists.debian.org/874nwdsm04@windlord.stanford.edu
Re: from / to /usr/: a summary
On 01/01/2012 03:11 PM, Russ Allbery wrote: Thomas Goirand tho...@goirand.fr writes: On 01/01/2012 01:49 AM, brian m. carlson wrote: So the only sane thing to do is not change the default, ever. The other sane way is to mark files not in /etc as conffiles. It semantically sux a bit, but if we have no choice because of upstream decisions (which we don't have enough time to fix), then that might be a way... That doesn't help unless you expect sysadmins to change them (unchanged conffiles are quietly updated just like any other package file), at which point it becomes an FHS violation. Which is why I wrote semantically sux a bit (it's another way to say there's a FHS violation ...). But my understanding is that we have no choice considering the path upstream took. I'd like to know: is it a normal thing to edit these files in /usr/lib/udev/rules.d (or, any other file that udev will use and which will be stored in /usr)? Or should we expect that *never* anyone will touch them (eg: there's never a real valid reason to edit them)? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f002401.1050...@debian.org
Re: from / to /usr/: a summary
* Russ Allbery r...@debian.org [111231 18:41]: Bernhard R. Link brl...@debian.org writes: My experience is rather that people usually stick to their core packages as personal property and won't except patches to make them more well behaved. That experience aside, we're not talking about patches here, assuming Marco's description of the situation is correct. We're talking about a full-blown fork and a need for a new udev upstream. You don't need to send patches to anyone for that; you need to set up a Git repository, a web page, a development mailing list, some infrastructure around how you're going to maintain the software, and start doing regular releases, and then see about getting Debian to switch upstreams. If people maintain some core piece of software and want to decide what the package looks like, listen to what other people want. This isn't about the package. It's about the *software*, the part that we generally use from upstream as much as possible because asking people to be both upstream and the Debian package maintainer is generally too much work for one person or even a small packaging team. If the maintainer refuses patches and only wants to fix brokeness if someone does a full blown upstream fork then this is a maintainer issue. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120101115756.gb3...@server.brlink.eu
Re: from / to /usr/: a summary
* Josselin Mouette j...@debian.org [111231 10:54]: Le samedi 31 décembre 2011 à 10:23 +0100, Bernhard R. Link a écrit : If people maintain some core piece of software and want to decide what the package looks like, listen to what other people want. If you want to use too much work as excuse, then file a RFA. Because it’s well-known that filing RFAs will magically generate competent maintainers with a lot of time in their hands. Spare your sarcasm, please. While a RFA will not magically make people appear magically, one at least makes clear that one would accept help. Even there it is of course possible to refuse help as incompotent, just as refusing patches by requiring a full upstream fork. But you cannot combine a I'm the only one knowing how to handle the package with There is not enough manpower for your request, so do not dare to say that the current situation is broken. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120101120229.gc3...@server.brlink.eu
Re: from / to /usr/: a summary
On 12/21/2011 11:55 AM, Russell Coker wrote: Nowadays 100G disks are small by laptop standards and for desktops 1TB is about the smallest that anyone would buy. Focussing on the desktop is the core of this - imho - misguided idea. I'd still like to be able have a small, self-contained, Debian that I can run on about anything. /usr is where all the real bloat (Gnome etc.) lies, which may or may not be available, and if you eg. consider your favourite phone storage, that's 512MB internally, or similar, with /home presumably on an external storage (SD card). Things have changed a lot since the FSSTD first came out. Indeed. Nowadays, we should support a much wider range of devices, not just computers the size of refrigerators. -- Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f004b35.2040...@debian.org
Re: from / to /usr/: a summary
On Sun, 1 Jan 2012, Toni Mueller t...@debian.org wrote: On 12/21/2011 11:55 AM, Russell Coker wrote: Nowadays 100G disks are small by laptop standards and for desktops 1TB is about the smallest that anyone would buy. Focussing on the desktop is the core of this - imho - misguided idea. I'd still like to be able have a small, self-contained, Debian that I can run on about anything. /usr is where all the real bloat (Gnome etc.) lies, which may or may not be available, and if you eg. consider your favourite phone storage, that's 512MB internally, or similar, with /home presumably on an external storage (SD card). Do we have Debian running on phones with a configuration such that the root filesystem is small but /usr can be bigger? Note that we shouldn't be planning for future phones here because they will have more internal storage. Phone storage is rapidly getting bigger. Things have changed a lot since the FSSTD first came out. Indeed. Nowadays, we should support a much wider range of devices, not just computers the size of refrigerators. Yes, modern phones have more RAM and storage than the fridge size servers of the early 90's. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201020049.04656.russ...@coker.com.au
Re: from / to /usr/: a summary
Le dimanche 01 janvier 2012 à 13:02 +0100, Bernhard R. Link a écrit : Because it’s well-known that filing RFAs will magically generate competent maintainers with a lot of time in their hands. Spare your sarcasm, please. No. I’m sick of these repeated allusions, really. If you are not ready to help, please stop telling maintainers that they should treat your personal nitpicks as the most important matters. While a RFA will not magically make people appear magically, one at least makes clear that one would accept help. Most maintainers in core teams have been repeatedly explaining they are PERMANENTLY looking for help. So far, neither RFHs, RFAs nor calls for help have changed much. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: from / to /usr/: a summary
Russell Coker russ...@coker.com.au writes: Do we have Debian running on phones with a configuration such that the root filesystem is small but /usr can be bigger? My openmoko has just $ df -h Filesystem Size Used Avail Use% Mounted on rootfs 3.8G 3.0G 626M 83% / tmpfs 5.0M 0 5.0M 0% /lib/init/rw tmpfs13M 224K 13M 2% /run tmpfs25M 24K 25M 1% /tmp udev 62M 0 62M 0% /dev tmpfs25M 4.0K 25M 1% /run/shm tmpfs13M 224K 13M 2% /var/lock tmpfs13M 224K 13M 2% /var/run -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/84wr9bxzac@sauna.l.org
Re: from / to /usr/: a summary
On Sun, Jan 01, 2012 at 05:14:41PM +0800, Thomas Goirand wrote: On 01/01/2012 03:11 PM, Russ Allbery wrote: Thomas Goirand tho...@goirand.fr writes: The other sane way is to mark files not in /etc as conffiles. It semantically sux a bit, but if we have no choice because of upstream decisions (which we don't have enough time to fix), then that might be a way... That doesn't help unless you expect sysadmins to change them (unchanged conffiles are quietly updated just like any other package file), at which point it becomes an FHS violation. I'd like to know: is it a normal thing to edit these files in /usr/lib/udev/rules.d (or, any other file that udev will use and which will be stored in /usr)? Or should we expect that *never* anyone will touch them (eg: there's never a real valid reason to edit them)? The latter. If you wish to override them, place the new file in /etc/udev/rules.d and the one in /usr/lib/udev won't be used. Nick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120101144201.ga5...@leverton.org
Re: from / to /usr/: a summary
On Sun, 2012-01-01 at 14:42, Nick Leverton wrote: On Sun, Jan 01, 2012 at 05:14:41PM +0800, Thomas Goirand wrote: On 01/01/2012 03:11 PM, Russ Allbery wrote: Thomas Goirand tho...@goirand.fr writes: The other sane way is to mark files not in /etc as conffiles. It semantically sux a bit, but if we have no choice because of upstream decisions (which we don't have enough time to fix), then that might be a way... That doesn't help unless you expect sysadmins to change them (unchanged conffiles are quietly updated just like any other package file), at which point it becomes an FHS violation. I'd like to know: is it a normal thing to edit these files in /usr/lib/udev/rules.d (or, any other file that udev will use and which will be stored in /usr)? Or should we expect that *never* anyone will touch them (eg: there's never a real valid reason to edit them)? The latter. If you wish to override them, place the new file in /etc/udev/rules.d and the one in /usr/lib/udev won't be used. ^ You mean: /lib/udev/rules.d -- Kind regards, Milan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120101172513.gb29...@arvanta.net
Re: from / to /usr/: a summary
Bernhard R. Link brl...@debian.org writes: * Russ Allbery r...@debian.org [111231 18:41]: This isn't about the package. It's about the *software*, the part that we generally use from upstream as much as possible because asking people to be both upstream and the Debian package maintainer is generally too much work for one person or even a small packaging team. If the maintainer refuses patches and only wants to fix brokeness if someone does a full blown upstream fork then this is a maintainer issue. I think this discussion is getting hopelessly muddled by excessive use of sweeping statements like this. I can't tell from this response whether you just disagree with Marco that the changes required will be substantial and ongoing, or whether you think that Marco should be maintaining substantial and ongoing patches himself as part of some obligation to the project for having the title of udev maintainer, or something else. And that lack of clarity just makes for more pointless arguments. Semantically, *any* patch is a fork of a sort. Practically, small patches involve small amounts of ongoing work and therefore become a different sort of thing than a real fork. A real fork is required if the patches become substantial, impact core functionality, and pose significant merge issues. But there's no clear distinction. My understanding of Marco's position is that the changes to udev that people are objecting to (undermining the ability to mount only / and not /usr at early boot, and using configuration overlays or replacements in /etc with package files in /lib) are the sort of changes that cannot be reversed with a simple patch that Marco can easily maintain on an ongoing basis. That even if the current complexity is low, he believes it will grow. This is an ENTIRELY REASONABLE thing for a maintainer to say, and an entirely reasonable thing for a maintainer to not want to get involved in. I daresay it's likely you've done the same yourself for some wontfix divergence from upstream with one of your packages. I know I certainly have with mine. Packaging resources are limited, and maintaining permanent divergence from upstream is a lot of hard work. Please, don't try to paint this position as some sort of dereliction of duty in order to score rhetorical points. It doesn't get us anywhere. If you think Marco is wrong in his estimation of the level of effort required, *that* is useful information, particularly if it's backed up with a concrete analysis (which would involve research into what the changes entail and what the udev upstream has said). That's a good discussion to have. But just hammering on Marco because you don't like the upstream direction of the package (at least as he understands it) and you want him to single-handedly stop it is pointless and needlessly antagonistic. -- 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 Archive: http://lists.debian.org/871urjb8bw@windlord.stanford.edu
Re: from / to /usr/: a summary
On Sat, Dec 24, 2011 at 11:48:42AM +, Philip Hands wrote: That might allow us to come up with solutions that are not just: Everyone must have initramfs, like it or not. Would we really need that? If I understand correctly, the / to /usr will merely mean that People who want to have /usr on separate partition will need initramfs. There might be other reasons why initramfs will get mandatory in near future thou. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120101190856.ga30...@afflict.kos.to
Re: from / to /usr/: a summary
Enrico Weigelt, 2011-12-31 03:55+0100: IMHO this is completely wrong, those files should be under /usr/lib/... or maybe even /usr/share/... as they're not dynamic data. Well, when people install new plugins or new themes, they get installed on the same directory, so I decided that it was less surprising to have packaged files that people will not touch under /var than to have user files under /usr. I'd split off package install and instance deployment (as soon as you want several dokuwiki instances on one host, that will be needed anyways). Multisite support is a feature that has been asked for quite a long time, but I implemented it some months ago, without copying anything. -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar | `-'Debian Maintainer \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jdqf6p$99b$1...@dough.gmane.org
Re: from / to /usr/: a summary
Toni Mueller wrote: On 12/21/2011 11:55 AM, Russell Coker wrote: Nowadays 100G disks are small by laptop standards and for desktops 1TB is about the smallest that anyone would buy. Focussing on the desktop is the core of this - imho - misguided idea. I'd still like to be able have a small, self-contained, Debian that I can run on about anything. /usr is where all the real bloat (Gnome etc.) lies, which may or may not be available, and if you eg. consider your favourite phone storage, that's 512MB internally, or similar, with /home presumably on an external storage (SD card). If you want to run Debian on a phone with incredibly small internal storage, then either put / on external storage, or don't install large packages like GNOME if you only have 512MB available. And in any case, nothing discussed in this thread would stop you from splitting out /usr if you want to, as long as the initramfs mounts it. (Also, my favorite phone has 32GB of storage. :) ) - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120101214217.GA27644@leaf
Re: from / to /usr/: a summary
On Dec 31, Russ Allbery r...@debian.org wrote:
ACK. Sometimes upstreams doing really stange things (maybe because they
dont have any package management in mind), that should be fixed. If
upstream doesnt do those fixes, distros have to catch in.
Sometimes, I think Red Hat makes some of these design decisions because
RPM's handling of configuration files sucks. If it had always behaved
like dpkg, I wonder if they wouldn't use designs that honor configuration
files somewhat more.
This has been my conclusion as well.
And an ever bigger problem is that Red Hat just does not support
upgrading to the next major release and so they choose to not care about
lots of issues which are important to us.
This, however, is a really good point, and is the thing that keeps running
through the back of my head reading this thread. There seems to be a lot
of sentiment that people wish udev (in particular) would work differently
A few people have been wishing for udev to work differently since it was
introduced in 2004. The major problem with these people is that they
usually do not understand how udev works, so they cannot propose
plausible alternative solutions, nor they have ever followed upstream
development, so they are unaware of the design choices and requirements
which lead to the current implementation.
I think it is obvious that so far I was right and they were wrong, since
they never actually proposed valid alternative solutions and my design
choices about how udev is integrated in Debian have been validated by
time and by adoption by other distributions.
(At least, before upstream drank the systemd kool aid.)
So we could waste a lot less time arguing over the inevitable if people
would accept that I tend to be right. :-)
Note that Steve's point, namely that he (if I'm reading him right) thinks
that the upstream changes are being overstated and that upstream's
direction isn't actually going to cause problems for us, is an entirely
separate one and not something I'm addressing in the above. And is
certainly something to explore before we start arguing over who's going to
fork something that may not be an issue at all.
Unsurprisingly, this is not a black or white issue: there are many
different issues in different parts of the stack and with different
levels of complexity.
In some cases I have been able to keep old code around (e.g. to support
older kernels than upstream did), but in others it is intrinsecally
impossible (e.g. when udev needs to IMPORT{} data from something which
lives in /usr).
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: from / to /usr/: a summary
On Jan 01, Riku Voipio riku.voi...@iki.fi wrote: Would we really need that? If I understand correctly, the / to /usr will merely mean that People who want to have /usr on separate partition will need initramfs. Correct. It does not even mean that they would need to use initramfs-tools, there are a few possible alternative solutions if anybody cared enough to implement them. I believe that creating a generic initramfs with busybox-static which can mount /usr defined on the kernel command line would take a couple of hours at most (and it could even be embedded in a custom kernel!). -- ciao, Marco signature.asc Description: Digital signature
Re: from / to /usr/: a summary
* Fernando Lemos fernando...@gmail.com [111231 04:54]: Are you guys applying for maintainership for this huge delta you want to introduce between upstream and us? Are you becoming new, reputable upstreams for that forked software? If not, please refrain from telling people what to do. My experience is rather that people usually stick to their core packages as personal property and won't except patches to make them more well behaved. If people maintain some core piece of software and want to decide what the package looks like, listen to what other people want. If you want to use too much work as excuse, then file a RFA. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111231092302.ga2...@server.brlink.eu
Re: from / to /usr/: a summary
Le samedi 31 décembre 2011 à 10:23 +0100, Bernhard R. Link a écrit : If people maintain some core piece of software and want to decide what the package looks like, listen to what other people want. If you want to use too much work as excuse, then file a RFA. Because it’s well-known that filing RFAs will magically generate competent maintainers with a lot of time in their hands. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: from / to /usr/: a summary
Bernhard R. Link brl...@debian.org writes: My experience is rather that people usually stick to their core packages as personal property and won't except patches to make them more well behaved. That experience aside, we're not talking about patches here, assuming Marco's description of the situation is correct. We're talking about a full-blown fork and a need for a new udev upstream. You don't need to send patches to anyone for that; you need to set up a Git repository, a web page, a development mailing list, some infrastructure around how you're going to maintain the software, and start doing regular releases, and then see about getting Debian to switch upstreams. If people maintain some core piece of software and want to decide what the package looks like, listen to what other people want. This isn't about the package. It's about the *software*, the part that we generally use from upstream as much as possible because asking people to be both upstream and the Debian package maintainer is generally too much work for one person or even a small packaging team. -- 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 Archive: http://lists.debian.org/87y5ts63mv@windlord.stanford.edu
Re: from / to /usr/: a summary
On Fri, Dec 30, 2011 at 07:54:34PM -0800, Josh Triplett wrote: The numerous upstreams which follow this model introduced it specifically *because* of distributions and package management, which they specifically had in mind as a design constraint. The search path behavior, along with the consistent use of .d directories, allows a clean distinction between upstream configuration, vendor/distribution configuration (any changes Debian wants to make to the defaults), sysadmin overrides of the defaults, and sysadmin configuration building on the defaults, without forcing sysadmins to perform manual three-way merges every time they upgrade. It also either (a) prevents upstream from ever changing that default or (b) silently breaks packages for the user. If option foo is set to bar in the upstream configuration and then upstream changes it to baz, the package breaks for the sysadmin. If the configuration were stored in /etc, the sysadmin would get notified by dpkg or ucf and would have an opportunity to change it. So the only sane thing to do is not change the default, ever. This does not sound to me like an especially robust model. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Sat, Dec 31, 2011 at 05:49:12PM +, brian m. carlson wrote: It also either (a) prevents upstream from ever changing that default or (b) silently breaks packages for the user. If option foo is set to bar in the upstream configuration and then upstream changes it to baz, the package breaks for the sysadmin. If the configuration were stored in /etc, the sysadmin would get notified by dpkg or ucf and would have an opportunity to change it. So the only sane thing to do is not change the default, ever. If the admin has not changed the config, dpkg and ucf will happily replace the old config with the new one, no questions asked, even when the config is in /etc. So no change there. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Sat, Dec 31, 2011 at 08:19:47PM +, Lars Wirzenius wrote: If the admin has not changed the config, dpkg and ucf will happily replace the old config with the new one, no questions asked, even when the config is in /etc. So no change there. Right. But if the sysadmin customizes any part of that configuration— even something completely unrelated—which is very likely, then he or she will be prompted. So if the defaults are fine, then the defaults are likely to be fine in the future. If the defaults are not fine, which often they are not, then the sysadmin will be prompted. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Sun, Jan 1, 2012 at 8:30 AM, brian m. carlson wrote: Right. But if the sysadmin customizes any part of that configuration— even something completely unrelated—which is very likely, then he or she will be prompted. So if the defaults are fine, then the defaults are likely to be fine in the future. If the defaults are not fine, which often they are not, then the sysadmin will be prompted. This is where Config::Model comes into play: http://wiki.debian.org/PackageConfigUpgrade -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GeA3CAtoDRLGsgmoOTYtUD3syYc4w30tqAg=yrir-...@mail.gmail.com
Re: from / to /usr/: a summary
On 12/31/2011 11:54 AM, Josh Triplett wrote: Almost all of those bug reports went away once udev moved the default location of distro-installed rules to /lib/udev/rules.d rather than /etc/udev/rules.d. Do you mean it went away, because in /usr/udev/rules.d it's not in /etc, which meaningfully says do not edit me, I'm not a conf file, which leads to admins having less issues (because refraining from hacking around)? By the way, .rpmnew files really sux indeed! :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4efffe16.5000...@goirand.fr
Re: from / to /usr/: a summary
On 01/01/2012 01:49 AM, brian m. carlson wrote: So the only sane thing to do is not change the default, ever. The other sane way is to mark files not in /etc as conffiles. It semantically sux a bit, but if we have no choice because of upstream decisions (which we don't have enough time to fix), then that might be a way... Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4efffed1.8070...@goirand.fr
Re: from / to /usr/: a summary
Thomas Goirand tho...@goirand.fr writes: On 01/01/2012 01:49 AM, brian m. carlson wrote: So the only sane thing to do is not change the default, ever. The other sane way is to mark files not in /etc as conffiles. It semantically sux a bit, but if we have no choice because of upstream decisions (which we don't have enough time to fix), then that might be a way... That doesn't help unless you expect sysadmins to change them (unchanged conffiles are quietly updated just like any other package file), at which point it becomes an FHS violation. -- 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 Archive: http://lists.debian.org/87y5tr28yx@windlord.stanford.edu
Re: from / to /usr/: a summary
Enrico Weigelt, 2011-12-30 06:21+0100:
Which packages ship files in /var ?
Many install directories there. And one of my packages, dokuwiki, also
installs files under /var/lib/dokuwiki/lib/{plugins,tpl}. These files
define the default set of bundled plugins and templates, and I install
them there so that the user can add other plugins or templates, which is
a very common case for DokuWiki administrators since one of the major
advantages of this wiki engine is its rich set of available plugins.
--
,--.
: /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar
| `-'Debian Maintainer
\_
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/jdk3gd$4pi$1...@dough.gmane.org
Re: from / to /usr/: a summary
On Thu, Dec 29, 2011 at 05:36:40PM -0800, Josh Triplett wrote: top-level directories would look after a move from / to /usr. Also, the FHS says nothing about the current approach of overriding files in /usr with files in /etc, which allows packages to stop shipping configuration files in /etc that just consist of the default settings. Every package which will accept a configuration file in /etc should ship such a file in /etc, even if it contains only comments. In this way, you know the name(s) of the configuration file(s) and the subdirectory in /etc where they belong. such as /bin, /sbin, /lib, /lib32, /lib64, and so on. However, consolidating all the package-managed bits in /usr would make it entirely sensible to share /usr as a single consistent pile of packaged bits. And where do you want to put the package information which are currently in /var? They do not belong to /usr. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Dec 30, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: Every package which will accept a configuration file in /etc should ship such a file in /etc, even if it contains only comments. In this This train has already passed and you lost it, sorry. And where do you want to put the package information which are currently in /var? They do not belong to /usr. They stay in /var, it does not matter for the interesting use cases. -- ciao, Marco signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On 30/12/11 12:48, Marco d'Itri wrote: On Dec 30, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: Every package which will accept a configuration file in /etc should ship such a file in /etc, even if it contains only comments. In this This train has already passed and you lost it, sorry. I think that stephan is right here. Every package using files in /etc should ship this files in the package in order to let the admin know what package each file belongs to. Its very ugly to do a dpkg -S /etc/xxx and get a no path found. If some package is not doing this I think is a mistake and should be fixed. -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Re: from / to /usr/: a summary
On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote: I think that stephan is right here. Every package using files in /etc It DOES NOT MATTER who is right, some upstreams have decided otherwise. At least udev, systemd and next month module-init-tools do override the configuration files in /usr/lib/ with the configuration files in /etc/. Deal with it. If some package is not doing this I think is a mistake and should be fixed. Fixing this creates a serious incompatibility with other distributions, so it is not an option. -- ciao, Marco signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote: On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote: I think that stephan is right here. Every package using files in /etc It DOES NOT MATTER who is right, some upstreams have decided otherwise. At least udev, systemd and next month module-init-tools do override the configuration files in /usr/lib/ with the configuration files in /etc/. Deal with it. Then udev and systemd are broken. You're introducing a dangerous inconsistency that's going to bite people. If some package is not doing this I think is a mistake and should be fixed. Fixing this creates a serious incompatibility with other distributions, so it is not an option. Fixing this preserves important consistency within the distribution. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Conffiles (was: from / to /usr/: a summary)
Carlos Alberto Lopez Perez, 2011-12-30 14:22+0100: I think that stephan is right here. Every package using files in /etc should ship this files in the package in order to let the admin know what package each file belongs to. Its very ugly to do a dpkg -S /etc/xxx and get a no path found. Not too problematic as long as that file has a name that make identification easy. I think having the default configuration values written in a default configuration file under /usr is better than having them harcoded, since it makes it really easier to determine what these defaults are. But not shipping the user configuration file, I do not know, that seems ugly somehow. At least the possibility to write a configuration file should be documented, ideally with a manpage. -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar | `-'Debian Maintainer \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jdkg5m$ija$1...@dough.gmane.org
Re: Conffiles (was: from / to /usr/: a summary)
On Fri, Dec 30, 2011 at 02:00:23PM +, Tanguy Ortolo wrote: I think having the default configuration values written in a default configuration file under /usr is better than having them harcoded, since it makes it really easier to determine what these defaults are. It's problematic if the defaults rely on the configuration file being present. From my experiences, I'd say it's best to ship the file with everything commented out. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Re: from / to /usr/: a summary
Stephan Seitz wrote: Every package which will accept a configuration file in /etc should ship such a file in /etc, even if it contains only comments. In this way, you know the name(s) of the configuration file(s) and the subdirectory in /etc where they belong. A de-facto standard has already emerged for how to ship the standard configuration in /usr/lib and handle overrides, which makes it quite straightforward to find configuration files in a package, add new configuration files, or override the standard configuration files: packages read /etc/$dir before /usr/lib/$dir, and /etc/$dir/$foo.conf overrides /usr/lib/$dir/$foo.conf. If you want to override /usr/lib/$dir/$foo.conf, copy it to /etc/$dir/$foo.conf and start editing. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111230150916.GA8957@leaf
Re: from / to /usr/: a summary
Josh Triplett, 2011-12-30 16:09+0100: A de-facto standard has already emerged for how to ship the standard configuration in /usr/lib and handle overrides, I do not think this is a de facto standard at all yet. What pieces of software use apply it? The length of that list should be compared to the order of magnitude of something like $(ls -1 /etc | wc -l) on a typical system before assuming that this has become the standard. The fact that a given piece of software is new or written by Lennart or whoever does not make its behaviour standard at all. The existence of a recommendation from IETF, LSB or XDG does, however. -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu irc://irc.oftc.net/Elessar | `-'Debian Maintainer \_ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jdkmvg$uut$1...@dough.gmane.org
Re: from / to /usr/: a summary
Josh Triplett, 2011-12-30 16:09+0100:
A de-facto standard has already emerged for how to ship the standard
configuration in /usr/lib and handle overrides,
I do not think this is a de facto standard at all yet. What pieces of
software use apply it? The length of that list should be compared to the
order of magnitude of something like $(ls -1 /etc | wc -l) on a typical
system before assuming that this has become the standard.
I didn't say that it had become as common as just having files in /etc;
I just suggested that programs which put their defaults outside of /etc
and allow overrides via /etc seem to follow a common approach which
makes them easy to find and override.
A quick check turned up the following software following the /usr/lib
with /etc override approach just on my own system:
- pm-utils
- PolicyKit
- ConsoleKit
- Parts of iceweasel
- Parts of Xorg
- systemd and its various helper components
- udev (modulo it currently using /lib rather than /usr/lib, but that
kind of thing started this whole thread in the first place)
The following packages have the same semantics, but use /usr/share
rather than /usr/lib, presumably because they don't consider their
default configurations architecture-specific:
- initramfs-tools
- TeX/LaTeX
- angband
- menu
- insserv
- defoma
- terminfo
- XKB
- calendar
My search also turned up a pile of other packages which *almost* manage
to follow this standard (default configuration in
/usr/{lib,share}/$package/ with overrides in /etc/$package/), but use
slight variations on naming between the files/directories in /usr and
the files/directories in /etc. Those kinds of inconsistencies really
ought to get fixed.
The fact that a given piece of software is new or written by Lennart
or whoever does not make its behaviour standard at all. The existence
of a recommendation from IETF, LSB or XDG does, however.
I said de-facto standard for a reason; that means precisely the
opposite of standards produced by the organizations you mentioned.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111231000954.GA11680@leaf
Re: Conffiles (was: from / to /usr/: a summary)
* Tanguy Ortolo tanguy+deb...@ortolo.eu schrieb: I think having the default configuration values written in a default configuration file under /usr is better than having them harcoded, since it makes it really easier to determine what these defaults are. But not shipping the user configuration file, I do not know, that seems ugly somehow. At least the possibility to write a configuration file should be documented, ideally with a manpage. I have a general objection against putting (default) configs outside /etc at all. The main problem is, on updates, defaults might silently change, without operators used to look at /etc and comparing current config with new defaults. Not sure how Debian handles this, but Gentoo's etc-update mechanism has shown to be very handy. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111231024024.ga30...@mailgate.onlinehome-server.info
Re: from / to /usr/: a summary
* Carlos Alberto Lopez Perez clo...@igalia.com schrieb: I think that stephan is right here. Every package using files in /etc should ship this files in the package in order to let the admin know what package each file belongs to. Its very ugly to do a dpkg -S /etc/xxx and get a no path found. If some package is not doing this I think is a mistake and should be fixed. ACK. And it's then the job of the package manager to handle the config files properly (eg. not simply overwriting them on on updates, instead put them to some proper location where the admin or an admin-tool can pick them up) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111231024734.gb30...@mailgate.onlinehome-server.info
Re: from / to /usr/: a summary
* Tanguy Ortolo tanguy+deb...@ortolo.eu schrieb:
Enrico Weigelt, 2011-12-30 06:21+0100:
Which packages ship files in /var ?
Many install directories there. And one of my packages, dokuwiki, also
installs files under /var/lib/dokuwiki/lib/{plugins,tpl}. These files
define the default set of bundled plugins and templates, and I install
them there so that the user can add other plugins or templates, which is
a very common case for DokuWiki administrators since one of the major
advantages of this wiki engine is its rich set of available plugins.
IMHO this is completely wrong, those files should be under
/usr/lib/... or maybe even /usr/share/... as they're not
dynamic data.
I'd split off package install and instance deployment
(as soon as you want several dokuwiki instances on one
host, that will be needed anyways).
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20111231025510.gc30...@mailgate.onlinehome-server.info
Re: from / to /usr/: a summary
* Adam Borowski kilob...@angband.pl schrieb: On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote: On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote: I think that stephan is right here. Every package using files in /etc It DOES NOT MATTER who is right, some upstreams have decided otherwise. At least udev, systemd and next month module-init-tools do override the configuration files in /usr/lib/ with the configuration files in /etc/. Deal with it. Then udev and systemd are broken. You're introducing a dangerous inconsistency that's going to bite people. ACK. Sometimes upstreams doing really stange things (maybe because they dont have any package management in mind), that should be fixed. If upstream doesnt do those fixes, distros have to catch in. Look, the purpose of distros is to provide an consistent, robust and mainainable environment. Sometimes the distro maintainers have to bite in the bitter apple and cleanup upstreams's dirt. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111231025922.gd30...@mailgate.onlinehome-server.info
Re: Conffiles (was: from / to /usr/: a summary)
Enrico Weigelt wrote: * Tanguy Ortolo tanguy+deb...@ortolo.eu schrieb: I think having the default configuration values written in a default configuration file under /usr is better than having them harcoded, since it makes it really easier to determine what these defaults are. But not shipping the user configuration file, I do not know, that seems ugly somehow. At least the possibility to write a configuration file should be documented, ideally with a manpage. I have a general objection against putting (default) configs outside /etc at all. The main problem is, on updates, defaults might silently change, without operators used to look at /etc and comparing current config with new defaults. By default, dpkg will silently upgrade unmodified conffiles to the current version, without prompting the user at all. If you've modified the conffile, dpkg will prompt you to find out if you want to keep your modified version, upgrade to the new upstream version, see a diff, or run a shell; dpkg will default to keeping your modified version. So, unless you've changed a configuration file, you already won't get a prompt on configuration upgrades. If the configuration upgrade might matter to sysadmins, the Debian package should provide an upgrade note in NEWS.Debian, or upstream should provide a note in NEWS (which I wish apt-listchanges could show, at least when it follows a standard format). - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111231033650.GA15689@leaf
Re: from / to /usr/: a summary
On Sat, Dec 31, 2011 at 12:59 AM, Enrico Weigelt weig...@metux.de wrote: * Adam Borowski kilob...@angband.pl schrieb: On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote: On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote: I think that stephan is right here. Every package using files in /etc It DOES NOT MATTER who is right, some upstreams have decided otherwise. At least udev, systemd and next month module-init-tools do override the configuration files in /usr/lib/ with the configuration files in /etc/. Deal with it. Then udev and systemd are broken. You're introducing a dangerous inconsistency that's going to bite people. ACK. Sometimes upstreams doing really stange things (maybe because they dont have any package management in mind), that should be fixed. If upstream doesnt do those fixes, distros have to catch in. Look, the purpose of distros is to provide an consistent, robust and mainainable environment. Sometimes the distro maintainers have to bite in the bitter apple and cleanup upstreams's dirt. Are you guys applying for maintainership for this huge delta you want to introduce between upstream and us? Are you becoming new, reputable upstreams for that forked software? If not, please refrain from telling people what to do. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa92t4N5zrWm=UX=PO1f19X=ykqvyb9szdo1cq7bhrk...@mail.gmail.com
Re: from / to /usr/: a summary
Enrico Weigelt wrote: * Adam Borowski kilob...@angband.pl schrieb: On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote: On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote: I think that stephan is right here. Every package using files in /etc It DOES NOT MATTER who is right, some upstreams have decided otherwise. At least udev, systemd and next month module-init-tools do override the configuration files in /usr/lib/ with the configuration files in /etc/. Deal with it. Then udev and systemd are broken. You're introducing a dangerous inconsistency that's going to bite people. ACK. Sometimes upstreams doing really stange things (maybe because they dont have any package management in mind), that should be fixed. If upstream doesnt do those fixes, distros have to catch in. The numerous upstreams which follow this model introduced it specifically *because* of distributions and package management, which they specifically had in mind as a design constraint. The search path behavior, along with the consistent use of .d directories, allows a clean distinction between upstream configuration, vendor/distribution configuration (any changes Debian wants to make to the defaults), sysadmin overrides of the defaults, and sysadmin configuration building on the defaults, without forcing sysadmins to perform manual three-way merges every time they upgrade. The upstream defaults live outside of /etc specifically because *they don't normally represent configuration intended for the sysadmin to change*. Before udev moved the default rules to /lib/udev, udev received a large number of bug reports caused by an incorrect set of udev rules in /etc. Sysadmins would make a local hack and then not accept new upstream rule changes, or packages would delete outdated rules but the conffiles would stick around and break things, or various other fun and exciting brokenness. Almost all of those bug reports went away once udev moved the default location of distro-installed rules to /lib/udev/rules.d rather than /etc/udev/rules.d. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111231035432.GA15712@leaf
Re: from / to /usr/: a summary
Fernando Lemos fernando...@gmail.com writes: Enrico Weigelt weig...@metux.de wrote: ACK. Sometimes upstreams doing really stange things (maybe because they dont have any package management in mind), that should be fixed. If upstream doesnt do those fixes, distros have to catch in. Sometimes, I think Red Hat makes some of these design decisions because RPM's handling of configuration files sucks. If it had always behaved like dpkg, I wonder if they wouldn't use designs that honor configuration files somewhat more. Are you guys applying for maintainership for this huge delta you want to introduce between upstream and us? Are you becoming new, reputable upstreams for that forked software? If not, please refrain from telling people what to do. This, however, is a really good point, and is the thing that keeps running through the back of my head reading this thread. There seems to be a lot of sentiment that people wish udev (in particular) would work differently and better integrate with a split / and /usr with only / being mounted during boot. But it's worth keeping in mind 2.1.1 of the constitution: you can't make people in the project do work they don't want to do. Clearly, Marco is not interested in maintaining this sort of substantial fork of upstream udev. In fact, one of his primary points in this discussion is that this is a ton of work for (at least in his opinion, and I think he has a credible prima facie case, if not a universally persuasive one) somewhat marginal benefit and it's not work he's interested in doing. People can't just tell him no, you have to go do that work; if it's so important to Debian to go a different direction than udev's upstream, that means Debian will need to fork it, which probably means *someone in this thread* is going to have to fork it. So who's volunteering to be the new udev upstream? (And, really, don't we have enough work to do that isn't getting done because we don't have enough people?) Note that Steve's point, namely that he (if I'm reading him right) thinks that the upstream changes are being overstated and that upstream's direction isn't actually going to cause problems for us, is an entirely separate one and not something I'm addressing in the above. And is certainly something to explore before we start arguing over who's going to fork something that may not be an issue at all. -- 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 Archive: http://lists.debian.org/87fwg1e5x5@windlord.stanford.edu
Re: from / to /usr/: a summary
On Mon, Dec 26, 2011 at 05:23:56PM -0800, Steve Langasek wrote: On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote: Not quite. Redhat and others want to make this change (moving binaries and libraries from / into /usr) not just for ease of maintenance (though that makes sense too) but for several rather interesting reasons. It would consolidate almost everything managed by the package manager under /usr. That's not interesting at all. Sorry you don't find it interesting. Other people do. In any case, I primarily wanted to explain the rationale, which went beyond the upstream being difficult repeated by others in the thread. Configuration would live in /etc (with templates possibly provided by packages, though more and more packages follow the override files in /usr with files in /etc approach and ship no /etc configuration by default). That's the FHS and has nothing to do with moving things. Well aware of that; just trying to fill in the full picture of how the top-level directories would look after a move from / to /usr. Also, the FHS says nothing about the current approach of overriding files in /usr with files in /etc, which allows packages to stop shipping configuration files in /etc that just consist of the default settings. /var includes bits that change, which should not normally include package-managed bits. That's also in the FHS. Again, well aware of that; just trying to fill in the full picture of how the top-level directories would look after a move from / to /usr. Also, nothing in the FHS states that packages shouldn't ship files in /var. This would make /usr easy to snapshot, easy to exclude from backups, easy to share between systems, easy to mark read-only (mount --bind -o ro /usr /usr) and various other fun possibilities. I don't think /bin, /sbin, and /lib are seriously blocking anyone from doing any of these things today. /bin, /sbin, /lib, /lib32, /lib64, and package-managed files in /var and /etc make these things significantly less convenient. More to the point, all of those directories (as well as /usr) exist as top-level directories right next to /home, /tmp, /lost+found, /media, and others which often require different treatment. Right now, all of the activities I mentioned require careful inclusion/exclusion rules: either include /, except exclude a pile of top-level directories or include a pile of explicitly listed top-level directories. Personally, I'd find it rather convenient to have all of that consolidated in /usr. So would the upstreams of various packages, hence this thread. Indeed, people have consistently argued in this thread that /usr shared over NFS is not a useful thing to try to do these days, and there's nothing about adding /bin, /sbin, and /lib to /usr that changes these arguments. People have consistently argued that sharing /usr makes no sense without also sharing all the other package-managed bits that live outside /usr, such as /bin, /sbin, /lib, /lib32, /lib64, and so on. However, consolidating all the package-managed bits in /usr would make it entirely sensible to share /usr as a single consistent pile of packaged bits. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111230013640.GA4475@leaf
Re: from / to /usr/: a summary
* Josh Triplett j...@joshtriplett.org schrieb: Well aware of that; just trying to fill in the full picture of how the top-level directories would look after a move from / to /usr. Also, the FHS says nothing about the current approach of overriding files in /usr with files in /etc, which allows packages to stop shipping configuration files in /etc that just consist of the default settings. Actualy, I'm opposed to putting default config files somewhere else from operating perspective. Having the initial configs in /etc is much easier when installing and then reconfiguring a package (it's already obvious where to look for the config file, and with proper comments you easily know what you might have to adapt). Not sure how Debian handles this, but Gentoo has a wonderful tool called etc-update for managing config file updates. Again, well aware of that; just trying to fill in the full picture of how the top-level directories would look after a move from / to /usr. Also, nothing in the FHS states that packages shouldn't ship files in /var. Which packages ship files in /var ? /bin, /sbin, /lib, /lib32, /lib64, and package-managed files in /var and /etc make these things significantly less convenient. More to the point, all of those directories (as well as /usr) exist as top-level directories right next to /home, /tmp, /lost+found, /media, and others which often require different treatment. Are there any packages installing something in /home, /tmp, /lost+found or /media ? People have consistently argued that sharing /usr makes no sense without also sharing all the other package-managed bits that live outside /usr, such as /bin, /sbin, /lib, /lib32, /lib64, and so on. However, consolidating all the package-managed bits in /usr would make it entirely sensible to share /usr as a single consistent pile of packaged bits. I personally haven't seen an installation where /usr is actually shared between separate hosts, I don't have a real position on that. But: /usr is meant for things that are not needed by an minimal bootup, eg. singleuser or fundamental networking only (ip-stack + sshd), so they can be splitted to separate media, eg. for emergency cases. For completey fresh installations, there are probably better ways for providing remote recovery (eg. large hosters have rescue boot), maybe even using containers etc. But the big problem are the uncountable existing systems which might become troublemakers with that change. We need practical and reliable migration strategies first. In the end, I'm curious if it's really worth all of this. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111230052144.ga25...@mailgate.onlinehome-server.info
Re: from / to /usr/: a summary
On Tue, Dec 27, 2011 at 08:54:29AM +0100, Josselin Mouette wrote: Le mardi 27 décembre 2011 à 08:53 +0100, Josselin Mouette a écrit : Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit : If someone would give even *one* example where something legitimately needed by a udev rule could not be moved from /usr to / without breaking interfaces or otherwise complicating matters, then that would be worth discussing. Grah. I mean introducing a udev rule that calls a D-Bus service, of course. And which D-Bus service has to be called at a early boot stage, that it can’t wait until we are leaving single user mode? Udev doesn’t seem to have a trigger database where rules that are not able to run now can insert information, so that udev can execute these rules if they can be run. But this is a bug in udev, not a reason to force people to reconfigure their systems. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Tue, Dec 27, 2011 at 08:35:06AM +0100, Bernhard R. Link wrote: * Andrey Rahmatullin w...@wrar.name [111227 07:53]: On Mon, Dec 26, 2011 at 06:59:07PM +0100, Bernhard R. Link wrote: It is a good thing to run with minimum privs, but compiling a new kernel to support this seems to be a lot of work for a fairly small benefit. First of all it is quite a significant benefit. And you get quite some other advantages like being able to boot faster and needing less memory, both RAM and on disc. [citation needed] This is not wikipedia. Things obviously true do not need a citation. But they are not obviously true. -- WBR, wRAR signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Tue, Dec 27, 2011 at 08:53:10AM +0100, Josselin Mouette wrote: Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit : If someone would give even *one* example where something legitimately needed by a udev rule could not be moved from /usr to / without breaking interfaces or otherwise complicating matters, then that would be worth discussing. Introducing a udev rule that calls a [D-Bus] service? Do you have a concrete example of how this would be a useful thing to do? So far I haven't seen the need for it. Describing things that you *could* do from udev if /usr could be relied on doesn't explain for why we would *want* to do it that way. Also, doesn't launching a dbus service presuppose that dbus-daemon itself is running? This sounds like we would be making udev depend on socket-based service activation to support this (in order to ensure the system bus is running when udev needs it). I'm skeptical of the robustness of such an approach. For one thing, what if there's disk thrashing at boot time on a slow system that causes the socket-activated dbus-daemon to exceed udev's worker timeout? (Note that for this reason, upstart in Ubuntu exclusively uses the upstart-udev-bridge to represent such long-running triggers as upstart jobs keyed on certain udev events, and *not* as udev rules.) -- 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 signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Sun, Dec 25, 2011 at 12:08:57PM +, Philipp Kern wrote: On 2011-12-25, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: All admins I know have at least some servers with custom kernels (in the past it was said, to build your firewall/server kernels without module support, so that no rootkit module could be loaded). No longer needed. See /proc/sys/kernel/modules_disabled. That's not equivalent - an attacker that can load modules can also remove the init script that sets this variable to 1 and reboot the machine. For proper safeguarding you still want no module support in the kernel at all. regards, iustin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111226103810.ga1...@teal.hq.k1024.org
Re: from / to /usr/: a summary
On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote: All admins I know have at least some servers with custom kernels (in the past it was said, to build your firewall/server kernels without module support, so that no rootkit module could be loaded). No longer needed. See /proc/sys/kernel/modules_disabled. That's not equivalent - an attacker that can load modules can also remove the init script that sets this variable to 1 and reboot the machine. Why can't the same attacker replace the kernel? For proper safeguarding you still want no module support in the kernel at all. regards, iustin -- WBR, wRAR signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote: On Sun, Dec 25, 2011 at 12:08:57PM +, Philipp Kern wrote: On 2011-12-25, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: All admins I know have at least some servers with custom kernels (in the past it was said, to build your firewall/server kernels without module support, so that no rootkit module could be loaded). No longer needed. See /proc/sys/kernel/modules_disabled. That's not equivalent - an attacker that can load modules can also remove the init script that sets this variable to 1 and reboot the machine. For proper safeguarding you still want no module support in the kernel at all. Sorry, but what kind of argumentation is that? If the admin doesn't notice reboots and/or file tampering, I could just replace the kernel with my modified one and reboot. Now of course you could increase your paranoia and boot the kernel from an immutable disc. But then I'd just load all relevant modules in the initramfs and set modules_disabled there instead of doing custom built kernels just to get rid of modules. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Mon, Dec 26, 2011 at 04:42:45PM +0600, Andrey Rahmatullin wrote: On Mon, Dec 26, 2011 at 11:38:10AM +0100, Iustin Pop wrote: All admins I know have at least some servers with custom kernels (in the past it was said, to build your firewall/server kernels without module support, so that no rootkit module could be loaded). No longer needed. See /proc/sys/kernel/modules_disabled. That's not equivalent - an attacker that can load modules can also remove the init script that sets this variable to 1 and reboot the machine. Why can't the same attacker replace the kernel? On Mon, Dec 26, 2011 at 12:01:43PM +0100, Philipp Kern wrote: For proper safeguarding you still want no module support in the kernel at all. Sorry, but what kind of argumentation is that? If the admin doesn't notice reboots and/or file tampering, I could just replace the kernel with my modified one and reboot. Now of course you could increase your paranoia and boot the kernel from an immutable disc. But then I'd just load all relevant modules in the initramfs and set modules_disabled there instead of doing custom built kernels just to get rid of modules. For both of you: for virtualised environments where the kernel is loaded from the hypervisor. Yes, doing the initrd from the hypervisor helps too, but the problem with that setting is that it defaults to 0 and has to be switched to 1. Whereas a kernel with no module support defaults to 0. regards, iustin signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Mon, 26 Dec 2011, Iustin Pop ius...@debian.org wrote: No longer needed. See /proc/sys/kernel/modules_disabled. That's not equivalent - an attacker that can load modules can also remove the init script that sets this variable to 1 and reboot the machine. For many of the things that can be done by loading a kernel module an attacker can achieve similar goals by replacing libc or by using ptrace to install hostile code in a long-running process that runs as root. Even if booting such a kernel prevented an attacker from hiding files and processes (and the other things that a kernel module might do) it still wouldn't provide a significant benefit. It's possible that an attacker might get root on your system via a script but lack the knowledge to do anything else effective if the script that loads a kernel module fails. It is a good thing to run with minimum privs, but compiling a new kernel to support this seems to be a lot of work for a fairly small benefit. I can think of one local root exploit that involved triggering a module load, one of the possible ways of preventing that exploit would be to disable module loading. But it seems to me that a more useful feature would be the ability to create a white-list of which modules can be loaded to solve the problem of unwanted triggers for module loading and the problem of buggy kernel modules being autoloaded in response to something an attacker did. If we had some module management tools that made this easy then it would be a good thing. For example it would be good to be able to white list the currently loaded modules (and optionally remove some from the white-list for hardware that is installed but never used) and then make a small white-list for the USB devices that are suitable for use. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112270015.47265.russ...@coker.com.au
Re: from / to /usr/: a summary
On Dec 26, Russell Coker russ...@coker.com.au wrote: For many of the things that can be done by loading a kernel module an attacker can achieve similar goals by replacing libc or by using ptrace to install hostile code in a long-running process that runs as root. Or load code in the kernel using /dev/mem, preventing loading modules only stops simple attacks. For example it would be good to be able to white list the currently loaded modules (and optionally remove some from the white-list for hardware that is installed but never used) and then make a small white-list for the USB devices that are suitable for use. You can easily do this with a udev rules file. -- ciao, Marco signature.asc Description: Digital signature
Re: from / to /usr/: a summary
* Philipp Kern pk...@debian.org [111226 12:02]: Sorry, but what kind of argumentation is that? If the admin doesn't notice reboots and/or file tampering, I could just replace the kernel with my modified one and reboot. Now of course you could increase your paranoia and boot the kernel from an immutable disc. But then I'd just load all relevant modules in the initramfs and set modules_disabled there instead of doing custom built kernels just to get rid of modules. As you pointed out so nicely: modules_disabled is only a replacement if you have a custom initramfs and do not allow that to be modified automatically. So from the point of the original discussion, modules_disabled is no solution. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111226180337.gb2...@server.brlink.eu
Re: from / to /usr/: a summary
* Russell Coker russ...@coker.com.au [111226 14:16]: For many of the things that can be done by loading a kernel module an attacker can achieve similar goals by replacing libc or by using ptrace to install hostile code in a long-running process that runs as root. Except replacing libc does not help against static binaries and here are well known ways to disallow ptrace. Even if booting such a kernel prevented an attacker from hiding files and processes (and the other things that a kernel module might do) it still wouldn't provide a significant benefit. Not being able to hide files and being able to notice file modifications is no benefit? It is a good thing to run with minimum privs, but compiling a new kernel to support this seems to be a lot of work for a fairly small benefit. First of all it is quite a significant benefit. And you get quite some other advantages like being able to boot faster and needing less memory, both RAM and on disc. But it seems to me that a more useful feature would be the ability to create a white-list of which modules can be loaded to solve the problem of unwanted triggers for module loading and the problem of buggy kernel modules being autoloaded in response to something an attacker did. If we had some module management tools that made this easy then it would be a good thing. For example it would be good to be able to white list the currently loaded modules (and optionally remove some from the white-list for hardware that is installed but never used) and then make a small white-list for the USB devices that are suitable for use. Feel free to implement this. But please stop telling people that what they do should not be supported just because you would do it differently or there might be some better vapourware solution. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111226175853.ga2...@server.brlink.eu
Re: from / to /usr/: a summary
On 12/22/2011 07:19 PM, Philip Hands wrote: I'm still yet to understand the significant upsides of this proposal So far, the only upside that has been written here, if I understand well, is less patches for upstream udev, which is important since we don't have enough people to work on alternatives/fork/patches. While I understand we have a limited amount of people willing to work on udev maintenance, I'd like to know if there is even a limit on how much crap we can accept from upstream. udev has nearly broken-up our Lenny to Squeeze upgrade path, and made it impossible to run recent Ubuntu with a Lenny kernel (which was, for a while, quite problematic when running virtual machines for me, and really annoying for upgrades). Now, this mess, which frankly, nobody needs, and with only downsides. How long are we going to accept such mess? How much crap is Debian ready to accept from upstream udev without declaring it a broken development? Do we really have to just accept shit from udev by RedHat without being able to say anything, or are there alternative path? Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ef8bb45.6020...@debian.org
Re: from / to /usr/: a summary
On 12/22/2011 05:50 PM, Marco d'Itri wrote: The main objections so far can be summarized as I like to do thing my way and changes make me unconfortable. No, the main objection is: I have already many systems/servers in production already. Please don't break them. I don't mind if using an initramfs is required, I don't mind if this initramfs mounts my /usr if it can/wants to, but my system should continue to boot. Especially if you consider that few years ago (that was truth for sarge, right?), using a separate / not on the LVM was the only solution for booting. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ef8be3d.8050...@debian.org
Re: from / to /usr/: a summary
On 12/09/2011 03:21 PM, Goswin von Brederlow wrote: As I mentioned I have a bug open (in the grml bug tracker) about providing a grml.deb. That would install an image in /boot and add itself to the bootloader. The small grml image is more like 180MB than 25-50MB but it is a verry good rescue system. And harddisk space is usualy cheap. That'd be great, and I'd use it! :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ef8c3fb.1050...@debian.org
Re: from / to /usr/: a summary
On Dec 26, Thomas Goirand z...@debian.org wrote: On 12/22/2011 07:19 PM, Philip Hands wrote: I'm still yet to understand the significant upsides of this proposal So far, the only upside that has been written here, if I understand well, is less patches for upstream udev, which is important since we don't have enough people to work on alternatives/fork/patches. No, it's not about patches. More and more things just need /usr at boot time, and the solution is to mount it in the initramfs. The only alternative would be to keep moving stuff from /usr to /, which kind of defeats its purpose. Also, mounting /usr in the initramfs allows to explore the / to /usr move, which if practical will bring many benefits and allow supporting new features. -- ciao, Marco signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Mon, 26 Dec 2011 20:25:12 +0100, m...@linux.it (Marco d'Itri) wrote: On Dec 26, Thomas Goirand z...@debian.org wrote: On 12/22/2011 07:19 PM, Philip Hands wrote: I'm still yet to understand the significant upsides of this proposal So far, the only upside that has been written here, if I understand well, is less patches for upstream udev, which is important since we don't have enough people to work on alternatives/fork/patches. No, it's not about patches. More and more things just need /usr at boot time, and the solution is to mount it in the initramfs. I presume that you mean that they need /usr early enough in the boot that we'll not have a chance to mount it as we do now because of entangled dependencies. Perhaps you could spell out some examples of what you mean, so people can judge whether they share your perception. The only alternative would be to keep moving stuff from /usr to /, which kind of defeats its purpose. Quite. Doing that would certainly not help those of us who seem to think that it might be nice to keep to the small / they have on some systems. Also, mounting /usr in the initramfs allows to explore the / to /usr move, which if practical will bring many benefits and allow supporting new features. Again, if you could perhaps go into some more details it might allow people to gain a greater understanding of the benefits you envisage. Cheers, Phil. P.S. I'm mostly persuaded by the initramfs approach, but I note that several others seem not to be, and noticed that you were again just stating that there are advantages, which I presume means that you see them as so obvious that there's no need to enumerate them -- I just think you might be more persuasive if you did. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpCN5DtDb5mC.pgp Description: PGP signature
Re: from / to /usr/: a summary
On 26/12/11 14:15, Russell Coker wrote: But it seems to me that a more useful feature would be the ability to create a white-list of which modules can be loaded to solve the problem of unwanted triggers for module loading and the problem of buggy kernel modules being autoloaded in response to something an attacker did. If we had some module management tools that made this easy then it would be a good thing. For example it would be good to be able to white list the currently loaded modules (and optionally remove some from the white-list for hardware that is installed but never used) and then make a small white-list for the USB devices that are suitable for use. https://lwn.net/Articles/470906/ -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Re: from / to /usr/: a summary
On Sat, Dec 24, 2011 at 07:03:10PM +0800, Paul Wise wrote: I'd still like to know what the compelling reason for the change is though. Apparently the reason is simply that our upstreams (who it sounds like are predominantly driven by Redhat folks) are dropping support for / and /usr on different partitions and that re-adding that support or maintaining the existing support is too much work for the Debian maintainers involved. At least that is what started the thread. Things like this is why getting involved upstream is important for Debian maintainers and probably why items 2 and 4 exist in our social contract. I would encourage those who care about this issue to start getting involved in the relevant places and submitting patches. It sounds like the ability to run a system with split / and /usr is *very* likely to disappear unless people who care decide to work in it. I don't think that sounds very likely at all, because so far *no one* has provided *any* evidence in this thread, or in any upstream discussions I've been able to find, of any regressions that would be introduced into Debian by upstream's not supporting starting udev before mounting /usr. It's too much work to move the libraries to /lib is nonsense and no justification at all. Our build systems don't make installing libraries to /lib as easy as they should, but it's not actually difficult, and no one who finds this genuinely difficult has any business being the maintainer of a library so core that it's needed at boot time by the system anyway. It's certainly far less work for the handful of affected libraries to be moved than it is to make countless users repartition their systems! The one and only example I've ever seen of an upstream decision that would impact the bootability of existing initramfsless systems with a separate /usr was a udev rule that would inject name information from /usr/share/misc/pci.ids into the udev database, *for consumption by other applications*. This would be a gratuitous incompatibility; no one appeared to be arguing that this information needed to be there for the benefit of udev itself. But I believe the decision has since been reversed upstream anyway. If someone would give even *one* example where something legitimately needed by a udev rule could not be moved from /usr to / without breaking interfaces or otherwise complicating matters, then that would be worth discussing. But so far, nobody has done so - having to move shared libraries between directories certainly doesn't qualify - so I continue to regard this as just so much upstream FUD. On Sat, Dec 24, 2011 at 08:00:50PM +0800, Paul Wise wrote: The package that started the thread was udev, there are examples of libs that need to be in /lib in the beginning of #652011. Yes, and it's a rather short list. I'll be happy to provide patches for these packages. On Mon, Dec 26, 2011 at 08:25:12PM +0100, Marco d'Itri wrote: No, it's not about patches. More and more things just need /usr at boot time, and the solution is to mount it in the initramfs. The only alternative would be to keep moving stuff from /usr to /, which kind of defeats its purpose. I don't agree that it defeats the purpose to move libraries needed at boot time to /; I think that given the wide range of uses to which Debian is put, it's important for us to be disciplined about the size of our base system and our startup, and keeping track of the libs in /lib is one tool that helps with this. So rather than defeating the purpose, I would say that requiring libs used in early boot to move to /lib provides a useful deterrent against growing the system unnecessarily. Also, mounting /usr in the initramfs allows to explore the / to /usr move, which if practical will bring many benefits and allow supporting new features. I think I've heard of one new feature, full-filesystem snapshotting, that this would enable. I can see that this would be useful and that some people may want to do it, and that this is worth exploring; I only object to requiring people to choose between /usr as a separate partition and initramfsless booting if it's not necessary. -- 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 signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote: Not quite. Redhat and others want to make this change (moving binaries and libraries from / into /usr) not just for ease of maintenance (though that makes sense too) but for several rather interesting reasons. It would consolidate almost everything managed by the package manager under /usr. That's not interesting at all. Configuration would live in /etc (with templates possibly provided by packages, though more and more packages follow the override files in /usr with files in /etc approach and ship no /etc configuration by default). That's the FHS and has nothing to do with moving things. /var includes bits that change, which should not normally include package-managed bits. That's also in the FHS. This would make /usr easy to snapshot, easy to exclude from backups, easy to share between systems, easy to mark read-only (mount --bind -o ro /usr /usr) and various other fun possibilities. I don't think /bin, /sbin, and /lib are seriously blocking anyone from doing any of these things today. Indeed, people have consistently argued in this thread that /usr shared over NFS is not a useful thing to try to do these days, and there's nothing about adding /bin, /sbin, and /lib to /usr that changes these arguments. -- 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 signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On 2011-12-26, Bernhard R. Link brl...@debian.org wrote: * Philipp Kern pk...@debian.org [111226 12:02]: Sorry, but what kind of argumentation is that? If the admin doesn't notice reboots and/or file tampering, I could just replace the kernel with my modified one and reboot. Now of course you could increase your paranoia and boot the kernel from an immutable disc. But then I'd just load all relevant modules in the initramfs and set modules_disabled there instead of doing custom built kernels just to get rid of modules. As you pointed out so nicely: modules_disabled is only a replacement if you have a custom initramfs and do not allow that to be modified automatically. So from the point of the original discussion, modules_disabled is no solution. You just stuff a file into /etc/initramfs-tools/local-bottom and regenerate the initramfs. I think that's much less effort than recompiling the kernel with the right bits built-in. I'll grant the boot the kernel from the outside bit, but then I could just kexec into my new kernel, if the admin wasn't careful enough. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjfidce.2qr.tr...@kelgar.0x539.de
Re: from / to /usr/: a summary
On Mon, Dec 26, 2011 at 06:59:07PM +0100, Bernhard R. Link wrote: It is a good thing to run with minimum privs, but compiling a new kernel to support this seems to be a lot of work for a fairly small benefit. First of all it is quite a significant benefit. And you get quite some other advantages like being able to boot faster and needing less memory, both RAM and on disc. [citation needed] -- WBR, wRAR signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Mon, 2011-12-26 at 22:17 +, Philip Hands wrote: On Mon, 26 Dec 2011 20:25:12 +0100, m...@linux.it (Marco d'Itri) wrote: On Dec 26, Thomas Goirand z...@debian.org wrote: On 12/22/2011 07:19 PM, Philip Hands wrote: I'm still yet to understand the significant upsides of this proposal So far, the only upside that has been written here, if I understand well, is less patches for upstream udev, which is important since we don't have enough people to work on alternatives/fork/patches. No, it's not about patches. More and more things just need /usr at boot time, and the solution is to mount it in the initramfs. I presume that you mean that they need /usr early enough in the boot that we'll not have a chance to mount it as we do now because of entangled dependencies. Perhaps you could spell out some examples of what you mean, so people can judge whether they share your perception. [...] /usr may require NFS, which requires networking, which may require crda, which requires: $ ldd /sbin/crda linux-gate.so.1 = (0xf7762000) libssl.so.1.0.0 = /usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.0 (0xf76f9000) libcrypto.so.1.0.0 = /usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.0 (0xf754b000) libnl.so.1 = /usr/lib/i386-linux-gnu/libnl.so.1 (0xf74fa000) libc.so.6 = /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xf73a) libdl.so.2 = /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xf739c000) libz.so.1 = /usr/lib/libz.so.1 (0xf7388000) libm.so.6 = /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xf7362000) /lib/ld-linux.so.2 (0xf7763000) Oh well, hopefully no-one actually expects that to work. Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Re: from / to /usr/: a summary
* Andrey Rahmatullin w...@wrar.name [111227 07:53]: On Mon, Dec 26, 2011 at 06:59:07PM +0100, Bernhard R. Link wrote: It is a good thing to run with minimum privs, but compiling a new kernel to support this seems to be a lot of work for a fairly small benefit. First of all it is quite a significant benefit. And you get quite some other advantages like being able to boot faster and needing less memory, both RAM and on disc. [citation needed] This is not wikipedia. Things obviously true do not need a citation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111227073506.ga2...@server.brlink.eu
Re: from / to /usr/: a summary
Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit : If someone would give even *one* example where something legitimately needed by a udev rule could not be moved from /usr to / without breaking interfaces or otherwise complicating matters, then that would be worth discussing. Introducing a udev rule that calls a udev service? -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: from / to /usr/: a summary
Le mardi 27 décembre 2011 à 08:53 +0100, Josselin Mouette a écrit : Le lundi 26 décembre 2011 à 17:08 -0800, Steve Langasek a écrit : If someone would give even *one* example where something legitimately needed by a udev rule could not be moved from /usr to / without breaking interfaces or otherwise complicating matters, then that would be worth discussing. Introducing a udev rule that calls a udev service? Grah. I mean introducing a udev rule that calls a D-Bus service, of course. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: from / to /usr/: a summary
* Philipp Kern tr...@philkern.de [111227 04:04]:
As you pointed out so nicely: modules_disabled is only a replacement if
you have a custom initramfs and do not allow that to be modified
automatically. So from the point of the original discussion,
modules_disabled is no solution.
You just stuff a file into /etc/initramfs-tools/local-bottom and regenerate
the
initramfs. I think that's much less effort than recompiling the kernel with
the right bits built-in.
Building a custom kernel is almost no efford at all. Building a minimal
one is a bit more efford.
But that part is exactly the same as needed for creating a
local-bottom: You have to know which modules you need to load before
disabling modules.
And what use is a /etc/initramfs-tools handling if you cannot create the
initramfs on the system or you would defeat the security?
You could argue as well that people wanting a kernel without initramsfs
have no problem with /usr to be mounted early, they just have to write
some parts into the correct part of /etc/rcS to have /usr mounted before
anything else is done.
I'll grant the boot the kernel from the outside bit, but then I could just
kexec into my new kernel, if the admin wasn't careful enough.
Kexec will of course not work. Otherwise there was something done
horribly wrong (like forgetting to patch out {k,}mem).
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111227074445.gb2...@server.brlink.eu
Re: from / to /usr/: a summary
On 12/22/2011 07:07 PM, Russell Coker wrote: It seems to me that wanting to have / outside LVM but /usr inside LVM is a fairly obscure corner case. I have about 100 servers setup this way, and my laptops as well. I really don't see why this would be a corner case. Please understand that many different people have many different configuration, and that in today's Debian, *absolutely everything is allowed*, and never, ever, Debian said that one type of setup would one day be forbidden. Taking decisions that some setup are not supported would be a bad move whatever the partitioning we are talking about. Please don't do that, there's no reason why Debian would take such move. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ef6db00.9040...@debian.org
Re: from / to /usr/: a summary
]] Philip Hands I used to use mondo-rescue for ensuring that systems were rescue-able. The problem is that on production systems one quite often never gets given the chance to test if the rescue system still works, so I ended up abandoning the use of mondo because it happened to me often enough that the hardware had been replaced under the OS, and some change that was required to support the new hardware didn't make it into the rescue images. As long as it's not the hardware support (such as a RAID controller driver going missing), you can easily do a test reboot of a system. qemu -snapshot -drive file=/dev/sda (add whatever other arguments you need.) Make sure you don't have too much disk activity to the drive while you're doing this, as the snapshotting is just done on the qemu side, so the kernel inside qemu will be quite confused when the bits on the disk change underneath its feet. Very, very convenient when you have managed to wedge the ILO and need to do evil things to a system. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762h5ugt3@qurzaw.varnish-software.com
Re: from / to /usr/: a summary
On 25.12.2011 12:12, Thomas Goirand wrote: On 12/22/2011 07:07 PM, Russell Coker wrote: It seems to me that wanting to have / outside LVM but /usr inside LVM is a fairly obscure corner case. I have about 100 servers setup this way, and my laptops as well. I really don't see why this would be a corner case. Please understand that many different people have many different configuration, and that in today's Debian, *absolutely everything is allowed*, and never, ever, Debian said that one type of setup would one day be forbidden. So if a core package which debian relies on will change in a way which does not support your configuration, should debian stop switching to a new version of that package? Or should debian fork that package and maintain it locally forever? Will you do it? Taking decisions that some setup are not supported would be a bad move whatever the partitioning we are talking about. Please don't do that, there's no reason why Debian would take such move. There's a very good reason to have and use current software, as opposed to a 10 years old one. There's a very good reason to change software. It is a moot point you're giving - if you want your current - somehow weird/non-standard/unusual/etc setup to work, just stick with the software you already using, don't upgrade anything. For example, in context of this discussion, if the decision will be made to have /usr available when switching to real root, it will require either having /usr and / on the same filesystem OR working initramfs which mounts BOTH / and /usr. If you use a setup now without initramfs and with / and /usr on separate partitions, there's no way you can continue to do that with new udev, this is unsupported by upstream. The postinst script will - most likely - do its best to ensure that it installs missing parts and creates initramfs for you so your system will still be bootable, but that's the max it can do, you may need to sort things after that manually (like updating bootloader configuration to include initramfs etc). If, at the same time, you're using a custom kernel which does not support initramfs, there's nothing that can be done automaticlly, short of installing standard debian kernel. Again, if the decision will be made. The alternative will be to a) stick with current udev (which will become incompatible with future kernels), b) fork udev to patch the missing bits back, c) grow debian- specific udev. Neither of which is realistic, imho. Thomas /mjt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ef6f2d0.5020...@msgid.tls.msk.ru
Re: from / to /usr/: a summary
On Sat, Dec 24, 2011 at 08:17:25PM -0800, Josh Triplett wrote: Debian systems without an initramfs already represent an uncommon case; Are you sure about this? How many server systems have/need an initramfs (think about VMs like XEN DomU)? How many of them are using the big Debian kernel instead of their own with certain options turned on/off (e.g. without IPv6, with certain iptables filters, with HyperV support)? All admins I know have at least some servers with custom kernels (in the past it was said, to build your firewall/server kernels without module support, so that no rootkit module could be loaded). Most of these admins have /usr separated from /. Should all these admins start repartitioning their systems or fiddle with initramfs? We can do this with new systems, yes, but not with the old ones. Shade and sweet water! Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html | signature.asc Description: Digital signature
Re: from / to /usr/: a summary
On Sun, Dec 25, 2011 at 04:12:48PM +0800, Thomas Goirand wrote: On 12/22/2011 07:07 PM, Russell Coker wrote: It seems to me that wanting to have / outside LVM but /usr inside LVM is a fairly obscure corner case. I have about 100 servers setup this way, and my laptops as well. I really don't see why this would be a corner case. Please understand that many different people have many different configuration, and that in today's Debian, *absolutely everything is allowed*, and never, ever, Debian said that one type of setup would one day be forbidden. Several years ago, it used to be the case that a combination of bootloader support and/or initramfs support meant that it was not possible to have / on LVM. Nowadays, it's possible to have the rootfs on LVM on MD raid, and the bootloader and initramfs are perfectly capable of setting things up properly. While it's still possible to set up a system the old way, today this is sub-optimal and definitely not to be recommended. For example, on the laptop I'm writing this on: % mount | grep mapper /dev/mapper/sysvg-root on / type ext3 (rw,relatime,user_xattr,errors=remount-ro,commit=0) /dev/mapper/sysvg-usr on /usr type ext3 (rw,relatime,user_xattr,commit=0) /dev/mapper/sysvg-var on /var type ext3 (rw,relatime,user_xattr,commit=0) /dev/mapper/sysvg-home on /home type ext4 (rw,relatime,user_xattr,commit=0) I used to use exactly the setup you are using. But for all the systems I've installed in the last few years, there was no point-- everything including swap can just go into an LVM VG. On more recent systems, I also omit the separate /usr given that it's effectively pointless. Regarding it being a corner case, this is I think true. It's no longer a recommended setup. While obviously this will necessarily continue to be supported for now and for a good while yet, it might not be in the distant future. Regarding absolutely everything is allowed, this is not really true. At some point some things do need retiring (I'm not saying this is true for the above, yet) when there are obviously better ways of accomplishing the same thing. 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 Archive: http://lists.debian.org/20111225114059.gx5...@codelibre.net
Re: from / to /usr/: a summary
On 2011-12-25, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: All admins I know have at least some servers with custom kernels (in the past it was said, to build your firewall/server kernels without module support, so that no rootkit module could be loaded). No longer needed. See /proc/sys/kernel/modules_disabled. Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjfe4ip.t6i.tr...@kelgar.0x539.de
Re: from / to /usr/: a summary
Le samedi 24 décembre 2011 à 19:03 +0800, Paul Wise a écrit : Apparently the reason is simply that our upstreams (who it sounds like are predominantly driven by Redhat folks) are dropping support for / and /usr on different partitions and that re-adding that support or maintaining the existing support is too much work for the Debian maintainers involved. At least that is what started the thread. Things like this is why getting involved upstream is important for Debian maintainers and probably why items 2 and 4 exist in our social contract. I would encourage those who care about this issue to start getting involved in the relevant places and submitting patches. It sounds like the ability to run a system with split / and /usr is *very* likely to disappear unless people who care decide to work in it. If you don’t care to read the key messages this thread is about, you should stop contributing to the discussion, otherwise this sounds like FUD. For those who can’t read: Marco’s proposal is not to drop support for split /usr, it is to actually re-add support for it, but through the initramfs. The only systems that will be screwed up are those with split /usr *and* no initramfs. Which is pretty uncommon. -- .''`. Josselin Mouette : :' : `. `' `- signature.asc Description: This is a digitally signed message part
Re: from / to /usr/: a summary
On Sat, 24 Dec 2011 10:17:49 +0800, Paul Wise p...@debian.org wrote: On Sat, Dec 24, 2011 at 3:05 AM, Goswin von Brederlow wrote: Maybe there is some misunderstanding here. I think nobody has suggested to build a rescue initramfs on the users system tailor made for the system. We already have debirf for that. I think the idea was for a ready made all purpose live image like grml or the DI images. We already have something similar: http://cdimage.debian.org/debian-cd/6.0.3-live/amd64/iso-hybrid/debian-live-6.0.3-amd64-rescue.iso Dunno how it compares to grml. I've generally been relatively generous with my allocation of space for /boot, so that would probably been fine for me, but others in this discussion were saying that they'd have to resize partitions to deploy even an initramfs, so suggesting a solution that requires them to stick a live image on their /boot still forces a repartition on them. I have almost no machines that are not RAIDed in some way (apart from my laptop) so I can even repartition most systems relatively painlessly if I'm willing to risk de-RAIDing them briefly. BTW do we have debian-live for ARM? How abut GRML for ARM? Of course, the ARM boxes I've been working on recently are all auto-installed, and configured with cfengine, so I doubt I'd ever bother trying to rescue them unless I was informed that some fool had put unique data on the disk in one, without backing it up. Also, if I was expecting to have to rescue them, I'd just install another copy of Debian on the built in flash, so there's no need for a live CD, but I still don't like losing the option of rescuing using the traditional method, so I'll be shifting to having / and /usr on a simple partition if we adopt this change. I'd still like to know what the compelling reason for the change is though. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpEnUf8uYbtj.pgp Description: PGP signature
