Subject: Re: [alpine-devel] Unattended Installation Ideas for 2.1
From: Natanael Copa <ncopa@alpinelinux.org>
To: Matt Smith <mcs@darkregion.net>
Cc: alpine-devel@lists.alpinelinux.org
In-Reply-To: <1282212187.424930332@192.168.2.231>
References: <1282212187.424930332@192.168.2.231>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 20 Aug 2010 14:35:07 +0200
Message-ID: <1282307707.31207.1887.camel@ncopa-desktop.nor.wtbts.net>
Precedence: list
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2010-08-19 at 05:03 -0500, Matt Smith wrote:
> On Wednesday, August 18, 2010 9:54am, "Natanael Copa" <ncopa@alpinelinux.org> said:
> > On Fri, 2010-08-13 at 22:12 -0500, Matt Smith wrote:

...

> Keep in mind, however, that that path is only "available" from within the
> initrd.  For instance, if done via USB, simply copying the scripts to the
> USB stick, assuming an "unattended" directory is created at the root
> of the USB's filesystem and the USB's filesystem is auto-mounted to
> /media/usb, would make them available at /media/usb/unattended. Or in the
> case of a CD/ISO, it would be available at /media/cdrom/unattended.
> 
> After that, all we would need to do is check either
> /media/cdrom/unattended or /media/usb/unattended for the main script.

or we could have a boot param: ua=usb:/unattended

With fedora you have 'ks' (for kickstart) and you can specify what
devices to search + a patch to the kickstart file.

> (Perhaps /media/alpine should be created to point to the install/LiveCD
> media, whether its a CD or USB stick.  Then for instance, the APK repositories
> file, among others, won't have to be altered from one media type to the other.)

I like this idea.

> >> => I recommend that we make the system "free-form," allowing for much
> >>    flexibility.  I like this idea for two reasons:
> >>      1) The implementation will be simple.
> >>      2) It will be relatively straight-forward for the user; they will do
> >>         everything they would normally do from the installation's "LiveCD"
> >>         environment, as well as, e.g., configuring the installed system for
> >>         networking with an IP address and OpenSSH.  All in an automated,
> >>         non-prompting fashion.
> > 
> > freeform as in a simple shell script? like /etc/rc.local?
> 
> Yeah, pretty much.
> 
> >> => The UNATTENDED_SCRIPT can source other shell scripts (like any other shell
> >>    script), for use of common functions.  (One handy function would be the one
> >>    I've created already that makes it easy to execute lengthy commands via
> >>    chroot.)
> > 
> > Ok, so you want stuff in more than a single file. You'd need a tar
> > archive then, like apkovl?
> 
> Not sure.  The idea is to allow the user to create as many scripts as they
> believe are necessary, programatically stemming from the user's main shell script.
> 
> For instance, they could have a DHCP server configured to dole out a specific
> IP address to a specific MAC address upon request.  At this point, their scripts
> could setup networking for DHCP, and then, based on the IP address obtained,
> execute a script that's specific to installing and configuring this particular
> machine.
> 
> In this manner, the user could create numerous individual machine install
> configs, but yet include them all on a single ISO or USB stick or USB stick
> image.

I wonder if we want preseeds, or answer files to the setup script(s)
with optional scripting hooks.

something like, unattended.conf (sa=setup-alpine for example) :

sa_keyboard=no
sa_hostname=alpine
sa_net_eth0_type=static

# uncomment row below to avoid prompting user
#sa_net_eth0_address=192.168.8.1/24

sa_net_eth1_type=dhcp

post_hook="echo 'install is done. will reboot in 10 sec' && sleep 10 && reboot"
	
...etc

Maybe lua is a better language for that. IIRC i wrote some experiments
for that some time ago. I wonder where that code went.

> >> => We should add some sort of universal "accept the defaults" option to the
> >>    /sbin/setup-* scripts (e.g. setup-disk), such as "--accept-defaults."
> >>    (I've already got a basic version of setup-disk that does this.)
> > 
> > I think it would be nice with some preseeds, that answers some of the
> > questions or all or tells the script "use default". User could be asked
> > the missing answers. That way you could make an half automated install,
> > where end user maybe only need to answer 1 question.
> 
> On the other hand, perhaps the user could simply use "expect" to answer
> any and all prompts that are normally available for things such as
> setup-disk and setup-keymap.  I'm not sure which package "expect" is in,
> if it's even available yet?

I dont think it is. I saw some expect-like utility that was a bit
smaller and simpler.

I still would prefer a preseed.conf or unattended.conf file over
scripts.

> >> => When the unattended install is complete, we could either "halt" or "reboot."
> >>    Assuming the CD/ISO will still be present after doing an automatic reboot,
> >>    we would need to do some sort of check to see if a prior unattended install
> >>    has completed.  If it has, proceed to booting the MBR of the first HDD, or,
> >>    if the user knows in advance what to boot, perhaps that could be added as an
> >>    option to the .conf.mk file.
> >>    => For example:
> >>       ON_FINISH=(halt|reboot)  # Maybe even make this a user-configurable script
> >>                                # instead.
> >>       ON_REBOOT_BOOT=sda
> > 
> > Fedora/Redhat uses a boot option, "ks" to fire up the unattended
> > install. If you need enter an option at bootprompt it fire the thing up,
> > you would not need check if it was previously run. (even if thats
> > trivial to implemnt too).
> > 
> > And you normally want look at the screen to see that it properly boots
> > before you leave it unattended.
> 
> That is true.  I like it.  I guess I just thought that (most?)
> unattended installs were just dropping in a CD and rebooting.
> 
> Actually, the CactiEZ ISO I tried a few days ago seemed to require that you
> press enter to boot with the default options (which I believe was 32-bit, as
> opposed to 64-bit), but still, it did require that you at least do something
> before it erased the primary HDD and went about installing everything
> automatically).

yes, i dont like the idea of a bootable cdrom with written alpine on it
that erases your disk without asking first.


> (...snip...)
> > For the unattended install problem, I think we can split it up in
> > atleast 3 parts:
> > 
> > 1. something that kicks in a script at end of boot.
> > 2. having preseeded answers to the setup-scripts.
> > 3. optionally fix alpine-iso to include #1 and #2 on the iso (trivial)
> > 
> > Problem #1 can be solved in various ways:
> > a. ship an apkovl with the contents:
> >   /etc/rc.local
> >   /etc/runlevels/default/local -> /etc/init.d/local
> > 
> > (if rc.local's last thing it does is 'rc-update del local', then it will
> > not be execute next run)
> 
> IMHO, that seems kind of sloppy.

yes, I am :) But it does what you want, without adding any extra code.

> > b. we could have a boot script parse boot params to kernel and excute
> > stuff based on that
> 
> I like this the best.

I think this is what I prefer too.

So, we have the kick-in mechanism more or less worked out. Some
questions remains. What do we call the beast? alpine-setup? auto-setup?
unattended-setup? kickstart? (redhats)

We should probably make a service that is triggered if the boot param is
found (from initramfs) so it is kicked in before login prompt.

Now, the real question is, how do we do the auto-answer on setup
scripts. I'd like have that part working before we write any code that
triggers it.

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---