Hi all,

I have 5 or so slackware servers, plus three new ones in the cloud. Its getting tough to keep them up to date.

So far my biggest problem is slackpkg isn't completely automatable. It's always prompting for stuff.

Yes, I know the config has BATCH, DIALOG, ONOFF, etc. I dont see them as command line options though. Sometime's I'd like to connect to a box and run slackpkg by hand, with prompts. Sometimes I'd like to automate slackpkg with no prompts. I don't want to edit the config file very time.

Any options I'm missing?

Anyone maintaining multiple servers this way?

Thanks for your time,

-Andy

Hi:

Sorry; I'm not but others here may be and have the experience to chime in and help you.


I can see where that would be a redundant practice and get old quick.
There may be a way to remedy that but I'll have to do research and that could take time.

Which configuration file?
Do you mean the server.config file or the xorg.conf file?

This goes a long way towards what you want:
However, the pattern matching in slackpkg is woeful, and this makes noninteractive usage a big problem. For example I've still not found a way of reinstalling only xorg-server without also getting xorg-server-xephyr, xorg-server-xnest and xorg-server-xvfb. It's not much of a problem when you can deselect them in the dialog menu, but with dialog=off you have to go with what it finds.

Wow. I totally missed that you could do that. I did look at the man page, but expected to see things like:

-dialog


I didn't actually read the section under OPTIONS. (oops).

I think I'll be ok with the matching. I expect to write a script for each update. My first one, for example, will install the openssl updates. I'm hoping, just a bash script that does the install, which I can automate running on all my servers, will be good enough.

Thanks Much.

-Andy

Take a lot at Cluster SSH. Even if it doesn't help with this question, you may find it useful. I know sysadmins who swear by it for administering multiple servers.

I have four servers, two 64-bit and two 32-bit, all Slackware 14.1, all up-to-date with patches. When the two 32-bitters die (they're 10 year old Dell Dimensions), they'll be replaced with 64-bit. All of them are configured identically, same disk partitions (with varying sizes of course), same add-on software, same application software, just compiled separately for the platform with the package spun off to the "other" box and upgraded or installed. I also maintain a few machines for clients, friends and neighbors (both 32- and 64-bit) with a flash drive or a couple of folks that I can get at remotely via SSH.

I have found it easier to just download the patches (from OSUOSL with wget) to a "master" /usr/local/patches then spread them out with scp (on my LAN) and doit toit (ssh and scp are wonderful things). Crack open a remote terminal and have at it: scp, upgradepkg, maybe init 6 and done. One download of each flavor to rule them all.

I will admit that only one of my servers has actually got a display and keyboard (well there is a 64-bit laptop too and it gets done manually via scp) which makes it simple if not automagic. I actually have to type a couple of things. I'm old-fashioned enough that I actually want to watch things happen and deal with any problems that might crop up before something cascades into a major mess (which, with patches is highly unlikely but...). I keep remote GKrellM displays running so I can monitor the things and see what's going on; talk about anal retentive.

Now, four servers and a laptop is pretty darned trivial. If I had to maintain a server farm or sea of desktops, well, that'd be different. I'd probably look into slackpkg or Cluster SSH (interesting, thanks @frankbell). I did look at slackpkg but only wanted patches and, to be honest, I couldn't get my arms around the ins and outs of it and gave up -- I tend to leave well enough alone until there's a Real Good Reason to upgrade to a new(er) release of a package from SlackBuilds (don't have many of those) then do it by hand. That's part lazy and part wait and see and maybe not the best approach but it's what I do and it seems to work fairly well most of the time. If it ain't broke, I really don't want to fix it, lesson learned during a wasted youth I think.

I suppose that there must be a happy medium somewhere or other where you auto check for available updates and notify an administrator that there is an update and the admin decides whether or not to allow it and hits a key and away you go. I just don't have enough trust in letting that happen all by itself -- I visualize streams of smoke and steam rising from machines with alarm bells ringing all over the place at 0300 and shudder at the thought. If you've ever had to rebuild a server because an update failed you'll know what I mean.

The brute idea has been stated but why not have an NFS smb or cifs (I guess) service.
Mirror the tree you're following and have patches exporting.

Have all of your servers mount this storage.

Chronically keep the service up to date with rsync.

Chronically invoke upgradepkg from your servers against the mountpoint.

A trigger would more ideal I guess but that can be up to you.

Does it have to be slackpkg? You could use this script. It fetches updates (only for installed packages) and saves them to "~/patches" (it can also check GPG signatures).

Once complete, issue the following:

I presume you are tracking a stable release, in which case you will only have minor updates (critical fixes and security updates), so you can just kill all the .new config files that are created and Slackware should continue to work ok with the old ones you have configured.

Or you could just leave the new files hanging around. Other than giving you a possible feeling of messiness, they won't cause a problem.

I would suggest have the servers get /usr from a network share, which gives you a single machine you can update, provided there isn't stuff in /lib, /bin or /sbin which is likely to require updating.

That would be ok, except how do you restart services once they are updated? ntp and openssl have both been updated recently. Installing the package is only half the battle.

php is even worse because I use Postgresql as my db, so I have to make sure the pg client works as well.

Nope. I had actually considered it. As long as its consistent enough to script, which this is, but so is slackpkg, it should work for me. But its not just patches I'm interested in.

I'm using slackpkg+ because I have my own repo setup which includes the php-postgresql-client, and a few other custom packages. My cloud servers can hit the repo via http which is quick and easy.

In the office I'm using Eric's mirror-slackware-current.sh to mirror 14.1 stable, and then my slackpkg mirror file points at the local. My cloud boxes just use a regular mirror.

I got Rex working pretty well this weekend:

http://www.rexify.org/

Its perl, which I love, and uses ssh, which I already had setup. So worked pretty well.

One big problem was:

only stopped ssh, it didnt restart. Then I couldnt connect anymore!

This worked howerver:

1 members found this post helpful.

What if you try:

That should prevent the closing ssh connection from exiting the script before it starts sshd back up. Or you could try it within screen, then when you reconnect, it would still have all the output of the command available (which should allow parsing for error messages, if you're attempting that).