Tuesday, December 27. 2011
With the release of Grml 2011.12 we were regularly asked what distinguishes Grml from other Live-CDs. The following items lists some reasons why you should consider using Grml instead of another Distribution for Installation&Rescue :
What are your reasons using Grml instead of other Live CDs? What are you missing from Grml?
Display comments as (Linear | Threaded)
What am I missing: It would be great if Grml would enable the serial console by default to fit headless machines. I use Grml as a rescue system for virtual machines with Qemu/KVM and the serial console is the most comfortable way to use it. But I always have to connect via VNC first to select the correct boot option. Sure, I could make a custom ISO (I propably should do so) but that keeps me from updating frequently to the newest release.
To answer your question, why grml, and I'm quite suprised it is not in your list: Automated startup using GRMLCFG and grml.sh. This also solves Bernd's problem (see below). That is, scripted configuration after booting without installing. Just create a usb stick with two partions. First holds grml to boot, the other labeled GRMLCFG holding grml.sh. No need for custom boot options, therefore no need for your own customized grml iso, let grml.sh do the work afterwards. Makes updates easy too, just dd the image to the stick and test that grml.sh still works. Read /etc/grml_version and even support different releases. I'm using grml primarily to run diskless (read: no OS uninstalled) backup servers which export their storage via VPN and iSCSI. I've yet to check if this setup still works with 2011.12 given the iSCSI switch and the omission of tools such as buffer or expect. Secondary usage is for remote access on broken systems which are otherwise unreachable. Give usb stick to someone, tell him to boot from it: Scripted grml.sh starts sshd, vpn, etc. Last but not least, I also use grml as rescue system im virtual machines. Guess what I'm doing for serial access: grml.sh on a virtual floppy image configures the serial console (modify /etc/inittab, SIGHUP init, etc). Maybe I should have posted this on the mailing-list, right?
We thought about enabling serial console per default but decided against it. The problem is there maybe machines which don't have a console on there serial interface but other HW like UPS. This may unintentionally break things. Thats the whole reasone why we did not enable serial console per default
Really nice description thanks. I just totally forgot about GRMLCFG. If i create a new list I'm sure to mention it. Re. iSCSI you hopefully don't need any expect as the commands should be scriptable (it seems you can just modify the configfs manually anyway) Btw. it is nice to see and hear advanced setups :)
No, I don't need expect for iSCSI. However, it's really useful for scripting highly interactive stuff, like even passwd! Expect is good to have when needed, say, simple input redirection fails. Fortunately, apt-get is your friend: I check for missing commands in my grml.sh and run apt-get if necessary.
JFTR to automatically update passwords you can use chpasswd. There is no need for using expect to change a password.
Yes, passwd was only supposed to be an example for a very interactive program, i.e. where input redirection is hard. For passwords, I usually insert the hash in /etc/shadow directly.
I am asking as we are currently discussing if we should add expect back onto the CD image. And I currently honestly don't think we should put it back as i don't see an usecase on a live-cd.
Well, I see grml as a live-cd which is (because of the targeted users, console) highly scriptable with _persistent_ scripts (on usb-stick or else), read: live-cd for automation (no need for X11). Expect is one of the core tools for automatisation where special tools (like chpasswd) are missing or non-interactive usage is not supported. Main advantages with expect: a) can talk to pretty much anything, b) highly configurable/scriptable and c) autoexpect allows for an easy quickstart. Therefore, I'd really favour the inclusion of expect. Please try to view grml not only as a live-cd for solely interactive human use. What about as a diskless OS? Any other live-cds usually target the Desktop and are therefore missing the tools. Except for grml which has (had) everything including excellent autoconfiguration that makes it almost hardware independent. I cannot think of an alternative. Shouldn't we take this to the mailinglist? Maybe more people think of grml not only as a rescue live-cd. There is definitely more to grml! user or devel?
Feel free to either start a new thread or reply to the existing ones. If it is about the packages i think grml-devel would be more appropriate.