Red Hat Bugzilla – Bug 55672
kickstart: rootpw --iscrypted can not be used with interactive or autostep installation
Last modified: 2007-04-18 12:38:01 EDT
Description of problem:
In a kickstart configuration file, if one uses the --iscrypted parameter
to the "rootpw" directive, in order to supply a pre-encrypted password,
and the "interactive" or "autostep" directives are used so that the
installation procedure is forced into a semi-automatic mode, this
password is not used to fill the root password fields in the account
setup step of the interactive installation procedure. The password fields
(enter and confirm) must be filled manually, otherwise it is impossible
to proceed to the next step.
I understand anaconda probably doesn't have the means to process the
password in order to automatically fill these fields, however:
a. the documentation should clearly state that an encrypted root password
should not be used along with interactive or autostep directives and
b. the kickstart configuration parser should either reject config files
that include both "rootpw --iscrypted" and "interactive" or "autostep",
or anaconda should totally skip the account creation step during an
interactive installation if this directive is used, or it should allow
proceeding to the next step even if a root password is not given in this
step; it would then just use the encrypted one from ks.cfg.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Write a ks.cfg file with the directives: "rootpw --iscrypted
<encrypted password>" and "interactive"
2. Install RHL: e.g. boot from RHL 7.2 CD1 with ks.cfg on a floppy and
type linux ks=floppy
3. Proceed through to the account configuration step.
4. Notice how the root password fields are empty and anaconda does not
allow to proceed to the next step unless you enter a root password in the
fields, effectively overriding the password in ks.cfg.
5. Abort installation, edit ks.cfg and change the rootpw directive
to "rootpw <unencrypted password>".
6. Repeat the procedure in steps 2 and 3.
7. Notice how anaconda has filled the root password fields this time.
Actual Results: Anaconda does not allow an interactive installation to
proceed to the next step after account configuration when the root
password fields are left blank, even though the root passwor is provided
encrypted in the kickstart configuration file that is used during this
Expected Results: Anaconda's kickstart configuration parser should
reject config files that include both "rootpw --iscrypted"
and "interactive" or "autostep".
Anaconda should totally skip the account creation step during an
interactive installation if "rootpw --iscrypted" is used, or it should
allow proceeding to the next step even if a root password is not given
(blank fields) in this step; it would then just use the encrypted one
Kickstart documentation (part of RHL Official Customization Guide) is not
clear at several points. Most specifically, the two most noticeable
A. It is not always clear what the right syntax for directive parameters
that accept arguments is, i.e. if
directive --parameter argument
is right or if
is right. From experience, it usually does not make a difference, but
using the "=" syntax is cleaner. But I have no clue the scripting
language that anaconda uses (python) does process these syntax formats
B. The documentation should include syntactical examples for every
directive and parameter explained. It should also be explicitly noted
when a directive requires at a minimum some parameters, which parameters
are required to be used together and which parameters conflict with each
other and should not be used together. There are some notes about such
issues (e.g. see the part/partition directive documentation) but there
are many more missing (see Bug #55670). Similarly, directive dependencies
and conflictions should be better documented (see this bug's Description).
I've verified this behavior. katzj, how do you want to handle this?
Skipping this step is possible, but it would require adding a lot more inner
knowledge of steps when the kickstart file is read on. My initial impression is
that this is going to just fall into the category of things not to do; in a lot
of ways, interactive mode exists for debugging so I don't want it doing a lot of
different things to the flow.
I'll think on it over the weekend though to see if I can come up with something.
Don't we know we're in kickstart mode, and can't we look at the passWd object
we're passed in getScreen() to decide what to do?
Deferring to future release.
This bug exists in 7.3 (Verified in autostep mode only)
If this is to become a feature, it should be documented.
*** Bug 84495 has been marked as a duplicate of this bug. ***
Can we reconsider this for the next release?