Re: Directory /boot/console-setup
On Fri, May 11, 2012 at 09:07:57AM +0200, Tollef Fog Heen wrote: ]] Steve Langasek My complaint is that this is excessively ugly. For persistent variable data that needs to be available during early boot, even when this is binary data that the user won't edit, /etc is the normal place to keep it - it's the creation of a a .cache subdirectory that I object to. Very strongly agreed, if we could outright ban using dot directories Ok, then it will be /etc/console-setup/cache (no dot). On Thu, May 10, 2012 at 02:54:16PM -0700, Steve Langasek wrote: On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote: Currently it creates files in the directory /etc/console-setup. As a result when the package is purged it is impossible to tell which files in /etc/console-setup are automatically generated (so they have to be removed) and which are put there by the admin (so we are not permitted to remove them). I think your premise here is false. The /etc/console-setup directory is owned by the console-setup package; there are certain predictable filenames The file names are not predictable unless one has acces to all previous versions of the configuration files. But even if they were predictable we would need MD5 or other hash to be sure the files have not be modified somehow by the admin. Yves-Alexis Perez wrote on debian-devel: What do you mean with “this doesn't work in Debian”? Some people do use encrypted root and they do have a working console asking for the passphrase. As far as I know currently the console works with default settings, meaning the keyboard is standard US-QWERTY layout. Anton Zinoviev -- 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/20120512120431.ga22...@logic.fmi.uni-sofia.bg
Re: Directory /boot/console-setup
On Sat, May 12, 2012 at 03:04:31PM +0300, Anton Zinoviev wrote: On Thu, May 10, 2012 at 02:54:16PM -0700, Steve Langasek wrote: On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote: Currently it creates files in the directory /etc/console-setup. As a result when the package is purged it is impossible to tell which files in /etc/console-setup are automatically generated (so they have to be removed) and which are put there by the admin (so we are not permitted to remove them). I think your premise here is false. The /etc/console-setup directory is owned by the console-setup package; there are certain predictable filenames The file names are not predictable unless one has acces to all previous versions of the configuration files. But even if they were predictable we would need MD5 or other hash to be sure the files have not be modified somehow by the admin. No, you absolutely do *not* need this. The policy rule isn't on purge, remove all config files if the admin hasn't edited them, it's on purge, remove *all configuration files*. This cache subdirectory is pointless complexity. The existing rm -rf behavior is appropriate. -- 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: Bug#672160: Directory /boot/console-setup
On Sat, May 12, 2012 at 07:01:20AM -0700, Steve Langasek wrote: No, you absolutely do *not* need this. The policy rule isn't on purge, remove all config files if the admin hasn't edited them, it's on purge, remove *all configuration files*. All configuration files owned by the package. There is no way to tell whether a file in /etc/console-setup is owned by the package console-setup or it has been put there by the admin and is unrelated to console-setup. Anton Zinoviev -- 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/20120512170415.ga23...@logic.fmi.uni-sofia.bg
Re: Bug#672160: Directory /boot/console-setup
On Sat, May 12, 2012 at 08:04:15PM +0300, Anton Zinoviev wrote: On Sat, May 12, 2012 at 07:01:20AM -0700, Steve Langasek wrote: No, you absolutely do *not* need this. The policy rule isn't on purge, remove all config files if the admin hasn't edited them, it's on purge, remove *all configuration files*. All configuration files owned by the package. This is not an interesting distinction. There is no way to tell whether a file in /etc/console-setup is owned by the package console-setup or it has been put there by the admin and is unrelated to console-setup. Who cares? If the admin is putting files in a directory named /etc/console-setup that are *unrelated to console-setup*, there's no reason to coddle them by making the console-setup's maintainer scripts more complex. And most package maintainers have not bothered to implement such handling. So an admin who hasn't yet learned the lesson to not put random files in unrelated directories under /etc will have plenty of opportunities to learn it before purging such a basic package as console-setup. -- 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: Directory /boot/console-setup
Hi, Anton Zinoviev wrote (12 May 2012 12:04:31 GMT) : Yves-Alexis Perez wrote on debian-devel: What do you mean with “this doesn't work in Debian”? Some people do use encrypted root and they do have a working console asking for the passphrase. As far as I know currently the console works with default settings, meaning the keyboard is standard US-QWERTY layout. Well, while this is currently true as far as testing/sid is concerned, but this is actually a regression: On Squeeze, one may happily use a non-US layout in the initramfs to enter their encrypted root passphrase. On Wheezy, this is currently broken, at least for fresh installs (#619711). -- 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/85boltq7fd@boum.org
Re: Directory /boot/console-setup
]] Steve Langasek My complaint is that this is excessively ugly. For persistent variable data that needs to be available during early boot, even when this is binary data that the user won't edit, /etc is the normal place to keep it - it's the creation of a a .cache subdirectory that I object to. Very strongly agreed, if we could outright ban using dot directories in packages for anything packaged (except dotfiles in people's ~, which should generally not be something that the packaging cares about), I think that would be a good idea. -- 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/87r4urnqk2@qurzaw.varnish-software.com
Directory /boot/console-setup
[Please preserve the CC to 672...@bugs.debian.org because I am not subscribed to debian-devel.] First the problem in few words. The package console-setup needs an access to a directory similar to /var very early during the boot process - when /var is not yet mounted. Currently it creates files in the directory /etc/console-setup. As a result when the package is purged it is impossible to tell which files in /etc/console-setup are automatically generated (so they have to be removed) and which are put there by the admin (so we are not permitted to remove them). One possible solution is to generate the files in a directory named /etc/console-setup/.cache and to put a file /etc/console-setup/.cache/README explaining the purpose of this directory and warning the admin that the package is free to remove or overwrite at any time any files in this directory. Please don't complain that this is a policy violation. :) I think at the moment there is no solution of the problem without policy violation and the packages kbd, console-tools and console-setup have been happily doing policy violations regarding /etc since the very first version of Debian. The second solution I propose is to generate the files in a directory /boot/console-setup. After all the whole need of such directory arises due to the specifics of the boot process. Personally, I think I prefer /boot to /etc. Some additional info: most of the time the package requires only read-only access to this directory. Write-access is required only in the following occasions: 1. when the admin is dpkg-reconfiguring the package 2. during the first reboot (but not too early in the boot process) if the admin has edited the configuration files of console-setup by hand and he has not used the command setupcon --save 3. when the admin uses the command setupcon --save Anton Zinoviev -- 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/20120510164346.gc3...@logic.fmi.uni-sofia.bg
Re: Bug#672160: Directory /boot/console-setup
On 2012-05-10 18:43 +0200, Anton Zinoviev wrote: [Please preserve the CC to 672...@bugs.debian.org because I am not subscribed to debian-devel.] First the problem in few words. The package console-setup needs an access to a directory similar to /var very early during the boot process - when /var is not yet mounted. Currently it creates files in the directory /etc/console-setup. As a result when the package is purged it is impossible to tell which files in /etc/console-setup are automatically generated (so they have to be removed) and which are put there by the admin (so we are not permitted to remove them). One possible solution is to generate the files in a directory named /etc/console-setup/.cache and to put a file /etc/console-setup/.cache/README explaining the purpose of this directory and warning the admin that the package is free to remove or overwrite at any time any files in this directory. Please don't complain that this is a policy violation. :) I think at the moment there is no solution of the problem without policy violation and the packages kbd, console-tools and console-setup have been happily doing policy violations regarding /etc since the very first version of Debian. The second solution I propose is to generate the files in a directory /boot/console-setup. After all the whole need of such directory arises due to the specifics of the boot process. Maybe I'm missing something obvious, but /boot seems to be a very bad choice for the location, simply because it is not available any earlier than /var. Cheers, Sven -- 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/87sjf87wwe@turtle.gmx.de
Re: Directory /boot/console-setup
On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote: [Please preserve the CC to 672...@bugs.debian.org because I am not subscribed to debian-devel.] First the problem in few words. The package console-setup needs an access to a directory similar to /var very early during the boot process - when /var is not yet mounted. Currently it creates files in the directory /etc/console-setup. We created /run for exactly this purpose. Create /run/console-setup and put what you need inside there. You'll need to follow the advice in http://wiki.debian.org/ReleaseGoals/RunDirectory . You basically just need to have a Depends on initscripts (= 2.88dsf-13.3) and you're good to go. Don't store megabytes of data in here though, since it's stored in virtual memory on most systems. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20120510174518.gk23...@codelibre.net
Re: Directory /boot/console-setup
On 2012-05-10 19:45 +0200, Roger Leigh wrote: On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote: [Please preserve the CC to 672...@bugs.debian.org because I am not subscribed to debian-devel.] First the problem in few words. The package console-setup needs an access to a directory similar to /var very early during the boot process - when /var is not yet mounted. Currently it creates files in the directory /etc/console-setup. We created /run for exactly this purpose. Create /run/console-setup and put what you need inside there. AIUI the data is not volatile, and it needs to be read early in the boot process, that's why /var was not suitable. Cheers, Sven -- 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/87havn9b00@turtle.gmx.de
Re: Bug#672160: Directory /boot/console-setup
On Thu, May 10, 2012 at 07:45:21PM +0200, Sven Joachim wrote: Maybe I'm missing something obvious, but /boot seems to be a very bad choice for the location, simply because it is not available any earlier than /var. Ah, you are right. So it seems only /etc is an option. Thanks. Anton Zinoviev -- 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/20120510191339.ga8...@debian.lan
Re: Bug#672160: Directory /boot/console-setup
On Thu, May 10, 2012 at 10:13:39PM +0300, Anton Zinoviev wrote: On Thu, May 10, 2012 at 07:45:21PM +0200, Sven Joachim wrote: Maybe I'm missing something obvious, but /boot seems to be a very bad choice for the location, simply because it is not available any earlier than /var. Ah, you are right. So it seems only /etc is an option. Thanks. Generally the console has to work even before root is mounted, so that the user can enter a decryption password if necessary. What is it that needs to be done before other filesystems are mounted, but not before root is mounted? Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20120510204023.ge4...@decadent.org.uk
Re: Bug#672160: Directory /boot/console-setup
On Thu, May 10, 2012 at 09:40:23PM +0100, Ben Hutchings wrote: Generally the console has to work even before root is mounted, so that the user can enter a decryption password if necessary. Unfortunately, as far as I know currently this doesn't work in Debian. Proper wishlist bug reports have been filled but we haven't come yet to a solution that is good for all developers. Anyway, we may not expect that all initrd images are able to configure the console. What is it that needs to be done before other filesystems are mounted, but not before root is mounted? At least the keyboard has to be configured before fsck runs. Anton Zinoviev -- 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/20120510211603.ga30...@debian.lan
Re: Bug#672160: Directory /boot/console-setup
On ven., 2012-05-11 at 00:16 +0300, Anton Zinoviev wrote: On Thu, May 10, 2012 at 09:40:23PM +0100, Ben Hutchings wrote: Generally the console has to work even before root is mounted, so that the user can enter a decryption password if necessary. Unfortunately, as far as I know currently this doesn't work in Debian. Proper wishlist bug reports have been filled but we haven't come yet to a solution that is good for all developers. What do you mean with “this doesn't work in Debian”? Some people do use encrypted root and they do have a working console asking for the passphrase. Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: Directory /boot/console-setup
On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote: First the problem in few words. The package console-setup needs an access to a directory similar to /var very early during the boot process - when /var is not yet mounted. Currently it creates files in the directory /etc/console-setup. As a result when the package is purged it is impossible to tell which files in /etc/console-setup are automatically generated (so they have to be removed) and which are put there by the admin (so we are not permitted to remove them). I think your premise here is false. The /etc/console-setup directory is owned by the console-setup package; there are certain predictable filenames that will have been created by the package; and any files in this directory are configuration files for console-setup, whether created by the admin manually or created by the package. So it's perfectly permissible under policy for the package to remove these files on purge. One possible solution is to generate the files in a directory named /etc/console-setup/.cache and to put a file /etc/console-setup/.cache/README explaining the purpose of this directory and warning the admin that the package is free to remove or overwrite at any time any files in this directory. Please don't complain that this is a policy violation. :) I think at the moment there is no solution of the problem without policy violation and the packages kbd, console-tools and console-setup have been happily doing policy violations regarding /etc since the very first version of Debian. My complaint is that this is excessively ugly. For persistent variable data that needs to be available during early boot, even when this is binary data that the user won't edit, /etc is the normal place to keep it - it's the creation of a a .cache subdirectory that I object to. The second solution I propose is to generate the files in a directory /boot/console-setup. After all the whole need of such directory arises due to the specifics of the boot process. Personally, I think I prefer /boot to /etc. Not useful for reasons already discussed. Some additional info: most of the time the package requires only read-only access to this directory. Write-access is required only in the following occasions: 1. when the admin is dpkg-reconfiguring the package 2. during the first reboot (but not too early in the boot process) if the admin has edited the configuration files of console-setup by hand and he has not used the command setupcon --save 3. when the admin uses the command setupcon --save Yep, which makes this entirely consistent with storage on the rootfs, including when the rootfs is read-only by default, and /etc the right place to put the data. Cheers, -- 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
