Suggestion: bootstrap hook for script (boot parameter + auto execution)

[tnussb]

@Maro: You are missing at least my point  It's not about the techniques of customization. There are various approaches and I'm experienced enough to realize them. My point is that for a real "nomadic distribution" there is still something missing, namely the explained hook mechanism via a boot parameter. It's about plug-and-play without any required customization - a one-stop-solution. Whatever is required to be performed during an installation/setup (what you normally type in) comes from an single external hosted script.

Suppose you want to guide a complete newbie to setup a special installation. The simplest way is to point him to download a standard distro and let him type in a web url of a kickstart-like file on the bootscreen. This way, appliances don't require any "large" downloads (customized distros) or require an unexperienced user to type in some cryptic lines. Just enter a single line at the boot prompt. That's all.

When it comes to automation of hundreds of nodes a single boot parameter rocks, too.

A special tc extension is fine, but requires still more "setup" work (and must be maintained in some way, of course).

[Lee]

Some time ago, as an exercise of curiosity when I wanted to see how early I could gain control of the boot process (without remastering), I created an extension called onload.tcz which simply checks for the existence an external script named onload.sh (which is -not- included in the extension) and sources it if found (otherwise exiting silently).  Essentially a hook into the extension loading process.

It runs automatically at whatever point in the extension loading sequence you place it - at the beginning of onboot.lst it runs early, at the end of onboot.lst, or as a dep of another extension, it runs a little later.  Loaded manually it runs when ever you want - but its kind of pointless then.  If you wanted it to download additional script from the net, you might have to wait for the network to be available.

[curaga]

The way I see it:

- security nightmare. Think of some website somewhere telling newbs to boot "fetchscript=1.2.3.4/script.sh"
- how is adding a small edit like that to the iso less complex than setting up a web server?

I get the feel you have a special situation (hundreds of nodes?) and for some reason do not want to do any customization to the standard isos.

What I read of Red Hat Kickstart says it's NFS only, on the local network. Is that any different to loading extensions from NFS, again from the lan?

[tnussb]

I get the feel you have a special situation (hundreds of nodes?) and for some reason do not want to do any customization to the standard isos.

That feeling get you completely wrong, because I have already realized it. In a matter of sense it works quite similar to the httplist bootcode, but instead of fetching just a list of tc extensions to install it fetches a script and executes it. This way not only extension installation can be performed automatically, but also all required configuration steps (whatever they are).

My intention was to contribute the idea of an ease-of-use automated setup mechanism. If it's not wanted, it's fine. I don't bother.

And btw, If you call that a "security nightmare" you can call almost everything a security nightmare (prefactored appliances, special distros, any package you install from the net without checking its sourcecode etc.).

Kickstart: By "like kickstart" I meant, that you have a single file which contains all the necessary installation and setup steps, so you can recreate a system from scratch using just that file at any time. This increases maintainability alot.

[danielibarnes]

What I read of Red Hat Kickstart says it's NFS only

Kickstart can do http as well. In fact, the primary reason I use Tiny Core is to serve files via lighttpd for kickstart-based CentOS and Red Hat installations.

Other distributions already offer what tnussb is suggesting (Red Hat kickstart, SUSE AutoYaST, HP-UX Ignite, etc.), so perhaps someone can investigate how they accomplish this and craft something similar for Tiny Core.

A properly generalized solution will require more than three lines, but I think it would be useful.

[curaga]

I've re-read the thread, and I still fail to see how doing a scripted customization once every node boot is better compared to doing it just once per version update, and then distributing that ready-to-go and tested image. Doing the work only once would fullfill most of the points mentioned, as far as I see.

[tnussb]

daniel: At least someone gets my point

curaga: It doesn't matter if you do it each time during boot (for diskless thin clients) or do it just once and distribute an image. The point is: even in the case of an image its much more comfortable (faster, easier to maintain, etc.pp.) if you can do it scripted without any manual interaction.

Systems like http://susestudio.com/ depends heavily on such a bootstrap script hook. Within a web gui you select your system's options and configure whatever is necessary and then an image is "automagically" produced for you. Such a hook opens up endless possibility. It's all about automation and flexibility ...

[curaga]

The point is: even in the case of an image its much more comfortable (faster, easier to maintain, etc.pp.) if you can do it scripted without any manual interaction.

That's quite possible, we have several such scripts in the programming area, and writing your own is about the same work as writing one to run on boot.

The remasters of svolli also come like that: both as images, and as automatic scripts.


I haven't used Suse Studio personally, but if it's anything like the Nimblex creator or rom-o-matic, it wouldn't require such a hook.