~alpine/devel

6 4

Re: [alpine-devel] Unattended Installation Ideas for 2.1

Details
Message ID
<1282212187.424930332@192.168.2.231>
Sender timestamp
1282212187
DKIM signature
missing
Download raw message
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:
> The goal is to make a bootable cdrom or USB that will run the install
> for you and give you a running system.
> 
> The goal is that it should be easy for enduser to create such system and
> it should be simple to understand whats going on.
> 
>> The concept work-flow at the moment, goes something like this:
>>
>> 1. The user will obtain "alpine-iso" via git.
> 
> I think it would be nice if the enduser would not need to create new iso
> if the target was a bootable USB. In other words, it would be nice if it
> would be enough to just copy a file to a bootable usb or something.

I like that idea.

(...snip...)
> We talked about this some really long time ago. The boot scripts used to
> look for a localinit script on the boot media (iso image/usb) and if
> found it was executed as last step in boot process.
> 
> We still have something similar with the /etc/init.d/local "service"
> which executes /etc/rc.local

* For USB: I believe that unattended support should be built into the publicly
available ISOs, where the user could download, dd to a USB stick, and start
adding their scripts.  When booted, the main script is executed if found.

* For ISO: The user could modify the example scripts provided in
alpine-iso/unattended and/or add new scripts altogether.
Then just "make PROFILE=alpine iso" and burn to CD (or dd to USB).

Right now, I'm thinking the bulk of the scripts should be located
at /etc/unattended.

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.

(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 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.

>> => 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?

>> => 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).

(...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.

> b. we could have a boot script parse boot params to kernel and excute
> stuff based on that

I like this the best.

> c. we could have a magic file on boot media, similar to apkovl, but
> instead of beeing a tar archive it is a simple script that gets
> autostarted. (like we did long time ago with localinit)

This is kind of what I did in my experiments, but I like the previous idea,
in that you can choose what to do on boot, instead of having the decision
made based on whether or not a magic file is available.

-- Matt Smith




---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Unattended Installation Ideas for 2.1

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<1282307707.31207.1887.camel@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<1282212187.424930332@192.168.2.231> (view parent)
Sender timestamp
1282307707
DKIM signature
missing
Download raw message
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
---

Re: [alpine-devel] Unattended Installation Ideas for 2.1

Details
Message ID
<1282350536.779815473@192.168.2.227>
In-Reply-To
<1282307707.31207.1887.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1282350536
DKIM signature
missing
Download raw message
On Friday, August 20, 2010 7:35am, "Natanael Copa" <ncopa@alpinelinux.org> said:
> 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:

...
>> 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.

Yeah, that sounds good.

>> (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.
(Kept above text for reference because it's on-point with the previous idea above.)

...
> 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.
> 
...
>> 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.

I can tell that you're big on the idea of doing a preseed or some type of
config file.  My issue with that is, and hear me out: even if all of the
custom variables are well-documented on the wiki, the user still has to
look up the documentation to figure out how to do something that's
relatively simple (e.g., what variable format and its syntax will allow me
to do X).  To be fair, I don't mind how ArchLinux does their rc.conf.
Granted that such an implementation would bring a certain level of sanity
to the table, I fear that it also limits the user to what the unattended
install would otherwise be capable of.

If you like the free-form idea a little more now, what if we instead
provided both implementations to the user?

The free-form idea would be easier to implement and I think advanced users
would appreciate it.  It should at least get us started quicker (and
eventually towards working on a preseeded answers method).

...
> 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)

What about Alpine Unattended Setup (AUS), or Alpine Linux Unattended Setup (ALUS)?
I kinda like AUS.

> 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.

Sounds good.

> 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.

As for the free-form idea, I say we recommend either "expect" or a simpler
version of "expect".  Simple reason being that without a large amount of
effort, and even then, it's largely impossible to provide an "accept the
defaults" option for anything and everything the user might want to use
during the unattended install.

- Matt Smith



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Unattended Installation Ideas for 2.1

Natanael Copa <n@tanael.org>
Details
Message ID
<1282647740.5375.1573.camel@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<1282350536.779815473@192.168.2.227> (view parent)
Sender timestamp
1282647740
DKIM signature
missing
Download raw message
On Fri, 2010-08-20 at 19:28 -0500, Matt Smith wrote:

> > 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)
> 
> What about Alpine Unattended Setup (AUS), or Alpine Linux Unattended Setup (ALUS)?
> I kinda like AUS.

ok.

> > 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.
> 
> Sounds good.
> 
> > 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.
> 
> As for the free-form idea, I say we recommend either "expect" or a simpler
> version of "expect".  Simple reason being that without a large amount of
> effort, and even then, it's largely impossible to provide an "accept the
> defaults" option for anything and everything the user might want to use
> during the unattended install.

I created lua-pty package which lets you control apps from lua via ptys,
similar to what expect does.

We dont have expect so we need a package for it. It does require tcl so
dependencies might be several MB. If we use lua we get away with 300K
probably.

There is a expect-light project, but it seems to require expect
http://expect-lite.sourceforge.net/

Otherwise we have "emtpy" http://empty.sourceforge.net/ which seems like
a good alternative.

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Unattended Installation Ideas for 2.1

Natanael Copa <ncopa@alpinelinux.org>
Details
Message ID
<1282648533.5375.1601.camel@ncopa-desktop.nor.wtbts.net>
In-Reply-To
<1282647740.5375.1573.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1282648533
DKIM signature
missing
Download raw message
On Tue, 2010-08-24 at 13:02 +0200, Natanael Copa wrote:

> 
> Otherwise we have "emtpy" http://empty.sourceforge.net/ which seems like
> a good alternative.

added package 'empty' to edge/testing.

-nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Unattended Installation Ideas for 2.1

Details
Message ID
<1282807014.591226967@192.168.2.228>
In-Reply-To
<1282647740.5375.1573.camel@ncopa-desktop.nor.wtbts.net> (view parent)
Sender timestamp
1282807014
DKIM signature
missing
Download raw message
On Tuesday, August 24, 2010 6:02am, "Natanael Copa" <n@tanael.org> said:

> I created lua-pty package which lets you control apps from lua via ptys,
> similar to what expect does.
> 
> We dont have expect so we need a package for it. It does require tcl so
> dependencies might be several MB. If we use lua we get away with 300K
> probably.
> 
> There is a expect-light project, but it seems to require expect
> http://expect-lite.sourceforge.net/
> 
> Otherwise we have "emtpy" http://empty.sourceforge.net/ which seems like
> a good alternative.

Yeah, the lua-pty option sounds pretty light-weight, as does "empty."

I'm open to using either option, but I'm thinking "empty" might be a better fit?

- Matt Smith



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Unattended Installation Ideas for 2.1

Details
Message ID
<AANLkTinNrhbM=4NKva-tuEprO47grO_OvdVXwBbLYEr_@mail.gmail.com>
In-Reply-To
<1282807014.591226967@192.168.2.228> (view parent)
Sender timestamp
1282828608
DKIM signature
missing
Download raw message
On Thu, Aug 26, 2010 at 9:16 AM, Matt Smith <mcs@darkregion.net> wrote:
> On Tuesday, August 24, 2010 6:02am, "Natanael Copa" <n@tanael.org> said:
>
>> I created lua-pty package which lets you control apps from lua via ptys,
>> similar to what expect does.
>>
>> We dont have expect so we need a package for it. It does require tcl so
>> dependencies might be several MB. If we use lua we get away with 300K
>> probably.
>>
>> There is a expect-light project, but it seems to require expect
>> http://expect-lite.sourceforge.net/
>>
>> Otherwise we have "emtpy" http://empty.sourceforge.net/ which seems like
>> a good alternative.
>
> Yeah, the lua-pty option sounds pretty light-weight, as does "empty."
>
> I'm open to using either option, but I'm thinking "empty" might be a better fit?

I'm ok with both. Depends on if you want do it with shell scripts or lua.

-- 
Natanael Copa


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Reply to thread Export thread (mbox)