[arch-general] script idea - update single arch box -> updates all on local net
Guys, I've played with an idea to save time with updates and duplicate (old version) removal from /var/cache/pacman/pkg for all arch boxes on a local network. I thought I would pass along the idea and the scripts as they exist now. Requirements: - public key/private key ssh access for user between boxes on the lan (id_dsa) - sudo rights for user on each box Config: - all script calls to additional scripts are to symlinks in /usr/local/bin Operation: pmduprsync.sh - is the outside script that runs pacman -Syu --noconfirm on a box on the lan (you can nix the --noconfirm if you want to review). -- it then calls fduparch.sh (which just sets the directories to remove old version of the packages from/to (I've posted a full description before). Which then calls: -- fduppkg (the actual script that scans /var/cache/pacman/pkg and moves old versions of packages to another directory of your chosing. (currently /home/backup/pkg-old for me) -- fduparch.sh runs a second time for me to remove old versions from /home/backup/pkg-old to /home/backup/pkg-older (original I know) pmduprsync.sh grabs a md5sum of the /var/cache/pacman/pkg dir on the remote hosts of the same arch and then rsyncs /var/cache/pacman/pkg dir to remote host and grabs another md5sum. If the sums differ, then pacman -Syu --noconfirm is called on the remote host following by fduparch.sh to tidy up the /var/cache/pacman/pkg dir there. For me the benefit is I keep a current package set for all boxes in the package dir of each host (not an issue in the days of 1T drives). Further, bandwidth reduction. Packages are only downloaded once and rsynced between boxes. Now granted the --noconfirm isn't optimal, and I always check first before pulling the trigger, but the automation of checking what an update will include on one host (generally the host with the widest package selection) and then having the updates daisy-chain to all other arch boxes on the lan while tidying up /var/cache/pacman/pkg on each box is a big plus. Currently you will see that I've just hard coded which hosts are i686 and x86_64 in pmduprsync.sh (easy at home - only 4 boxes 2 of each arch), but there is no reason why either an i686/x86_64 host list file couldn't be automagically built with some type of subnet host query followed up with ssh 'uname -r' calls. Anyway here are the scripts in case it sparks an idea with someone else. Regardless of whether you want the auto update part, the scripts that move old versions of packages from /var/cache/pacman/pkg have served me well. http://www.3111skyline.com/dl/Archlinux/scripts/pmduprsync.sh http://www.3111skyline.com/dl/Archlinux/scripts/fduparch.sh http://www.3111skyline.com/dl/Archlinux/scripts/fduppkg Once I refine the logic in the update script a bit more and the collection of hosts with the same arch on the lan, I'll follow up. All the scripts are my original work and are gpl, so use, reuse, tear apart at will. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
On Thu, Dec 2, 2010 at 5:36 PM, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
Guys,
I've played with an idea to save time with updates and duplicate (old version) removal from /var/cache/pacman/pkg for all arch boxes on a local network. I thought I would pass along the idea and the scripts as they exist now.
I'm not criticizing your solution by any means, but have you looked over pkgd, from Xyne [1]? It does what you want and even more transparently. I never used it, because I don't need, but it's one of those things I would love to have a need :) The documentation is so tempting, with that big blue graph... (nerd pr0n at its best...) [1] http://xyne.archlinux.ca/projects/pkgd/ -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------
On 12/02/2010 01:53 PM, Denis A. Altoé Falqueto wrote:
I'm not criticizing your solution by any means, but have you looked over pkgd, from Xyne [1]? It does what you want and even more transparently. I never used it, because I don't need, but it's one of those things I would love to have a need:) The documentation is so tempting, with that big blue graph... (nerd pr0n at its best...)
Completely overlooked :p Thanks. I will have fun with this... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
participants (2)
-
David C. Rankin
-
Denis A. Altoé Falqueto