From nobody Fri Mar 29 05:57:45 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from smtp111.iad.emailsrvr.com (smtp111.iad.emailsrvr.com [207.97.245.111]) by lists.alpinelinux.org (Postfix) with ESMTP id 26A2B1EB599 for ; Thu, 19 Aug 2010 10:03:08 +0000 (UTC) Received: from relay31.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay31.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 7BC8A1B436B for ; Thu, 19 Aug 2010 06:03:07 -0400 (EDT) Received: from dynamic11.wm-web.iad.mlsrvr.com (dynamic11.wm-web.iad.mlsrvr.com [192.168.2.218]) by relay31.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 766B51B4290 for ; Thu, 19 Aug 2010 06:03:07 -0400 (EDT) Received: from darkregion.net (localhost [127.0.0.1]) by dynamic11.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 680E5E0086 for ; Thu, 19 Aug 2010 06:03:07 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: mcs@darkregion.net, from: mcs@darkregion.net) with HTTP; Thu, 19 Aug 2010 05:03:07 -0500 (CDT) Date: Thu, 19 Aug 2010 05:03:07 -0500 (CDT) Subject: Re: [alpine-devel] Unattended Installation Ideas for 2.1 From: "Matt Smith" To: alpine-devel@lists.alpinelinux.org X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1282212187.424930332@192.168.2.231> X-Mailer: webmail8 On Wednesday, August 18, 2010 9:54am, "Natanael Copa" 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 --- From nobody Fri Mar 29 05:57:45 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from mail.wtbts.no (mail.wtbts.no [213.234.126.131]) by lists.alpinelinux.org (Postfix) with ESMTP id 0C7FE3617A1D for ; Fri, 20 Aug 2010 12:38:42 +0000 (UTC) Received: from [10.65.65.1] (unknown [10.65.65.1]) by mail.wtbts.no (Postfix) with ESMTP id 9FB0012C00F; Fri, 20 Aug 2010 14:32:18 +0200 (CEST) Subject: Re: [alpine-devel] Unattended Installation Ideas for 2.1 From: Natanael Copa To: Matt Smith 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> X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 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" 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 --- From nobody Fri Mar 29 05:57:45 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from smtp191.iad.emailsrvr.com (smtp191.iad.emailsrvr.com [207.97.245.191]) by lists.alpinelinux.org (Postfix) with ESMTP id 5F6E53617A1D for ; Sat, 21 Aug 2010 00:28:57 +0000 (UTC) Received: from relay19.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay19.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 0EC991B400A for ; Fri, 20 Aug 2010 20:28:57 -0400 (EDT) Received: from dynamic4.wm-web.iad.mlsrvr.com (dynamic4.wm-web.iad.mlsrvr.com [192.168.2.153]) by relay19.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id EDBE61B402C for ; Fri, 20 Aug 2010 20:28:56 -0400 (EDT) Received: from darkregion.net (localhost [127.0.0.1]) by dynamic4.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id BEBB31D48070 for ; Fri, 20 Aug 2010 20:28:56 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: mcs@darkregion.net, from: mcs@darkregion.net) with HTTP; Fri, 20 Aug 2010 19:28:56 -0500 (CDT) Date: Fri, 20 Aug 2010 19:28:56 -0500 (CDT) Subject: Re: [alpine-devel] Unattended Installation Ideas for 2.1 From: "Matt Smith" To: alpine-devel@lists.alpinelinux.org X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <1282307707.31207.1887.camel@ncopa-desktop.nor.wtbts.net> References: <1282212187.424930332@192.168.2.231> <1282307707.31207.1887.camel@ncopa-desktop.nor.wtbts.net> Message-ID: <1282350536.779815473@192.168.2.227> X-Mailer: webmail8 On Friday, August 20, 2010 7:35am, "Natanael Copa" = said:=0A> On Thu, 2010-08-19 at 05:03 -0500, Matt Smith wrote:=0A>> On Wedn= esday, August 18, 2010 9:54am, "Natanael Copa" =0A>>= said:=0A>> > On Fri, 2010-08-13 at 22:12 -0500, Matt Smith wrote:=0A=0A...= =0A>> After that, all we would need to do is check either=0A>> /media/cdrom= /unattended or /media/usb/unattended for the main script.=0A> =0A> or we co= uld have a boot param: ua=3Dusb:/unattended=0A> =0A> With fedora you have '= ks' (for kickstart) and you can specify what=0A> devices to search + a patc= h to the kickstart file.=0A=0AYeah, that sounds good.=0A=0A>> (Perhaps /med= ia/alpine should be created to point to the install/LiveCD=0A>> media, whet= her its a CD or USB stick. =C2=A0Then for instance, the APK repositories=0A= >> file, among others, won't have to be altered from one media type to the = other.)=0A> =0A> I like this idea.=0A(Kept above text for reference because= it's on-point with the previous idea above.)=0A=0A...=0A> I wonder if we w= ant preseeds, or answer files to the setup script(s)=0A> with optional scri= pting hooks.=0A> =0A> something like, unattended.conf (sa=3Dsetup-alpine fo= r example) :=0A> =0A> sa_keyboard=3Dno=0A> sa_hostname=3Dalpine=0A> sa_net_= eth0_type=3Dstatic=0A> =0A> # uncomment row below to avoid prompting user= =0A> #sa_net_eth0_address=3D192.168.8.1/24=0A> =0A> sa_net_eth1_type=3Ddhcp= =0A> =0A> post_hook=3D"echo 'install is done. will reboot in 10 sec' && sle= ep 10 && reboot"=0A> =0A> ...etc=0A> =0A> Maybe lua is a better language fo= r that. IIRC i wrote some experiments=0A> for that some time ago. I wonder = where that code went.=0A> =0A...=0A>> On the other hand, perhaps the user c= ould simply use "expect" to answer=0A>> any and all prompts that are normal= ly available for things such as=0A>> setup-disk and setup-keymap. =C2=A0I'm= not sure which package "expect" is in,=0A>> if it's even available yet?=0A= > =0A> I dont think it is. I saw some expect-like utility that was a bit=0A= > smaller and simpler.=0A> =0A> I still would prefer a preseed.conf or unat= tended.conf file over=0A> scripts.=0A=0AI can tell that you're big on the i= dea of doing a preseed or some type of=0Aconfig file. =C2=A0My issue with t= hat is, and hear me out: even if all of the=0Acustom variables are well-doc= umented on the wiki, the user still has to=0Alook up the documentation to f= igure out how to do something that's=0Arelatively simple (e.g., what variab= le format and its syntax will allow me=0Ato do X). =C2=A0To be fair, I don'= t mind how ArchLinux does their rc.conf.=0AGranted that such an implementat= ion would bring a certain level of sanity=0Ato the table, I fear that it al= so limits the user to what the unattended=0Ainstall would otherwise be capa= ble of.=0A=0AIf you like the free-form idea a little more now, what if we i= nstead=0Aprovided both implementations to the user?=0A=0AThe free-form idea= would be easier to implement and I think advanced users=0Awould appreciate= it. =C2=A0It should at least get us started quicker (and=0Aeventually towa= rds working on a preseeded answers method).=0A=0A...=0A> So, we have the ki= ck-in mechanism more or less worked out. Some=0A> questions remains. What d= o we call the beast? alpine-setup? auto-setup?=0A> unattended-setup? kickst= art? (redhats)=0A=0AWhat about Alpine Unattended Setup (AUS), or Alpine Lin= ux Unattended Setup (ALUS)?=0AI kinda like AUS.=0A=0A> We should probably m= ake a service that is triggered if the boot param is=0A> found (from initra= mfs) so it is kicked in before login prompt.=0A=0ASounds good.=0A=0A> Now, = the real question is, how do we do the auto-answer on setup=0A> scripts. I'= d like have that part working before we write any code that=0A> triggers it= .=0A=0AAs for the free-form idea, I say we recommend either "expect" or a s= impler=0Aversion of "expect". =C2=A0Simple reason being that without a larg= e amount of=0Aeffort, and even then, it's largely impossible to provide an = "accept the=0Adefaults" option for anything and everything the user might w= ant to use=0Aduring the unattended install.=0A=0A- Matt Smith --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Fri Mar 29 05:57:45 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from mail.tanael.org (unknown [213.234.126.134]) by lists.alpinelinux.org (Postfix) with ESMTP id B65141EB59F for ; Tue, 24 Aug 2010 11:06:14 +0000 (UTC) Received: from [10.65.65.1] (unknown [213.234.126.129]) by mail.tanael.org (Postfix) with ESMTP id 882A6A3DA62F; Tue, 24 Aug 2010 11:06:14 +0000 (UTC) Subject: Re: [alpine-devel] Unattended Installation Ideas for 2.1 From: Natanael Copa To: Matt Smith Cc: alpine-devel@lists.alpinelinux.org In-Reply-To: <1282350536.779815473@192.168.2.227> References: <1282212187.424930332@192.168.2.231> <1282307707.31207.1887.camel@ncopa-desktop.nor.wtbts.net> <1282350536.779815473@192.168.2.227> Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 Aug 2010 13:02:20 +0200 Message-ID: <1282647740.5375.1573.camel@ncopa-desktop.nor.wtbts.net> X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit 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 --- From nobody Fri Mar 29 05:57:45 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from mail.wtbts.no (mail.wtbts.no [213.234.126.131]) by lists.alpinelinux.org (Postfix) with ESMTP id B37101EB59F for ; Tue, 24 Aug 2010 11:19:25 +0000 (UTC) Received: from [10.65.65.1] (unknown [10.65.65.1]) by mail.wtbts.no (Postfix) with ESMTP id 30C4C12C001; Tue, 24 Aug 2010 13:12:58 +0200 (CEST) Subject: Re: [alpine-devel] Unattended Installation Ideas for 2.1 From: Natanael Copa To: Matt Smith Cc: alpine-devel@lists.alpinelinux.org In-Reply-To: <1282647740.5375.1573.camel@ncopa-desktop.nor.wtbts.net> References: <1282212187.424930332@192.168.2.231> <1282307707.31207.1887.camel@ncopa-desktop.nor.wtbts.net> <1282350536.779815473@192.168.2.227> <1282647740.5375.1573.camel@ncopa-desktop.nor.wtbts.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 Aug 2010 13:15:33 +0200 Message-ID: <1282648533.5375.1601.camel@ncopa-desktop.nor.wtbts.net> X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit 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 --- From nobody Fri Mar 29 05:57:45 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from smtp111.iad.emailsrvr.com (smtp111.iad.emailsrvr.com [207.97.245.111]) by lists.alpinelinux.org (Postfix) with ESMTP id 71FAF1EB587 for ; Thu, 26 Aug 2010 07:16:55 +0000 (UTC) Received: from relay31.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay31.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id A61E01B4205 for ; Thu, 26 Aug 2010 03:16:54 -0400 (EDT) Received: from dynamic1.wm-web.iad.mlsrvr.com (dynamic1.wm-web.iad.mlsrvr.com [192.168.2.150]) by relay31.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 9F2FD1B419B for ; Thu, 26 Aug 2010 03:16:54 -0400 (EDT) Received: from darkregion.net (localhost [127.0.0.1]) by dynamic1.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 90DE7C98070 for ; Thu, 26 Aug 2010 03:16:54 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: mcs@darkregion.net, from: mcs@darkregion.net) with HTTP; Thu, 26 Aug 2010 02:16:54 -0500 (CDT) Date: Thu, 26 Aug 2010 02:16:54 -0500 (CDT) Subject: Re: [alpine-devel] Unattended Installation Ideas for 2.1 From: "Matt Smith" To: alpine-devel@lists.alpinelinux.org X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: <1282647740.5375.1573.camel@ncopa-desktop.nor.wtbts.net> References: <1282212187.424930332@192.168.2.231> <1282307707.31207.1887.camel@ncopa-desktop.nor.wtbts.net> <1282350536.779815473@192.168.2.227> <1282647740.5375.1573.camel@ncopa-desktop.nor.wtbts.net> Message-ID: <1282807014.591226967@192.168.2.228> X-Mailer: webmail8 On Tuesday, August 24, 2010 6:02am, "Natanael Copa" said:=0A= =0A> I created lua-pty package which lets you control apps from lua via pty= s,=0A> similar to what expect does.=0A> =0A> We dont have expect so we need= a package for it. It does require tcl so=0A> dependencies might be several= MB. If we use lua we get away with 300K=0A> probably.=0A> =0A> There is a = expect-light project, but it seems to require expect=0A> http://expect-lite= .sourceforge.net/=0A> =0A> Otherwise we have "emtpy" http://empty.sourcefor= ge.net/ which seems like=0A> a good alternative.=0A=0AYeah, the lua-pty opt= ion sounds pretty light-weight, as does "empty."=0A=0AI'm open to using eit= her option, but I'm thinking "empty" might be a better fit?=0A=0A- Matt Smi= th --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Fri Mar 29 05:57:45 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@lists.alpinelinux.org Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by lists.alpinelinux.org (Postfix) with ESMTP id EB0BB1EB587 for ; Thu, 26 Aug 2010 13:16:51 +0000 (UTC) Received: by bwz20 with SMTP id 20so1261921bwz.13 for ; Thu, 26 Aug 2010 06:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ALvZbLg41dZHfdfq+60m9dmqHvAGxA2kvG9pR8hUDpM=; b=hebVslLGmP3GPoRdYF/5Qjx1+T0zxYY+NGuYoRiECL5hGHvZa2m/Seks+ZOkBHAT73 JOzOhFTAITyEghdFGsfdv4raFiUhDwjGz7ixXqCfb4Y7PRJY++9pwQXICuyeZmdI4Lue pEy9Rb/iVu6Twra0wLssXef1BqJmNh10dnkmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PuN325J/o0K7lf0MlDjmBuYGkslKftGK1UT0fDUovOiIg2rpIbYks9Zzs5jOGCjOGx Nnm61ADYpHwzjXT9GIjGTG5yISnRos7aeh9EqhyWKy98J5AMN2QqNJSAb6mnG1tA0vTo 44P1Rix9Kdq47znicI0VPlv0gbcDeJny1NQEM= X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.204.126.92 with SMTP id b28mr6483607bks.47.1282828609000; Thu, 26 Aug 2010 06:16:49 -0700 (PDT) Received: by 10.204.19.140 with HTTP; Thu, 26 Aug 2010 06:16:48 -0700 (PDT) In-Reply-To: <1282807014.591226967@192.168.2.228> References: <1282212187.424930332@192.168.2.231> <1282307707.31207.1887.camel@ncopa-desktop.nor.wtbts.net> <1282350536.779815473@192.168.2.227> <1282647740.5375.1573.camel@ncopa-desktop.nor.wtbts.net> <1282807014.591226967@192.168.2.228> Date: Thu, 26 Aug 2010 15:16:48 +0200 Message-ID: Subject: Re: [alpine-devel] Unattended Installation Ideas for 2.1 From: Natanael Copa To: Matt Smith Cc: alpine-devel@lists.alpinelinux.org Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 26, 2010 at 9:16 AM, Matt Smith wrote: > On Tuesday, August 24, 2010 6:02am, "Natanael Copa" 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 ---