Bug#340608: fai: nfsroot should not be in /usr
tag 340608 + patch thanks Scribit Michael Tautschnig dies 26/11/2005 hora 15:19: Are the files created by fai-setup/make-fai-nfsroot really to be considered installed files, or does the policy rather talk about files installed by dpkg? I think it is a reasonable expecting that the behaviour of a program would not place files in a way incompatible with the FHS, but it is not clearly in the policy. we will consider your report for the next releases anyway, but keeping a release that does not yet fix that bug from entering testing won't help anyone much... Would one of the following patch be usable? The first is, IMHO, 100% FHS compliant, the second lets alone the /mnt2 and /fai: diff -U0 conf/fai.conf conf.new/fai.conf --- conf/fai.conf 2005-05-19 11:28:33.0 +0200 +++ conf.new/fai.conf 2005-11-27 13:50:57.578439944 +0100 @@ -46 +46 @@ -FAI_CONFIGDIR=/usr/local/share/fai +FAI_CONFIGDIR=/var/lib/fai @@ -54 +54 @@ -MNTPOINT=/mnt2 +MNTPOINT=/mnt @@ -58 +58 @@ -NFSROOT=/usr/lib/fai/nfsroot +NFSROOT=/var/lib/fai/nfsroot @@ -61 +61 @@ -FAI=/fai +FAI=/media/fai diff -U0 conf/make-fai-nfsroot.conf conf.new/make-fai-nfsroot.conf --- conf/make-fai-nfsroot.conf 2005-05-19 11:05:09.0 +0200 +++ conf.new/make-fai-nfsroot.conf 2005-11-27 13:53:16.539178808 +0100 @@ -23 +23 @@ -KERNELPACKAGE=/usr/lib/fai/kernel/kernel-image-_KERNELVERSION_-fai_1_i386.deb +KERNELPACKAGE=/var/lib/fai/kernel/kernel-image-_KERNELVERSION_-fai_1_i386.deb diff -U0 conf/fai.conf conf.new/fai.conf --- conf/fai.conf 2005-05-19 11:28:33.0 +0200 +++ conf.new/fai.conf 2005-11-27 13:55:10.035342008 +0100 @@ -46 +46 @@ -FAI_CONFIGDIR=/usr/local/share/fai +FAI_CONFIGDIR=/var/lib/fai @@ -58 +58 @@ -NFSROOT=/usr/lib/fai/nfsroot +NFSROOT=/var/lib/fai/nfsroot diff -U0 conf/make-fai-nfsroot.conf conf.new/make-fai-nfsroot.conf --- conf/make-fai-nfsroot.conf 2005-05-19 11:05:09.0 +0200 +++ conf.new/make-fai-nfsroot.conf 2005-11-27 13:53:16.539178808 +0100 @@ -23 +23 @@ -KERNELPACKAGE=/usr/lib/fai/kernel/kernel-image-_KERNELVERSION_-fai_1_i386.deb +KERNELPACKAGE=/var/lib/fai/kernel/kernel-image-_KERNELVERSION_-fai_1_i386.deb Practically, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
Scribit Steve Langasek dies 25/11/2005 hora 18:42: I certainly agree that it's desirable to never have anything written to /usr except by the package management system and to be able to keep it read-only otherwise, but I don't find that the FHS mandates this. I found, indeed: ``/usr is shareable, read-only data.'' Could you raise back the severity? Quickly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
On Sat, Nov 26, 2005 at 12:41:10PM +0100, Pierre THIERRY wrote: Scribit Steve Langasek dies 25/11/2005 hora 18:42: I certainly agree that it's desirable to never have anything written to /usr except by the package management system and to be able to keep it read-only otherwise, but I don't find that the FHS mandates this. I found, indeed: ``/usr is shareable, read-only data.'' Could you raise back the severity? No, because this data *is* both shareable and read-only; it is written to only by certain admin operations. The fact that these admin operations are not governed by dpkg doesn't make it a policy violation. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
Scribit Steve Langasek dies 26/11/2005 hora 03:47: No, because this data *is* both shareable and read-only; it is written to only by certain admin operations. I don't see how you can still consider data that is sometimes modified by priviledged users read-only... Data only modified by the core system, including dpkg, should be considered read-only when no user, including priviledged ones, modifies it. Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
Hi, I have some remarks to this bug. First, I think it can be merged with #309554, which severity should be raised at least to important... (But) #309554 deals with both the FAI_CONFIGDIR (currently defaults to /usr/local/share/fai) and NFSROOT (defaults to /usr/lib/fai/nfsroot) - both variables are set in /etc/fai/fai.conf resp. fai-nfsroot.conf. As I've said in #309554 I strongly believe /srv/ should be used for both. I like to add now, that IMO - if /srv is a policy violation at the moment (vorlon, what is your statement/guess regarding FHS 2.3 and etch ?) - this should be changed to /var/lib/fai and changed again later. Thomas, I really dont think (anymore) that it's a good idea to keep important bugs open for 2 years, just because you don't want to change it twice. My rationale for not having NFSROOT in /usr is that it is supposed to be changed during normal operation (creating, upgrading, adding packages to it) - quoting file:/usr/share/doc/debian-policy/fhs/fhs.html/fhs-4.html : Any information that is host-specific or _varies_with_time_ is stored elsewhere. (Emphasis mine.) On Friday 25 November 2005 17:10, Stephen Gran wrote: So long as the files aren't shipped in the .deb, and only put in /srv when an admin runs the tool, then I think that is exactly the place for them to go. My only worry was that fai-setup was being invoked automatically, or that the files were being proposed to be shipped in the .deb. Both of those scenarios would be wrong. Well, the upcoming fai-quickstart packages postinst copies the simple examples to FAI_CONFIGDIR... Currently there is not code in trunk (for the quickstart package) to setup the nfsroot, but we want this, too. I do find nothing in http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM which says its only up to the local admin to populate /srv, it only says, no program should rely on a specific structure in it. Which fai doesnt do, as it's configurable thru variables. Summary what I think should be done: - raise #309554 to serious - raise #340608 to serious again - merge #309554 and #340608 - change default setting of NFSROOT to /var/lib/fai/nfsroot, maybe even /var/lib/fai/nfsroot/$ARCH - change default setting of FAI_CONFIGDIR to /var/lib/fai/config - close the bug - when FHS 2.3 is required by policy, change those paths to /srv regards, Holger pgpGop2wKnokO.pgp Description: PGP signature
Bug#340608: fai: nfsroot should not be in /usr
Scribit Steve Langasek dies 26/11/2005 hora 03:47: No, because this data *is* both shareable and read-only; it is written to only by certain admin operations. I don't see how you can still consider data that is sometimes modified by priviledged users read-only... Data only modified by the core system, including dpkg, should be considered read-only when no user, including priviledged ones, modifies it. The policy states (9.1.1): The location of all installed files and directories must comply with the File system Hierarchy Standard (FHS), version 2.1 ... Are the files created by fai-setup/make-fai-nfsroot really to be considered installed files, or does the policy rather talk about files installed by dpkg? Even though I'd also prefer to have them in /srv (and I do have them there on my hosts), I don't think that the severity was justified; we will consider your report for the next releases anyway, but keeping a release that does not yet fix that bug from entering testing won't help anyone much... Best regards, Michael signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
On Sat, Nov 26, 2005 at 02:48:12PM +0100, Holger Levsen wrote: As I've said in #309554 I strongly believe /srv/ should be used for both. I like to add now, that IMO - if /srv is a policy violation at the moment (vorlon, what is your statement/guess regarding FHS 2.3 and etch ?) FHS 2.3 for etch is still an open question, as there are some transition issues. But as far as I'm concerned, /srv is fine for packages to begin using. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
On Thu, Nov 24, 2005 at 03:19:08PM +0100, Pierre THIERRY wrote: Package: fai Version: 2.8.4 Severity: serious Justification: FHS According to the FHS, ``/usr is shareable, read-only data''. So FAI should not by default try to write anything in /usr and place it's nfsroot there. See #309554. Could you elaborate on why you believe this is an FHS violation? Is the fai nfsroot not shareable, or is it not read-only? (I would expect an nfsroot image to be both...) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
On Fri, 25 Nov 2005 00:56:17 -0800, Steve Langasek [EMAIL PROTECTED] said: Could you elaborate on why you believe this is an FHS violation? Is the fai nfsroot not shareable, or is it not read-only? (I would expect an nfsroot image to be both...) The FAI nfsroot IS shareable and read only for all clients! I also think this is not an FHS violation. -- regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340608: fai: nfsroot should not be in /usr
Scribit Steve Langasek dies 25/11/2005 hora 00:56: According to the FHS, ``/usr is shareable, read-only data''. So FAI should not by default try to write anything in /usr and place it's nfsroot there. See #309554. Could you elaborate on why you believe this is an FHS violation? My /usr is only rw when doing dpkg operations. After having successfully installed the fai packaged, running the fai-setup -v fails because /usr is again ro. I think the fact that a user-triggered operation has to write in /usr is the point why there is FHS violation. Is the fai nfsroot not shareable, or is it not read-only? (I would expect an nfsroot image to be both...) It is not read-only, at least for the -k option of fai-setup, that install a new kernel in the nfsroot. So the nfsroot is clearly a read-write object the user can modify and update... It belongs either to /var or /srv (the latter I prefer, as it is clearly data for a service exposed by the system). Regards, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
On Fri, 25 Nov 2005 13:41:18 +0100, Pierre THIERRY [EMAIL PROTECTED] said: read-write object the user can modify and update... It belongs either to /var or /srv (the latter I prefer, as it is clearly data for a service exposed by the system). My future plans are to move it to /srv, but the question is, if it's really a FHS violation. I'm also wondering, why there are currently no Debian packages using /srv. I hesitate to be the first package using /srv. -- regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340608: fai: nfsroot should not be in /usr
This one time, at band camp, Thomas Lange said: On Fri, 25 Nov 2005 13:41:18 +0100, Pierre THIERRY [EMAIL PROTECTED] said: read-write object the user can modify and update... It belongs either to /var or /srv (the latter I prefer, as it is clearly data for a service exposed by the system). My future plans are to move it to /srv, but the question is, if it's really a FHS violation. I'm also wondering, why there are currently no Debian packages using /srv. I hesitate to be the first package using /srv. My understanding is that while /srv is the right place for this kind of data, it would be incorrect for Debian packages to dump stuff there. /srv is the domain of the local admin. I suppose that shipping it somewhere with a note to the effect that it should be put in /srv might be one way to go, although it seems less than optimal. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
Scribit Thomas Lange dies 25/11/2005 hora 15:34: My future plans are to move it to /srv, but the question is, if it's really a FHS violation. nfsroot can be updated, regenerated, modified to fit the user's needs, and so on. I don't see how it can really be seen read-only. So it can't be in /usr. I'm also wondering, why there are currently no Debian packages using /srv. I hesitate to be the first package using /srv. Heck, don't hesitate! Or maybe do (cf. after)... :-/ Maybe an answer is people do some things only were forced to do so. /srv is a great innovation of the FHS, I think, but many maintainers I asked to use it answer it was not mandatory. Indeed, the 3.6.2 policy only mandates FHS 2.1, but /srv was added in 2.3. The problem is, strictly speaking, using /srv would not be policy compliant, I think, because there is no mention of /srv in the currently included FHS. Maybe you should just usr /var/lib/fai and just be prepared to switch to /srv/fai when possible. Doubtfully, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
Scribit Stephen Gran dies 25/11/2005 hora 15:19: My understanding is that while /srv is the right place for this kind of data, it would be incorrect for Debian packages to dump stuff there. /srv is the domain of the local admin. This is precisely why it should be put there by fai-setup. fai-setup is not run by the system, but by the user, byt the adminstrator who sets up it's FAI. fai-setup is for FAI more or less like svnadmin create /srv/svn/foo for Subversion. I agree packages should not touch /srv much, if any, but commands run by the user to create and modify data served by the system are perfectly fine touching /srv... Quickly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
This one time, at band camp, Pierre THIERRY said: Scribit Stephen Gran dies 25/11/2005 hora 15:19: My understanding is that while /srv is the right place for this kind of data, it would be incorrect for Debian packages to dump stuff there. /srv is the domain of the local admin. This is precisely why it should be put there by fai-setup. fai-setup is not run by the system, but by the user, byt the adminstrator who sets up it's FAI. fai-setup is for FAI more or less like svnadmin create /srv/svn/foo for Subversion. I agree packages should not touch /srv much, if any, but commands run by the user to create and modify data served by the system are perfectly fine touching /srv... Disclaimer: I know nothing about FAI So long as the files aren't shipped in the .deb, and only put in /srv when an admin runs the tool, then I think that is exactly the place for them to go. My only worry was that fai-setup was being invoked automatically, or that the files were being proposed to be shipped in the .deb. Both of those scenarios would be wrong. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
On Fri, 25 Nov 2005 16:13:24 +0100, Pierre THIERRY [EMAIL PROTECTED] said: The problem is, strictly speaking, using /srv would not be policy compliant, I think, because there is no mention of /srv in the currently included FHS. Maybe you should just usr /var/lib/fai and just be prepared to switch to /srv/fai when possible. I like to skip the move to /var/lib/fai, and wait until I can finally move to /srv. -- regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340608: fai: nfsroot should not be in /usr
Scribit Thomas Lange dies 25/11/2005 hora 17:35: I like to skip the move to /var/lib/fai, and wait until I can finally move to /srv. But this is still a bug, and a policy violation. Users applying Debian security guidelines will still encounter this bug with the default configuration... Pragmatically, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
severity 340608 important thanks On Fri, Nov 25, 2005 at 01:41:18PM +0100, Pierre THIERRY wrote: Scribit Steve Langasek dies 25/11/2005 hora 00:56: According to the FHS, ``/usr is shareable, read-only data''. So FAI should not by default try to write anything in /usr and place it's nfsroot there. See #309554. Could you elaborate on why you believe this is an FHS violation? My /usr is only rw when doing dpkg operations. After having successfully installed the fai packaged, running the fai-setup -v fails because /usr is again ro. I think the fact that a user-triggered operation has to write in /usr is the point why there is FHS violation. I certainly agree that it's desirable to never have anything written to /usr except by the package management system and to be able to keep it read-only otherwise, but I don't find that the FHS mandates this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#340608: fai: nfsroot should not be in /usr
Package: fai Version: 2.8.4 Severity: serious Justification: FHS According to the FHS, ``/usr is shareable, read-only data''. So FAI should not by default try to write anything in /usr and place it's nfsroot there. See #309554. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages fai depends on: ii libapt-pkg-perl 0.1.13 Perl interface to libapt-pkg ii perl 5.8.7-6Larry Wall's Practical Extraction Versions of packages fai recommends: ii debootstrap 0.3.2 Bootstrap a basic Debian system pn dhcp3-server | bootp none (no description available) pn fai-kernels none (no description available) ii krb5-rsh-server [rsh-server] 1.3.6-5Secure replacements for rshd and r ii nfs-kernel-server [nfs-server 1:1.0.7-3 Kernel NFS server support ii syslinux 2.11-0.1 Bootloader for Linux/i386 using MS pn tftpd-hpa | tftpd none (no description available) ii wget 1.10.2-1 retrieves files from the web -- no debconf information -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
