Bug#337011: installation-guide: Please document the new ways to preseed root and user passwords
On Monday 07 November 2005 11:04, Frans Pop wrote: Well, yes. Unless we want to use your text as a first more extensive text in a new appendix. One idea could be is to break up the current example into parts and preseed each part by an introduction. This would also be good for translators as the current massive example is rather hard on them... I have started to implement this. For the Etch version of the manual preseeding will be covered in a separate appendix B. I have included a new section for user setup in first stage based on the proposed text (currently marked NOT-YET as the udeb is not yet used in installs). Please check the new text and example for errors. The source for the new appendix is available from [1] in SVN, but is not yet included in the daily builds of the manual. Before it can be included I need to write a new script that can parse the xml file and extract an example preseed file from it. A preview is available from [2] (does not include the new user setup bit). Others are welcome to flesh out the missing parts in the introductory sections. Cheers, FJP [1] manual/en/appendix/example-preseed-etch-new.xml [2] http://people.debian.org/~fjp/d-i/manual/apb.html pgpR5bGvMvK0Q.pgp Description: PGP signature
Bug#337011: installation-guide: Please document the new ways to preseed root and user passwords
On Thursday 03 November 2005 08:59, Christian Perrier wrote: Well, I basically agree. I had this concern while writing the text but I was then a bit lazy and preferred to see this item (which was at the top of my TODO list for a while, thanks to Holger) done. However, correct me if I'm wrong, but actually preseeding is only covered by the examples, right? AT basically yes. But I think there are good reason to expand it into a separate appendix. That could start by explaining the basic concepts, how preseeding works in different installation methods, how to create a preseed file, how to find valid values, explain the various hooks in more detail (early/late commands), etc. There's no other place where preseeding is covered with more details? No. As I said we currently only have the short introduction [1] and the example [2] If so, then I guess I should move the paragraphs I added to shadow.xml to the example files themselves... Well, yes. Unless we want to use your text as a first more extensive text in a new appendix. One idea could be is to break up the current example into parts and preseed each part by an introduction. This would also be good for translators as the current massive example is rather hard on them... I think it should still be possible to merge the different parts automatically into one example file at build time to which we could link. That [1] http://d-i.alioth.debian.org/manual/en.i386/ch04s07.html#preseed [2] http://d-i.alioth.debian.org/manual/en.i386/apcs01.html pgpjPVssFuV9B.pgp Description: PGP signature
Bug#337011: installation-guide: Please document the new ways to preseed root and user passwords
I see you wrote the patch for boot-new/modules/shadow.xml. The only problem I have with that is that this would be the first instance where preseeding is covered in the main text. For the rest preseeding is only introduced in general in 4.7.1 and then only in the appendix. Putting preseeding info in the main text IMO distracts from the normal installation procedure. I do see arguments for creating a separate chapter for preseeding instead of having it as a part of a more general appendix. It does deserve a more extensive documentation, which currently is hard to do. Comment please. Well, I basically agree. I had this concern while writing the text but I was then a bit lazy and preferred to see this item (which was at the top of my TODO list for a while, thanks to Holger) done. However, correct me if I'm wrong, but actually preseeding is only covered by the examples, right? There's no other place where preseeding is covered with more details? If so, then I guess I should move the paragraphs I added to shadow.xml to the example files themselves... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337011: installation-guide: Please document the new ways to preseed root and user passwords
Package: installation-guide Severity: normal Tags: patch The attached patch documents the password preseeding, including the new ways to preseed passwords as of shadow 4.0.13-1, which is now in testing. I'm not very used to the writing style of the Installation Guide. This is why I did not commit the change immediately as it probably needs a review. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-1-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) --- en/boot-new/modules/shadow.xml 2005-10-07 21:59:11.339037959 +0200 +++ en/boot-new/modules/shadow-new.xml 2005-11-02 08:13:06.791479900 +0100 @@ -65,5 +65,47 @@ account, use the commandadduser/command command. /para + /sect3 + sect3 id=password-preseeding + titlePreseeding passwords/title + +para + +Both the root and the first created user passwords can be +emphasispreseeded/emphasis during automated installs (see xref +linkend=automatic-install/). +/para + +para +The passwords can be preseeded in cleartext using the +classnamepasswd/root-password/classname, +classnamepasswd/root-password-again/classname, +classnamepasswd/user-password/classname and +classnamepasswd/user-password-again/classname values. Be aware +that this is not completely security-proof as everyone with physical +access to the preseed file will have the knowledge of these passwords. +/para + +para condition=etch +The passwords can also be preseeded as MD5 emphasishashes/emphasis +by using the classnamepasswd/root-password-crypted/classname and +classnamepasswd/user-password-crypted/classname variables. Thihs +method is considered slightly better in terms of security but not +completely proof as well because physical access to a MD5 /para hash +allows for brute force attacks. Some people even consider this method +can be less secure as it may give a false sense of security. +/para + +para condition=etch +The classnamepasswd/root-password-crypted/classname and +classnamepasswd/user-password-crypted/classname variables can be +preseeded with ! as value. In that case, the corresponding account +is disabled. This may be convenient for the root account, provided of +course that an alternate method is setup to allow administrative +activities or root login (for instance by using SSH key +authentication). +/para + + /sect2
Bug#337011: installation-guide: Please document the new ways to preseed root and user passwords
Hi, On Wednesday 02 November 2005 09:04, Christian Perrier wrote: The attached patch documents the password preseeding, including the new ways to preseed passwords as of shadow 4.0.13-1, which is now in testing. Thanks. I'm not very used to the writing style of the Installation Guide. This is why I did not commit the change immediately as it probably needs a review. Looked good to me, besides this: Three remarks about the 2nd paragraph: (quoted now for easier reference) +para condition=etch +The passwords can also be preseeded as MD5 emphasishashes/emphasis +by using the classnamepasswd/root-password-crypted/classname and +classnamepasswd/user-password-crypted/classname variables. Thihs +method is considered slightly better in terms of security but not +completely proof as well because physical access to a MD5 /para hash +allows for brute force attacks. Some people even consider this method +can be less secure as it may give a false sense of security. +/para 1. typo: Thihs 2. s/Some people even consider this method can be less secure as it may give a false sense of security./Some people consider this method problematic as it may give a false sense of security./ Maybe its even sensible to write it even shorter: This method is considered slightly better in terms of security but it might also give a false sense of security because physical access to a MD5 hash allows for brute force attacks. 3. I believe the /para after the 2nd MD5 is wrong. regards, Holger pgpLzxMnnG2JA.pgp Description: PGP signature
Bug#337011: installation-guide: Please document the new ways to preseed root and user passwords
Hi all, On Wednesday 02 Nov 2005 10:30, Holger Levsen wrote: Looked good to me, besides this: Three remarks about the 2nd paragraph: (quoted now for easier reference) +para condition=etch +The passwords can also be preseeded as MD5 emphasishashes/emphasis +by using the classnamepasswd/root-password-crypted/classname and +classnamepasswd/user-password-crypted/classname variables. Thihs +method is considered slightly better in terms of security but not +completely proof as well because physical access to a MD5 /para hash +allows for brute force attacks. Some people even consider this method +can be less secure as it may give a false sense of security. +/para Wasn't there a way of preseeding that the password should be locked? (apologies if this was already mentioned, I missed the beginning of the discussion). I thought this was to set the passwd/root-password-crypted as * , but this isn't working for me. I had: passwd passwd/root-password-crypted password * Am I doing something wrong here? 2. s/Some people even consider this method can be less secure as it may give a false sense of security./Some people consider this method problematic as it may give a false sense of security./ (imho, with security problematic == less secure) How about: Some people consider this method less secure as it may give a false sense of security. Maybe its even sensible to write it even shorter: This method is considered slightly better in terms of security but it might also give a false sense of security because physical access to a MD5 hash allows for brute force attacks. 's OK, but I'm concerned for the user who doesn't know how to evaluate the risk with MD5 sums. Do we (or should we) give recommendations here? Personally, I think we should say use MD5 over plain-text, but how does the user quantify the risk with preseeding the root-password in whatever form its stored? Cheers, Paul. pgp0zx5i4U62U.pgp Description: PGP signature
Bug#337011: installation-guide: Please document the new ways to preseed root and user passwords
New patch version, after Holger's remarks. --- en/boot-new/modules/shadow.xml 2005-10-07 21:59:11.339037959 +0200 +++ en/boot-new/modules/shadow-new.xml 2005-11-02 18:26:12.427774809 +0100 @@ -16,7 +16,6 @@ a time as possible. /parapara - Any password you create should contain at least 6 characters, and should contain both upper- and lower-case characters, as well as punctuation characters. Take extra care when setting your root @@ -65,5 +64,47 @@ account, use the commandadduser/command command. /para + /sect3 + sect3 id=password-preseeding + titlePreseeding passwords/title + +para + +Both the root and the first created user passwords can be +emphasispreseeded/emphasis during automated installs (see xref +linkend=automatic-install/). +/para + +para +The passwords can be preseeded in cleartext using the +classnamepasswd/root-password/classname, +classnamepasswd/root-password-again/classname, +classnamepasswd/user-password/classname and +classnamepasswd/user-password-again/classname values. Be aware +that this is not completely security-proof as everyone with physical +access to the preseed file will have the knowledge of these passwords. +/para + +para condition=etch +The passwords can also be preseeded as MD5 emphasishashes/emphasis +by using the classnamepasswd/root-password-crypted/classname and +classnamepasswd/user-password-crypted/classname variables. This +method is considered slightly better in terms of security but it might +also give a false sense of security because physical access to a MD5 +hash allows for brute force attacks. + +/para + +para condition=etch +The classnamepasswd/root-password-crypted/classname and +classnamepasswd/user-password-crypted/classname variables can be +preseeded with ! as value. In that case, the corresponding account +is disabled. This may be convenient for the root account, provided of +course that an alternate method is setup to allow administrative +activities or root login (for instance by using SSH key +authentication). +/para + + /sect2
Bug#337011: installation-guide: Please document the new ways to preseed root and user passwords
On Wednesday 02 November 2005 09:04, Christian Perrier wrote: The attached patch documents the password preseeding, including the new ways to preseed passwords as of shadow 4.0.13-1, which is now in testing. I see you wrote the patch for boot-new/modules/shadow.xml. The only problem I have with that is that this would be the first instance where preseeding is covered in the main text. For the rest preseeding is only introduced in general in 4.7.1 and then only in the appendix. Putting preseeding info in the main text IMO distracts from the normal installation procedure. I do see arguments for creating a separate chapter for preseeding instead of having it as a part of a more general appendix. It does deserve a more extensive documentation, which currently is hard to do. Comment please. pgp5LcqfM6LGK.pgp Description: PGP signature
