Question about slackpkg - Slackware

This is a discussion on Question about slackpkg - Slackware ; Hi, 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Question about slackpkg

  1. Question about slackpkg

    Hi,

    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. 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.

    A friend of mine (also running Slackware) has shown me swaret, which
    seems nice to handle such a task. But before I give it a try, I'd like to
    know if slackpkg can handle this. As far as I understand, it's only
    possible to handle updates from original custom repos. Or is it possible
    somehow to create my own custom repo and then handle it with slackpkg?

    A laconic answer will do, I'll check the docs eventually. I just have to
    get organizized, as Travis Bickle said smilingly D

    cheers,

    Niki

  2. Re: Question about slackpkg

    Niki Kovacs wrote:

    > 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.


    See if something like
    http://www.therockgarden.ca/software...are/UPGRADE.sh 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 syl@alcor.concordia.ca

    Systems and Network analyst Concordia University
    Instructional & Information Technology Montreal, Quebec, Canada
    ----------------------------------------------------------------------

  3. Re: Question about slackpkg

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On 2007-11-28, Niki Kovacs wrote:
    > 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.


    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-----

  4. Re: Question about slackpkg

    Niki Kovacs wrote:
    > Now I wonder about a strategy to keep all these installs up to date.


    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


  5. Re: Question about slackpkg

    Le Wed, 28 Nov 2007 20:19:11 +0000, +Alan Hicks+ a √©crit¬*:
    >
    > 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).


    That sounds like a good idea. And yes, I had planned that 31st machine in
    any case.

    cheers,

    Niki

+ Reply to Thread