Is there a way that I can use up2date to manage multiple installations? The last time I used it, it indicated that it was limited to one machine per user email. TIA, Bill
The free demo account is.. If you pay for an account you can use it for more. Scott On Tue, 18 Mar 2003, Bill Mills-Curran wrote:
Is there a way that I can use up2date to manage multiple installations? The last time I used it, it indicated that it was limited to one machine per user email.
TIA, Bill
_______________________________________________ Wlug mailing list Wlug@mail.wlug.org http://mail.wlug.org/mailman/listinfo/wlug
AFIK this is still the case, unless you subsribe to thier RHN service. with the RHN service you can mannage 100's of boxes supposedly.. Anyone use it on a large install here? I just use it on a few boxes, each one i setup with it's own e-mail so i could still get it for free :) On Tue, 18 Mar 2003, Bill Mills-Curran wrote:
Is there a way that I can use up2date to manage multiple installations? The last time I used it, it indicated that it was limited to one machine per user email.
TIA, Bill
_______________________________________________ Wlug mailing list Wlug@mail.wlug.org http://mail.wlug.org/mailman/listinfo/wlug
-- ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø Karl Hiramoto <karl@hiramoto.org> Work: 978-425-2090 ext 25 Cell: 508-517-4819 Personal web page: http://karl.hiramoto.org/ Freedom: http://www.technojihad.com/ Zoop Productions: http://www.zoop.org/ KTEQ Rapid City: http://www.kteq.org/ AOL IM ID = KarlH420 Yahoo_IM = karl_hiramoto ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø Hackers are just a migratory lifeform with a tropism for computers.
On Tue, Mar 18, 2003 at 03:16:05PM -0500, Bill Mills-Curran wrote: subssn594> Is there a way that I can use up2date to manage multiple subssn594> installations? The last time I used it, it indicated that it was subssn594> limited to one machine per user email. The free demo account is limited to one system per login unless you purchase a subscription. The details of each level of access is available here: https://rhn.redhat.com/preview/index.pxt -- Charles R. Anderson <cra@wpi.edu> / http://angus.ind.wpi.edu/~cra/ PGP Key ID: 49BB5886 Fingerprint: EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 49BB 5886
Is there a way that I can use up2date to manage multiple installations? The last time I used it, it indicated that it was limited to one machine per user email.
I believe you can use a single up2date account to pull down the necessary RPMs and store them locally at which point you can rsync them to your pool of machines and upgrade each that way. BR
On Wed, 19 Mar 2003, Brett Russ wrote:
Date: Wed, 19 Mar 2003 19:31:41 -0500 From: Brett Russ <icycle@charter.net> Reply-To: wlug@mail.wlug.org To: wlug@mail.wlug.org Subject: RE: [Wlug] up2date question
Is there a way that I can use up2date to manage multiple installations? The last time I used it, it indicated that it was limited to one machine per user email.
I believe you can use a single up2date account to pull down the necessary RPMs and store them locally at which point you can rsync them to your pool of machines and upgrade each that way.
BR
For most of the updates, that would work great. The kernel updates are trickier, I understand. Bill
On Thu, Mar 20, 2003 at 08:00:39AM -0500, Bill Mills-Curran wrote: subssn594> > I believe you can use a single up2date account to pull down the necessary subssn594> > RPMs and store them locally at which point you can rsync them to your pool subssn594> > of machines and upgrade each that way. subssn594> For most of the updates, that would work great. The kernel updates subssn594> are trickier, I understand. If you are going to do that, you might as well just do everything manually. It is pretty simple to apply errata manually. I mirror Red Hat's FTP site containing the update packages, and I also wrote a script to maintain a tree of just the latest versions of each package: ftp://angus.ind.wpi.edu/pub/mirrors/redhat/linux/updates (full mirror) ftp://angus.ind.wpi.edu/pub/updates (only latest) The latest-only tree is useful with the "rpm -F" command, and is used in my method below. My method for updates is as follows: 1. Determine if the kernel needs to be updated, and install the correct architecture of the main kernel, -smp, and/or -enterprise packages first. Always use rpm -i, so you install the new kernel without deleting the older kernel versions (in case you need to boot back to the old one if there is a problem): uname -r rpm -qa | grep kernel | sort rpm -ivh i686/kernel-2.4.18-27.8.0.i686.rpm i686/kernel-smp-2.4.18-27.8.0.i686.rpm (If you are not using grub bootloader, you may need to mkinitrd, edit /etc/lilo.conf, and re-run /sbin/lilo. Since at least Red Hat 7.2, if you are using the grub bootloader, everything is automatic.) 2. Next handle other packages that have i586 and/or i686 architectures (currently only glibc and openssl are compiled for i586/i686). Use rpm -F (freshen) to only upgrade what you already have installed. You also need to install the i386 sub-packages of each package at the same time (i.e., install the i686 version of openssl, but also the i386 versions of the openssl-devel and openssl-perl packages at the same time): rpm -Fvh i686/openssl-*.i686.rpm i386/openssl-{devel,perl}*.i386.rpm rpm -Fvh i686/glibc-{,debug}-2.3.2-4.80.i686.rpm i386/glibc-{common,debug-static,devel,profile,utils}*.i386.rpm 3. Finally, freshen everything else. This will automatically skip over the above packages which you already installed: rpm -Fvh i386/*.i386.rpm noarch/*.noarch.rpm 4. If you upgraded the kernel, reboot to the new one. If you upgraded glibc, you might want to reboot too. Otherwise, you can get away with just restarting services that use the upgraded packages (like restarting apache and sshd after an openssl upgrade): service httpd restart service sshd restart shutdown -r now -- Charles R. Anderson <cra@wpi.edu> / http://angus.ind.wpi.edu/~cra/ PGP Key ID: 49BB5886 Fingerprint: EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 49BB 5886
A couple of points I missed in my previous message: It is a good idea to save the output of each rpm command: rpm ... 2>&1 | tee rpm.out especially the last one, so you can see which config files might need to be replaced or merged in with your existing ones (.rpmorig, .rpmnew, and .rpmsave files). For doing a bunch of machines, just NFS export your directory containing the latest-only updates, and mount that on each client to do the updates. My scripts which I use to mirror the updates and maintain the latest-only tree are available here: ftp://angus.ind.wpi.edu/pub/cra-contrib/mirror-tools -- Charles R. Anderson <cra@wpi.edu> / http://angus.ind.wpi.edu/~cra/ PGP Key ID: 49BB5886 Fingerprint: EBA3 A106 7C93 FA07 8E15 3AC2 C367 A0F9 49BB 5886
participants (5)
-
Bill Mills-Curran -
Brett Russ -
Charles R. Anderson -
Karl Hiramoto -
Scott Venier