I'm going to rebuild a computer for a friend of mine. I'm going to install 12.2 in it and wanted to see if there was a way to install patches automatically from a cron. I don't think slackpkg can do such thing as a cron, correct? For anyone that set up a Slackware box for someone with little Linux knowledge, how did you handle the ability for the person to update the box?

Thanks ahead of time!

I know slapt-get has a GTK frontend (gslapt-get) that makes upgrading the system very easy.

You could automate one of the package managers to do it, or even just rsync the /patches directory and run upgradepkg on it. I am not aware of an existing script to do this, but it shouldn't be hard. The only issue I could see with slackpkg would be how to supress the messages about .new files (or really, how to handle the .new files at all).

Unattended upgrades are not recommended.

That's what I thought. I maybe I can teach him how to do it through the command line.

I use swaret, I have not found a way to use slackpkg for auto updates.
setup swaret then a daily cron as follows seems to work

#!/bin/bash
swaret --update
swaret --upgrade -a

You are going to have to be very careful about kernel updates and lilo.

I second that. That's the one who has the potential to leave the box in an unbootable state.

Of course ensure that your /etc/swaret.conf has
EXCLUDE=kernel lilo
which is what I believe to the be default.

You'll also need to figure out a way of handling the *.new files that occur from time to time. IMO it's going to be more trouble than it's worth.

Does anybody know of a good way of doing this in Slackware then?
So far it seems that we think slackpkg and swaret are not going to work.
How is this done then? A way to install patches automatically from a cron for Slackware.

I have 10 systems that need to be updated, and I don't want to do it manually if I can avoid it, and stormtracknole question remains unanswered.

It's not that I think it won't work 9 out of 10 times. I think if you stick with stable and blacklist the kernel packages then you will be fairly safe. I think it's likely that you might run into trouble often enough that it might not be worth the hastle, although it's a decision you have to make. Of course I think one of the major features of Slackware to most users is not having automatic updates all the time. You'll need to turn off interactive mode in /etc/slackpkg/slackpkg.conf And add some sort of action for the .new files. As I mentioned before, blacklisting kernel packages in /etc/slackpkg/blacklist is probably a good idea to prevent the need to run lilo. This still leaves kernel updates to the end user.

As a side note, if you are upgrading multiple machines, it's probably a good idea to use Eric's mirror-slackware-current.sh in a cron job to keep an updated local mirror so that you are only downloading once or twice from the mirror. This will require you to update the /etc/slackpkg/mirrors files to point to your local mirror. The mirror script can be used to keep stable up to date although it defaults to current so be careful. Finally I would say to leave at least 24 hours between the mirror script and slackpkg if you go that route to ensure that the mirror has had time to fully sync.


And probably the most important bit is to TEST THIS ON A SPARE MACHINE before moving to multiple machines.
HTH.

Managing automation of updates over a large install base is a sys-admin's "meat and potatoes". When you're talking 10+ machines you're getting into this territory. The usual approach is a centrally managed repository where the admin can drop update scripts that the target machines pull from on a schedule or when triggered. It's not difficult to script the mechanisms for this using any number of methods and slackware's simplistic package management and tools are well suited to this. In fact, when you think about it, this is exactly what debian, Redhat, SUSE and Canonical are doing: treating their customers machines exactly in this manner. The difference of course is that they're making all the decisions and you've surrendered control.

This doesn't really address stormtracknole's situation though. Slackware isn't a hands-off distro where you have surrendered control to some central authority and that freedom comes at a cost in maintenance effort. I don't think there is a good way to completely automate slackware updates on a small scale, though as I hope I've shown above, doing so on a medium-large scale should be relatively easy.

Things have not changed much in 5 years. Here is a post from that era: http://www.linuxquestions.org/questi...5/#post1388833

This uses GazL's approach of a centrally managed repository which I called /ourpatches. I had it running when written but have not maintained it. Thus you will have to figure out how to add a -patch mode to the current upgradepkg using the old diff file as a guide.

The downside is every time a 'remote host' is booted it will hammer the server for patches and then display a stream of messages where a particular package was not found, or a particular package is current (that's what original upgradepkg did back then) or it will actually upgrade a package and reboot the remote host.

I suspect rc.patch -find could be run from cron which would eliminate users having to shutdown their computer every night.

ppd

I had forgotten about this thread. I ended up telling my friend to just run slackpkg through the command line. He's been running Slackware with no problems yet. I'm not a fan of unattended upgrades either, but just wanted to research about the possibility of doing so.