-   Slackware (
-   -   Headless installation + multi-install management (

abesirovic1 12-30-2012 04:41 PM

Headless installation + multi-install management
Hi there folks,

I am wondering if it is possible to install slackware using something like a seed file with pre-filled values for configuration choices? Or is making some sort of image and just feeding the image an option?

On a related note, I was wondering if there's something for managing multiple slackware boxes from a single interface? Because, for example, updating apache on 50 boxes by hand would be very suicidal (time-wise).

To provide some context for the questions, recently I've been handed the role of admin in my company and our current infrastructure hosts ~20 boxes which are primarily used for development. There's a bunch of systems around there (openSUSE, Debian, Ubuntu, CentOS,...) and I'd like to standardize on a single distribution. Currently the choice is pretty much Debian but I firmly believe that a stripped-down version of Slack with only required packages would work far better. Plus, I'd have something to brag about over beer to my OSS-aware friends :P

So, how enterprise-ready is slack exactly?

Thanks for a great distro and a swell community. I'm hoping for some good discussion and great answers.


TommyC7 12-30-2012 06:59 PM

I think what you might be looking for are "tagfiles." Basically tagfiles tell the installer what to install, and what to skip. A default tagfile exists in all of the directories with the packages in them. For example:

find /path/to/pub/slackware/slackware-<Slackware Version>/slackware -name "tagfile"

Of course, if you're using a 64-bit Slackware, it would be something like:

find /path/to/pub/slackware/slackware64-<Slackware Version>/slackware64 -name "tagfile"
However, you can use your own tagfiles. Make sure the tagfiles are in each subdirectory like Pat has done with his own tagfiles (so you also have an a/tagfile ap/tagfile d/tagfile e/tagfile, etc). Make sure the packages also exist of course, and more importantly make sure it works with the Slackware version you're installing. For example, Slackware 13.37 doesn't have kmod (it has module-init-tools), but Slackware 14.0 does use kmod (apparently it was a replacement or something, I'm not clear on the details). So if you try a 13.37 tagfile that installs kmod with a 14.0 installation, your installation may fail (or your system won't boot).

After you login as root with the installation media, create some random directory, then mount the medium with the custom tagfiles on it. In the provided example, I mount a floppy disk, but you can use a USB, CD/DVD, or whatever:

# mkdir /fake/dir
# mount /dev/fd0 /fake/dir

Now use (c)fdisk to create your partitions, do that LUKS/LVM/mdadm stuff if you want to use it, and then run the "setup" program. When you get to the installation prompt prompter (the page that asks if you want to do a full installation, menu/expert installation or a newbie installation, etc.), at the very bottom you'll see "tagpath" as one of the installation options.

The installer, as it says, will search subdirectories of the directory you provide it. So in my case, /fake/dir/{a,ap,d,e,f,k,...y} all exist, each with their own tagfile, and I type in "/fake/dir" in the prompt. The packages on the installation media will be used, but the tagfile on the other media will be read to know which packages to install.

Now you just sit back, relax and watch that text go by as Slackware installs using your custom tagfiles.

ttk 12-31-2012 08:05 PM

We did something similar for Debian in 2004 at We made bootable USB thumbdrives which automatically partitioned the disks (with parted), installed the kernel, and rsync'd the operating system into place. When a new rack of forty servers arrived, we'd plug forty USB dongles into them, power, and ethernet, turned them on, and let them go through their self-install.

There was no interactive component at all, except when the VAR screwed up and failed to set up the BIOS to boot from USB HDD. That required someone to plug in a keyboard and monitor to tweak the BIOS.

We talked about doing it via DHCP and PXE instead, but we worried that if someone screwed up the configuration, a rebooting production server might re-install itself. I think they did switch to PXE-install some years later, but I was out of there by 2008.

RedHat has similar automatic installation gizmos for the datacenter, like KickStart (extended by SpaceWalk). I got a taste of KickStart at my previous job, and was not impressed at all. It was cryptic and clumsy, and when it failed it tended to fail silently, forcing us to dig deep to figure out the cause. I've often thought of making something similar (but better), but never gave it priority. If you think you can swing it, roll your own. Then at least you'll know its problems intimately, and how to fix them.

To manage large numbers of systems autonomously, Puppet used to be the cat's meow, but it's been surpassed by Chef. Unfortunately doesn't appear to have a build for either (but even if it did, there's no way to guarantee sbopkg won't require interaction without hacking up the script). What you'll want to do is make your own Chef package and have it be installed by whatever you come up with for an automated OS installer.

If you don't like Chef's configuration language, Fabric is a similar beastie (though less developed) which is based on Python.

The good news is, if you install your ssh keys without a public key password, the various and sundry parallel-command tools (like ganglia's gexec, or mssh which opens hundreds of ssh connections simultaneously and let you send commands to all of your servers at once) work just fine with Slackware. I've used mssh to manage multiple Slackware servers, and it scales nicely to about 1200 servers (and with a little hoop-hopping, 20,000 servers).

Frankly, I've been wanting to implement a "Datacenter Linux" based on Slackware since 2009'ish, to do all the things RedHat does to make their OS deployable en masse (but hopefully better), but it just hasn't been a priority, and frankly I wasn't sure if there would be much demand. I *love* Slackware for production servers because it's so reliable and transparent, but most sysadmins take it as gospel that RedHat is "The Solution" for the datacenter, and the Slackware users I've talked to didn't understand the need for such a thing. Maybe I just don't communicate it very well, but they've seemed unconvinced that solutions which work great for one or two PC's might not cut it for bringing up dozens or hundreds of headless servers. So I've just floated along with ad-hoc solutions.

You're literally the first person I've heard (besides myself) expressing a desire for such a solution. Maybe that's enough to warrant starting a project?

abesirovic1 01-01-2013 10:12 AM

TommyC7, thanks for the tip but I know of tagfiles and use them a lot for stripped-down versions of slackware which are purposed to one thing and one thing only - DNS server for example.

ttk, I've been wanting something like this based on slackware purely because of the no-bs approach slack has. While in debian you can make a seed file for debian-installer I haven't heard of something similar for slack. In all honesty, I think that is already overengineering of a simple problem: basically for a VM you can have a bootable prepartitioned disk image onto which you can rsync the system and get a set of text files which configure stuff (like hostname, network and so on).

It all boils down to keeping these "seed" files somewhere in check. In fact I think I'll give it a go to make something like this with slack.

As for chef, I've messed with it a little but (correct me if I'm wrong) chef seems like a lot of work on top to maintain all the recipes, cookbooks, versions and whatnot. Basically I don't see much gain with chef unless I have a purely homogenous environment with 100 cloned VMs.

All times are GMT -5. The time now is 06:00 AM.