Here's what I'm currently doing in ks.cfg:
%pre #!/bin/sh echo -n "Please enter blah: " read blah echo $blah > /tmp/ks-blah
I know that "read blah" works fine, because after that I see the variable in the /tmp file.
The problem is, echo doesn't seem to work at this stage. This pretty much kills the idea of an interactive %pre script. I was thinking to collect in %pre the information that is different from one system to another (and cannot be deduced automatically by kickstart), then the user can walk away and the system is installed and configured completely by kickstart.
If %pre cannot be made interactive, then I'll have to move the customization after reboot, which is less than ideal.
P.S.: I guess I could automatically generate a whole lot of ks.cfg files on the kickstart server, and just tell the user to point the installer to the appropriate ks.cfg, instead of entering some info manually at the %pre stage. But somehow generating hundreds of ks.cfg files seems very ugly. I'd rather keep that algorithm in one single ks.cfg and let the user enter a couple things in the %pre stage.
Florin Andrei wrote:
Here's what I'm currently doing in ks.cfg:
%pre #!/bin/sh echo -n "Please enter blah: " read blah echo $blah > /tmp/ks-blah
the 'normal' way to do such config stuff is via a module for firstboot, which runs the first time a machine boots....
since you are going this in %pre rather than %post, i presume some of the choices a user makes at this stage will influence the installer in someway ?
- KB
Karanbir Singh wrote:
the 'normal' way to do such config stuff is via a module for firstboot, which runs the first time a machine boots....
I want the user to enter as much as possible at the very beginning of the process, then walk away and the installation should continue after that 100% unattended. It's very handy if you have to build dozens of servers ASAP. ;-)
since you are going this in %pre rather than %post, i presume some of the choices a user makes at this stage will influence the installer in someway ?
Yes. All systems are the same, except a few small differences. It's those differences that the installer must ask.
And now I have the solution. Apparently, %pre is displayed on tty3, but the input is still on tty1. Ugly, but we have to deal with it. So, this is a %pre that works fine:
%pre chvt 3 exec < /dev/tty3 > /dev/tty3 echo -n "Enter blah: " read blah echo $blah > /tmp/ks-blah chvt 1 exec < /dev/tty1 > /dev/tty1
Florin Andrei wrote:
Karanbir Singh wrote:
the 'normal' way to do such config stuff is via a module for firstboot, which runs the first time a machine boots....
I want the user to enter as much as possible at the very beginning of the process, then walk away and the installation should continue after that 100% unattended. It's very handy if you have to build dozens of servers ASAP. ;-)
you prolly want something like cobbler ( ref: http://cobbler.et.redhat.com/ )
- KB
Karanbir Singh wrote:
you prolly want something like cobbler ( ref: http://cobbler.et.redhat.com/ )
Cool. I'll play with it. Thanks.
Florin Andrei wrote:
Karanbir Singh wrote:
the 'normal' way to do such config stuff is via a module for firstboot, which runs the first time a machine boots....
I want the user to enter as much as possible at the very beginning of the process, then walk away and the installation should continue after that 100% unattended. It's very handy if you have to build dozens of servers ASAP. ;-)
since you are going this in %pre rather than %post, i presume some of the choices a user makes at this stage will influence the installer in someway ?
Yes. All systems are the same, except a few small differences. It's those differences that the installer must ask.
And now I have the solution. Apparently, %pre is displayed on tty3, but the input is still on tty1. Ugly, but we have to deal with it. So, this is a %pre that works fine:
%pre chvt 3 exec < /dev/tty3 > /dev/tty3 echo -n "Enter blah: "
# If tee is available echo -n Enter blah: | tee /dev/tty1 # Otherwise echo -n >/dev/tty Enter blah:
read blah echo $blah > /tmp/ks-blah chvt 1 exec < /dev/tty1 > /dev/tty1
On 21/03/07, Florin Andrei florin@andrei.myip.org wrote:
Here's what I'm currently doing in ks.cfg:
%pre #!/bin/sh echo -n "Please enter blah: " read blah echo $blah > /tmp/ks-blah
I know that "read blah" works fine, because after that I see the variable in the /tmp file.
The problem is, echo doesn't seem to work at this stage. This pretty much kills the idea of an interactive %pre script. I was thinking to collect in %pre the information that is different from one system to another (and cannot be deduced automatically by kickstart), then the user can walk away and the system is installed and configured completely by kickstart.
If %pre cannot be made interactive, then I'll have to move the customization after reboot, which is less than ideal.
P.S.: I guess I could automatically generate a whole lot of ks.cfg files on the kickstart server, and just tell the user to point the installer to the appropriate ks.cfg, instead of entering some info manually at the %pre stage. But somehow generating hundreds of ks.cfg files seems very ugly. I'd rather keep that algorithm in one single ks.cfg and let the user enter a couple things in the %pre stage.
If you know the MAC address of the system before install then you could customise the install on that basis.
i.e. I know the MAC[s] of this box so when they're detected use ks-mail.cfg or ks-web.cfg as appropriate, then have a front end to add MACs use specific kickstart configs?
Will.
Will McDonald wrote:
If you know the MAC address of the system before install then you could customise the install on that basis.
i.e. I know the MAC[s] of this box so when they're detected use ks-mail.cfg or ks-web.cfg as appropriate, then have a front end to add MACs use specific kickstart configs?
Good idea when replacing an existing system.
Doesn't work that well when adding new systems, or building a new environment.
On 21/03/07, Florin Andrei florin@andrei.myip.org wrote:
Will McDonald wrote:
If you know the MAC address of the system before install then you could customise the install on that basis.
i.e. I know the MAC[s] of this box so when they're detected use ks-mail.cfg or ks-web.cfg as appropriate, then have a front end to add MACs use specific kickstart configs?
Good idea when replacing an existing system.
Doesn't work that well when adding new systems, or building a new environment.
Yes and no.
Most modern rackmount kit comes with a tear-off system info card with MAC address, asset tag and the like attached for this sort of purpose. Obviously the value of this depends on your build systems but you should, theoretically, be able to rack a system and build it with minimal intervention once the tear-off tag's information's inserted into your management systems [1].
Will.
[1] In an ideal world :)
On Wed, Mar 21, 2007 at 02:11:40AM +0000, Will McDonald said:
On 21/03/07, Florin Andrei florin@andrei.myip.org wrote:
Will McDonald wrote:
If you know the MAC address of the system before install then you could customise the install on that basis.
i.e. I know the MAC[s] of this box so when they're detected use ks-mail.cfg or ks-web.cfg as appropriate, then have a front end to add MACs use specific kickstart configs?
Good idea when replacing an existing system.
Doesn't work that well when adding new systems, or building a new environment.
Yes and no.
Most modern rackmount kit comes with a tear-off system info card with MAC address, asset tag and the like attached for this sort of purpose. Obviously the value of this depends on your build systems but you should, theoretically, be able to rack a system and build it with minimal intervention once the tear-off tag's information's inserted into your management systems [1].
What I do is let them grab the default install, and then I grab the mac out of the dhcp.leases file. Nuke the dirve with "dd" and reboot so it get's the customized install. Helps with those pesky HP servers that do not have the MAC on the outside of the box.
-
Florin Andrei -
John Summerfield -
Karanbir Singh -
Walt Reed -
Will McDonald