Date: Thu, 19 Aug 2010 05:03:07 -0500 (CDT)
Subject: Re: [alpine-devel] Unattended Installation Ideas for 2.1
From: "Matt Smith" <mcs@darkregion.net>
To: alpine-devel@lists.alpinelinux.org
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
Message-ID: <1282212187.424930332@192.168.2.231>

On Wednesday, August 18, 2010 9:54am, "Natanael Copa" <ncopa@alpinelinux.or=
g> said:=0A> On Fri, 2010-08-13 at 22:12 -0500, Matt Smith wrote:=0A> The g=
oal is to make a bootable cdrom or USB that will run the install=0A> for yo=
u and give you a running system.=0A> =0A> The goal is that it should be eas=
y for enduser to create such system and=0A> it should be simple to understa=
nd whats going on.=0A> =0A>> The concept work-flow at the moment, goes some=
thing like this:=0A>>=0A>> 1. The user will obtain "alpine-iso" via git.=0A=
> =0A> I think it would be nice if the enduser would not need to create new=
 iso=0A> if the target was a bootable USB. In other words, it would be nice=
 if it=0A> would be enough to just copy a file to a bootable usb or somethi=
ng.=0A=0AI like that idea.=0A=0A(...snip...)=0A> We talked about this some =
really long time ago. The boot scripts used to=0A> look for a localinit scr=
ipt on the boot media (iso image/usb) and if=0A> found it was executed as l=
ast step in boot process.=0A> =0A> We still have something similar with the=
 /etc/init.d/local "service"=0A> which executes /etc/rc.local=0A=0A* For US=
B: I believe that unattended support should be built into the publicly=0Aav=
ailable ISOs, where the user could download, dd to a USB stick, and start=
=0Aadding their scripts. =C2=A0When booted, the main script is executed if =
found.=0A=0A* For ISO: The user could modify the example scripts provided i=
n=0Aalpine-iso/unattended and/or add new scripts altogether.=0AThen just "m=
ake PROFILE=3Dalpine iso" and burn to CD (or dd to USB).=0A=0ARight now, I'=
m thinking the bulk of the scripts should be located=0Aat /etc/unattended.=
=0A=0AKeep in mind, however, that that path is only "available" from within=
 the=0Ainitrd. =C2=A0For instance, if done via USB, simply copying the scri=
pts to the=0AUSB stick, assuming an "unattended" directory is created at th=
e root=0Aof the USB's filesystem and the USB's filesystem is auto-mounted t=
o=0A/media/usb, would make them available at /media/usb/unattended. Or in t=
he=0Acase of a CD/ISO, it would be available at /media/cdrom/unattended.=0A=
=0AAfter that, all we would need to do is check either=0A/media/cdrom/unatt=
ended or /media/usb/unattended for the main script.=0A=0A(Perhaps /media/al=
pine should be created to point to the install/LiveCD=0Amedia, whether its =
a CD or USB stick. =C2=A0Then for instance, the APK repositories=0Afile, am=
ong others, won't have to be altered from one media type to the other.)=0A=
=0A>> =3D> I recommend that we make the system "free-form," allowing for mu=
ch=0A>> =C2=A0 =C2=A0flexibility. =C2=A0I like this idea for two reasons:=
=0A>> =C2=A0 =C2=A0 =C2=A01) The implementation will be simple.=0A>> =C2=A0=
 =C2=A0 =C2=A02) It will be relatively straight-forward for the user; they =
will do=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 everything they would normally do =
from the installation's "LiveCD"=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 environme=
nt, as well as, e.g., configuring the installed system for=0A>> =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 networking with an IP address and OpenSSH. =C2=A0All in a=
n automated,=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 non-prompting fashion.=0A> =
=0A> freeform as in a simple shell script? like /etc/rc.local?=0A=0AYeah, p=
retty much.=0A=0A>> =3D> The UNATTENDED_SCRIPT can source other shell scrip=
ts (like any other shell=0A>> =C2=A0 =C2=A0script), for use of common funct=
ions. =C2=A0(One handy function would be the one=0A>> =C2=A0 =C2=A0I've cre=
ated already that makes it easy to execute lengthy commands via=0A>> =C2=A0=
 =C2=A0chroot.)=0A> =0A> Ok, so you want stuff in more than a single file. =
You'd need a tar=0A> archive then, like apkovl?=0A=0ANot sure. =C2=A0The id=
ea is to allow the user to create as many scripts as they=0Abelieve are nec=
essary, programatically stemming from the user's main shell script.=0A=0AFo=
r instance, they could have a DHCP server configured to dole out a specific=
=0AIP address to a specific MAC address upon request. =C2=A0At this point, =
their scripts=0Acould setup networking for DHCP, and then, based on the IP =
address obtained,=0Aexecute a script that's specific to installing and conf=
iguring this particular=0Amachine.=0A=0AIn this manner, the user could crea=
te numerous individual machine install=0Aconfigs, but yet include them all =
on a single ISO or USB stick or USB stick=0Aimage.=0A=0A>> =3D> We should a=
dd some sort of universal "accept the defaults" option to the=0A>> =C2=A0 =
=C2=A0/sbin/setup-* scripts (e.g. setup-disk), such as "--accept-defaults."=
=0A>> =C2=A0 =C2=A0(I've already got a basic version of setup-disk that doe=
s this.)=0A> =0A> I think it would be nice with some preseeds, that answers=
 some of the=0A> questions or all or tells the script "use default". User c=
ould be asked=0A> the missing answers. That way you could make an half auto=
mated install,=0A> where end user maybe only need to answer 1 question.=0A=
=0AOn the other hand, perhaps the user could simply use "expect" to answer=
=0Aany and all prompts that are normally available for things such as=0Aset=
up-disk and setup-keymap. =C2=A0I'm not sure which package "expect" is in,=
=0Aif it's even available yet?=0A=0A>> =3D> When the unattended install is =
complete, we could either "halt" or "reboot."=0A>> =C2=A0 =C2=A0Assuming th=
e CD/ISO will still be present after doing an automatic reboot,=0A>> =C2=A0=
 =C2=A0we would need to do some sort of check to see if a prior unattended =
install=0A>> =C2=A0 =C2=A0has completed. =C2=A0If it has, proceed to bootin=
g the MBR of the first HDD, or,=0A>> =C2=A0 =C2=A0if the user knows in adva=
nce what to boot, perhaps that could be added as an=0A>> =C2=A0 =C2=A0optio=
n to the .conf.mk file.=0A>> =C2=A0 =C2=A0=3D> For example:=0A>> =C2=A0 =C2=
=A0 =C2=A0 ON_FINISH=3D(halt|reboot) =C2=A0# Maybe even make this a user-co=
nfigurable script=0A>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0# instead.=0A>> =
=C2=A0 =C2=A0 =C2=A0 ON_REBOOT_BOOT=3Dsda=0A> =0A> Fedora/Redhat uses a boo=
t option, "ks" to fire up the unattended=0A> install. If you need enter an =
option at bootprompt it fire the thing up,=0A> you would not need check if =
it was previously run. (even if thats=0A> trivial to implemnt too).=0A> =0A=
> And you normally want look at the screen to see that it properly boots=0A=
> before you leave it unattended.=0A=0AThat is true. =C2=A0I like it. =C2=
=A0I guess I just thought that (most?)=0Aunattended installs were just drop=
ping in a CD and rebooting.=0A=0AActually, the CactiEZ ISO I tried a few da=
ys ago seemed to require that you=0Apress enter to boot with the default op=
tions (which I believe was 32-bit, as=0Aopposed to 64-bit), but still, it d=
id require that you at least do something=0Abefore it erased the primary HD=
D and went about installing everything=0Aautomatically).=0A=0A(...snip...)=
=0A> For the unattended install problem, I think we can split it up in=0A> =
atleast 3 parts:=0A> =0A> 1. something that kicks in a script at end of boo=
t.=0A> 2. having preseeded answers to the setup-scripts.=0A> 3. optionally =
fix alpine-iso to include #1 and #2 on the iso (trivial)=0A> =0A> Problem #=
1 can be solved in various ways:=0A> a. ship an apkovl with the contents:=
=0A> =C2=A0 /etc/rc.local=0A> =C2=A0 /etc/runlevels/default/local -> /etc/i=
nit.d/local=0A> =0A> (if rc.local's last thing it does is 'rc-update del lo=
cal', then it will=0A> not be execute next run)=0A=0AIMHO, that seems kind =
of sloppy.=0A=0A> b. we could have a boot script parse boot params to kerne=
l and excute=0A> stuff based on that=0A=0AI like this the best.=0A=0A> c. w=
e could have a magic file on boot media, similar to apkovl, but=0A> instead=
 of beeing a tar archive it is a simple script that gets=0A> autostarted. (=
like we did long time ago with localinit)=0A=0AThis is kind of what I did i=
n my experiments, but I like the previous idea,=0Ain that you can choose wh=
at to do on boot, instead of having the decision=0Amade based on whether or=
 not a magic file is available.=0A=0A-- Matt Smith=0A



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---