Re: Question about slackpkg
Niki Kovacs wrote:
[color=blue]
> Now I wonder about a strategy to keep all these installs up to date.
> By that, I don't mean running current/, but essentially 1) upgrading
> packages for security fixes, and 2) installing and/or upgrading
> selfmade packages, that I eventually rebuild, and that I intend to
> store on a custom repo.[/color]
See if something like
[url]http://www.therockgarden.ca/software/slackware/UPGRADE.sh[/url] would be
useful to you. It makes use of Slackware's own package management
utilities to keep the system up to date. You could run it regularly
from cron on a central system to download updated packages, then push
those updates to your other systems.
You'll very certainly need to edit some of the variables being set near
the top of the script. I hope it helps ...
--
----------------------------------------------------------------------
Sylvain Robitaille [email]syl@alcor.concordia.ca[/email]
Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------
Re: Question about slackpkg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2007-11-28, Niki Kovacs <mickey@mouse.com> wrote:[color=blue]
> I'll soon have to handle something like 30 desktop machines all running
> Slackware 12.0. I've already written a tight set of tagfiles, rebuilt
> some packages (mostly KDE to unclutter it), added some packages (from
> slackbuilds.org or myself) and wrote a packet of docs for personal use.
>
> Now I wonder about a strategy to keep all these installs up to date.[/color]
What I would do is have a 31st machine running the same software that
you can test updates on. Then have a central machine running an rsync
server. Once you test out an upgrade, push the package to that rsync
server. All the other 30 machines grab those packages via rsync, then
run upgradepkg on them. You could even do this on an NFS mounted
partition if everything is on your LAN.
Optionally, you could have a script that would call upgradepkg on these
files before or after running pre-install and post-install scripts
pulled via rsync (or NFS). This would let you upgrade some things that
aren't so easy to handle without physical access (think: glibc and the
like, or a kernel).
- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHTc1OrZS6hX/gvjoRAq9dAKCDqsLegP+7U8xCN4Xe/I2nnjPbSwCfTBzj
+n9zRls4h2iHwDUdeBqkR5c=
=X1fo
-----END PGP SIGNATURE-----
Re: Question about slackpkg
Niki Kovacs <mickey@mouse.com> wrote:[color=blue]
> Now I wonder about a strategy to keep all these installs up to date.[/color]
I have an NFS mounted directory called updates. This directory contains
symbolic links to packages in patches as well as custom packages in other
directories. The updates directory also contains a Makefile which all
machines run from a cron job every night. That Makefile checks if there is
any new package in updates that doesn't have any up to date log file in
/var/log/packages. If so, the new package is installed with "upgradepkg
--install-new".
When a new version of a package is added with a link to updates it is
important to remove the link to the older package. Otherwise upgradepkg
will alter between those two versions every night.
If you want I can send you the Makefile. I use the same Makefile for both
Slackware 12 and Slackware 9.1, but of course I have different NFS mounted
updates directories for different versions of Slackware.
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc1(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost
Re: Question about slackpkg
Le Wed, 28 Nov 2007 20:19:11 +0000, +Alan Hicks+ a écritÂ*:[color=blue]
>
> What I would do is have a 31st machine running the same software that
> you can test updates on. Then have a central machine running an rsync
> server. Once you test out an upgrade, push the package to that rsync
> server. All the other 30 machines grab those packages via rsync, then
> run upgradepkg on them. You could even do this on an NFS mounted
> partition if everything is on your LAN.
>
> Optionally, you could have a script that would call upgradepkg on these
> files before or after running pre-install and post-install scripts
> pulled via rsync (or NFS). This would let you upgrade some things that
> aren't so easy to handle without physical access (think: glibc and the
> like, or a kernel).[/color]
That sounds like a good idea. And yes, I had planned that 31st machine in
any case.
cheers,
Niki