Currently, I kickstart my machines over http to install CentOS 4.4 and then in a script called from %post do a "yum -y update" to install all the latest updates. Is there a way to set up the kickstart server so that I can do this all in one step? In other words, is there a "supported" way to roll in all the updates into the kickstart server? In case it matters, I set up the kickstart server by copying the contents of all CentOS 4.4 CDs (well, from the ISO images actually) into one directory, and then configuring the kickstart file to point to that URL (via http).
Thanks, Alfred
why not setup your own cent 4.4 repo..have it rsynch with a mirror which will get the updates for you then you can kickstart to your internal repo?
Alfred von Campe wrote:
Currently, I kickstart my machines over http to install CentOS 4.4 and then in a script called from %post do a "yum -y update" to install all the latest updates. Is there a way to set up the kickstart server so that I can do this all in one step? In other words, is there a "supported" way to roll in all the updates into the kickstart server? In case it matters, I set up the kickstart server by copying the contents of all CentOS 4.4 CDs (well, from the ISO images actually) into one directory, and then configuring the kickstart file to point to that URL (via http).
Thanks, Alfred
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
.
On Feb 27, 2007, at 21:06, William Warren wrote:
why not setup your own cent 4.4 repo..have it rsynch with a mirror which will get the updates for you then you can kickstart to your internal repo?
Hmm, maybe I am overlooking the obvious. I already have a local CentOS mirror that I rsync every night. And every couple of weeks or so I do a "yum -y update" on all my machines, which pull in everything from my local mirror. But when I kickstart a new machine, it installs the original CentOS 4.4 bits, and when I do a "yum -y update" it installs 150+ packages.
I want the kickstart process to include those new packages directly, and for that I would have to modify how things are set up on the kickstart server. Is it just a matter of copying all the RPMs from the yum mirror to the kickstart server. If so, which RPMs do I copy? My yum repository has lots of directories named RPMS:
# find 4.4 -name RPMS 4.4/addons/i386/RPMS 4.4/build/livecd/RPMS 4.4/centosplus/i386/RPMS 4.4/contrib/i386/RPMS 4.4/csgfs/i386/RPMS 4.4/extras/i386/RPMS 4.4/os/i386/CentOS/RPMS 4.4/fasttrack/i386/RPMS 4.4/updates/i386/RPMS
My kickstart server only has one directory name RPMS (if I remember correctly, I can't access it currently).
Alfred
Can't you just point the kickstart files to the local mirror? That way when you do the install you are grabbing the updated files from the get-go.
I don't have a ton of experience with kickstarting machines and i don't run a separate kickstart server for anything i have kickstarted.
Alfred von Campe wrote:
On Feb 27, 2007, at 21:06, William Warren wrote:
why not setup your own cent 4.4 repo..have it rsynch with a mirror which will get the updates for you then you can kickstart to your internal repo?
Hmm, maybe I am overlooking the obvious. I already have a local CentOS mirror that I rsync every night. And every couple of weeks or so I do a "yum -y update" on all my machines, which pull in everything from my local mirror. But when I kickstart a new machine, it installs the original CentOS 4.4 bits, and when I do a "yum -y update" it installs 150+ packages.
I want the kickstart process to include those new packages directly, and for that I would have to modify how things are set up on the kickstart server. Is it just a matter of copying all the RPMs from the yum mirror to the kickstart server. If so, which RPMs do I copy? My yum repository has lots of directories named RPMS:
# find 4.4 -name RPMS 4.4/addons/i386/RPMS 4.4/build/livecd/RPMS 4.4/centosplus/i386/RPMS 4.4/contrib/i386/RPMS 4.4/csgfs/i386/RPMS 4.4/extras/i386/RPMS 4.4/os/i386/CentOS/RPMS 4.4/fasttrack/i386/RPMS 4.4/updates/i386/RPMS
My kickstart server only has one directory name RPMS (if I remember correctly, I can't access it currently).
Alfred
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
.
On 28/02/07, William Warren hescominsoon@emmanuelcomputerconsulting.com wrote:
Can't you just point the kickstart files to the local mirror? That way when you do the install you are grabbing the updated files from the get-go.
I think what Alfred's asking is how does he roll the updates from (for example for i386) /centos-4/4.4/updates/i386/RPMS/ into /centos-4/4.4/os/i386/CentOS/RPMS/ so that when he Kickstart builds a system it's already using the latest versions of updated RPMS where applicable. Rather than building from a pristine 4.4 repository then having to 'yum update' after the install.
I have a vague recollection of having read how to do with with RHAS 2.1 a few years back so in principle I guess it's possible.
I'd build a list of updated packages, minus the version/release numbers. Create a copy of /centos-4/4.4/updates/i386/RPMS/, remove all the default versions of packages updated from there and drop copies of the latest in instead and try a build from that test tree. He might have to munge some of the XML package manifest stuff too.
Will.
So why not just put yum -y update in the %post section of the kickstart?
-Drew
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of William Warren Sent: Tuesday, February 27, 2007 9:25 PM To: CentOS mailing list Subject: Re: [CentOS] Kickstart with all the latest updates?
Can't you just point the kickstart files to the local mirror? That way when you do the install you are grabbing the updated files from the get-go.
I don't have a ton of experience with kickstarting machines and i don't run a separate kickstart server for anything i have kickstarted.
Alfred von Campe wrote:
On Feb 27, 2007, at 21:06, William Warren wrote:
why not setup your own cent 4.4 repo..have it rsynch with a mirror which will get the updates for you then you can kickstart to your internal repo?
Hmm, maybe I am overlooking the obvious. I already have a local CentOS mirror that I rsync every night. And every couple of weeks or so I do a "yum -y update" on all my machines, which pull in everything
from my local mirror. But when I kickstart a new machine, it installs
the original CentOS 4.4 bits, and when I do a "yum -y update" it installs 150+ packages.
I want the kickstart process to include those new packages directly, and for that I would have to modify how things are set up on the kickstart server. Is it just a matter of copying all the RPMs from the yum mirror to the kickstart server. If so, which RPMs do I copy?
My yum repository has lots of directories named RPMS:
# find 4.4 -name RPMS 4.4/addons/i386/RPMS 4.4/build/livecd/RPMS 4.4/centosplus/i386/RPMS 4.4/contrib/i386/RPMS 4.4/csgfs/i386/RPMS 4.4/extras/i386/RPMS 4.4/os/i386/CentOS/RPMS 4.4/fasttrack/i386/RPMS 4.4/updates/i386/RPMS
My kickstart server only has one directory name RPMS (if I remember correctly, I can't access it currently).
Alfred
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
.
-- My "Foundation" verse: Isa 54:17 No weapon that is formed against thee shall prosper; and every tongue that shall rise against thee in judgment thou shalt condemn. This is the heritage of the servants of the LORD, and their righteousness is of me, saith the LORD.
-- carpe ductum -- "Grab the tape" CDTT (Certified Duct Tape Technician)
Linux user #322099 Machines: 206822 256638 276825 http://counter.li.org/ _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 28/02/07, Drew Weaver drew.weaver@thenap.com wrote:
So why not just put yum -y update in the %post section of the kickstart?
Because that's explicitly what he didn't want to do in the initial question.
"Currently, I kickstart my machines over http to install CentOS 4.4 and then in a script called from %post do a "yum -y update" to install all the latest updates. Is there a way to set up the kickstart server so that I can do this all in one step?"
The reasons why, your guess is as good as mine. If the machine's part of an automated provisioning system and is, at least in a network sense, exposed to untrusted users from the instant it's available perhaps he's like the box patched up ASAP?
Will.
On 28/02/07, Drew Weaver drew.weaver@thenap.com wrote:
So why not just put yum -y update in the %post section of the kickstart?
Because that's explicitly what he didn't want to do in the initial question.
Yes, exactly.
The reasons why, your guess is as good as mine. If the machine's part of an automated provisioning system and is, at least in a network sense, exposed to untrusted users from the instant it's available perhaps he's like the box patched up ASAP?
No, it's not really for security reasons. It's for performance (or efficiency). Doing the "yum -y update" in the %post adds considerable time to the total install. I'm working on creating a CentOS VM to be used here at work, and while I'm still in the testing phase, I'd like to reduce the turnaround time. Also, I think I can reduce the VM footprint if I install the final version of all the RPMS initially, instead of installing 4.4 first and then all the updates.
Alfred
On Feb 28, 2007, at 9:48 AM, Alfred von Campe wrote:
The reasons why, your guess is as good as mine. If the machine's part of an automated provisioning system and is, at least in a network sense, exposed to untrusted users from the instant it's available perhaps he's like the box patched up ASAP?
No, it's not really for security reasons. It's for performance (or efficiency). Doing the "yum -y update" in the %post adds considerable time to the total install. I'm working on creating a CentOS VM to be used here at work, and while I'm still in the testing phase, I'd like to reduce the turnaround time. Also, I think I can reduce the VM footprint if I install the final version of all the RPMS initially, instead of installing 4.4 first and then all the updates.
this document may be of assistance:
http://tldp.org/HOWTO/RedHat-CD-HOWTO/index.html
in particular, section 5, "Including the updates", tells you about the comps.xml file, which defines the packages that make up a distribution. you'll need to move the updated packages into place, then edit comps.xml so that it knows about the updated packages, then run genhdlist to create base/hdlist and base/hdlist2.
more useful links can be found in this thread from the archives:
http://lists.centos.org/pipermail/centos/2005-July/049047.html
good luck, -steve
p.s. since you're doing this on a VM, why not save a snapshot of a pristine build and just revert to that, instead of rebuilding and rebuilding new VMs?
-- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
No, it's not really for security reasons. It's for performance (or efficiency). Doing the "yum -y update" in the %post adds considerable time to the total install. I'm working on creating a CentOS VM to be used here at work, and while I'm still in the testing phase, I'd like to reduce the turnaround time. Also, I think I can reduce the VM footprint if I install the final version of all the RPMS initially, instead of installing 4.4 first and then all the updates.
Without re-rolling the install tree, there isn't much way to accomplish building the updates into the installer. You would have to do the install via %post, though with a local repository this shouldn't be overly long.
The alternative (which is much more work) would be to check out the /build directory on the mirrors and consider building new install media with the updates rolled in. Personally this isn't really worth the effort to me.
On Feb 28, 2007, at 10:14, Jim Perrin wrote:
Without re-rolling the install tree, there isn't much way to accomplish building the updates into the installer.
I guess this confirms that I am not overlooking something obvious, and that what I am trying to do is "hard". I'll stick with my current method of doing a "yum -y update" in the kickstart %post, and I may investigate the suggestion of using VMware snapshots (although that doesn't quite accomplish what I am trying to do).
Alfred
On Wed, 2007-02-28 at 15:21 -0500, Alfred von Campe wrote:
On Feb 28, 2007, at 10:14, Jim Perrin wrote:
Without re-rolling the install tree, there isn't much way to accomplish building the updates into the installer.
I guess this confirms that I am not overlooking something obvious, and that what I am trying to do is "hard". I'll stick with my current method of doing a "yum -y update" in the kickstart %post, and I may investigate the suggestion of using VMware snapshots (although that doesn't quite accomplish what I am trying to do).
What is hard in CentOS-3 and CentOS-4 (roll in updates as part of the install) will be much easier in EL5. The anaconda there uses yum to do the installs and it is as easy as pointing to the proper updates repo to do this in EL5.
So ... you will be able to do this soon :P
What is hard in CentOS-3 and CentOS-4 (roll in updates as part of the install) will be much easier in EL5. The anaconda there uses yum to do the installs and it is as easy as pointing to the proper updates repo to do this in EL5.
So ... you will be able to do this soon :P
Superb.
FWIW, I wanted to do exactly what the original poster asked about - install all the latest RPMs from the start to save the time of installing a package that would be immediately replaced in the %post phase. This thread tells me where to look if I want to pursue that further. The other tactic I was considering is one a collegue of mine uses, just install the bare minimum during kickstart and then have our configuration manager (cfengine) install all the rest of the packages after the first reboot. That would make my total install time faster - but would involve a fair amount of effort on my part to change where I specify packages for my different server classes. Since I don't have a lot of machines and don't reinstall them very often, I decided it wasn't worth the hassle.
Alfred von Campe wrote:
On Feb 28, 2007, at 10:14, Jim Perrin wrote:
Without re-rolling the install tree, there isn't much way to accomplish building the updates into the installer.
I guess this confirms that I am not overlooking something obvious, and that what I am trying to do is "hard".
I have a script to do so, except for finding out which rpms are to be updated. would the following approach be ok?
- install a system manually, do whatever yum update/remove/install - do rpm -qa to get the list of installed rpms - if they are on the CD, copy them - otherwise, download them
I'll stick with my current method of doing a "yum -y update" in the kickstart %post, and I may investigate the suggestion of using VMware snapshots (although that doesn't quite accomplish what I am trying to do).
mouss wrote:
Alfred von Campe wrote:
On Feb 28, 2007, at 10:14, Jim Perrin wrote:
Without re-rolling the install tree, there isn't much way to accomplish building the updates into the installer.
I guess this confirms that I am not overlooking something obvious, and that what I am trying to do is "hard".
I have a script to do so, except for finding out which rpms are to be updated. would the following approach be ok?
- install a system manually, do whatever yum update/remove/install
- do rpm -qa to get the list of installed rpms
- if they are on the CD, copy them
- otherwise, download them
I'll stick with my current method of doing a "yum -y update" in the kickstart %post, and I may investigate the suggestion of using VMware snapshots (although that doesn't quite accomplish what I am trying to do).
What I've found that works fairly well is to do the following steps:
1. copy the DVD installation tree from the DVD .iso to a working directory 2. copy available updated RPMS (typically with "rsync") from a mirror site into the CentOS/RPMS directory 3. use the "repomanage.py" utility from the "yum-utils" package to remove superseded RPMs (with the "-o" argument):
repomanage.py -o <base>/CentOS/RPMS | xargs rm -f
4. Regenerate the hdlist file on the DVD image (requires the anaconda-runtime package to be installed):
/usr/lib/anaconda-runtime/genhdlist --productpath CentOS <base>
-Greg
-
Alfred von Campe -
Cynthia Kiser -
Drew Weaver -
Greg Bailey -
Jim Perrin -
Johnny Hughes -
mouss -
Steve Huff -
Will McDonald -
William Warren