[Fedora-xen] Xen Guest Installation question

Wed May 9 19:46:54 UTC 2007

On Sunday 06 May 2007 05:21pm, John Summerfield wrote:
> Lamont Peterson wrote:
> > On Tuesday 01 May 2007 09:05am, Willemann, Phil wrote:
[snip]
> >> Here are the questions
> >>
> >> 1.  If I want to use http or NFS, do I copy the entire FC3 Install CD to
> >> some place on the hard drive?  Is the copy a *.iso file or is it the
> >> individual          files from the CD?  This has never been clear for
> >> me.  I have seen conflicting information on the net about this
> >
> > Either.
> >
> > You can copy all files from each CD turn into a directory and share that
> > via NFS or HTTP (or FTP) for network installs. To copy the CDs, mount
> > them one by one,
> > run "cp -a /media/cdrom/* /wherever/you/want/it/", "umount
> > /media/cdrom/", do the same with the next CD and so on until they are all
> > copied over.  Make sure to use the same destination directory for the cp
> > command every time. Substitute whatever path your CD/DVD drive mounts at
> > for /media/cdrom/ if that's not the right value.
>
> I am sure this does not work well with the advent of yum repos on
> install media. It's okay if you have a DVD image (there is only one),
> but from CD there will be problems.

You know, come to think of it, I haven't tried with the CD images since FC3.  
As FC5 and later have the yum repo on the CDs, I could see how that might be 
a problem.  As I don't have the CD images handy at the moment, I can't look 
to see what's really up, however, I find it hard to fathom that the first CD 
wouldn't just have the whole repo on it.

It does work with the DVD; we do it all the time.

> I've not yet see documentation, but I think a createrepo command will
> fix it.

I'm sure re-running createrepo on any repo will not, at the very least,  harm 
anything and so it should be safe.

> BUT, the files will be ro,

When copied from the CDs, yup.

> so something like this would be the go: 
> find <newrepo> -type d -exec chmod 755 {} \;
> find <newrepo> ! -type d -exec chmod 644 {} \;
>
> Let's not have the xargs argument today, okay?

NP :) .  Personally, I go either way on this, sometimes using xargs and 
sometimes using find's -exec. However, since we're talking about yum and 
xargs a little here, i have had problems when using something like:

 rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}" | grep "i[36]
86$" | xargs yum remove

Obviously, this is something one might construct on an AMD64 system if they 
were trying to eradicate all the x86 packages.  The result is that yum 
processes all the deps, prints the list, prints the "Do you want to proceed" 
(however it's phrased) prompt and then crashes and pukes.  If the command is 
rewritten as this (I would probably use backticks when typing on the command 
line, but the $( ... ) suntax might be less comfusing to some), it works just 
fine:

 yum remove $(rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}" | 
grep "i[36]86$")

I'm sure it's got to be a problem with yum and/or python not liking something 
about the way xargs is feeding it the list of arguments.

> Just to show I know, you 
> might also want this:
> find <newrepo> -name TRANS.TBL -print0 \
>
>    | xargs -0 rm -f --no-run-if-empty

I'm not sure why the "-print0" on your find command.  I've always just run:

 find <whatever_dir> -name TRANS.TBL | xargs rm -f

The same thing works to get rid of dirs, too:

 find <whatever_dir> -type d -name CVS | xargs rm -R

> Also, there are (probably) some filenames duplicated*, so the original
> cp might be
> cp -f <etc>

Unnecessary as cp -a will handle that just fine.  There are dups if for 
nothing else than the TRANS.TBL files.

BTW, to do this with SUSE's CD sets, you have to be sure you copy the *first* 
CD *last*.  Usually, people just copy the CDs in reverse order.  It been 
quite a long time since I used SUSE's CDs for this, as their DVDs have a 
significantly larger number of packages than the CD sets do (I guess they 
just said, "Hey, we don't want to ship more than 5 CDs ever again, so put all 
the rest on the DVD and leave it out of the CD set").

> The find ... xargs ... removes those I know about.
>
> > As of Red Hat Linux 7.2 (IIRC), which is a long time ago now, you can
> > also just place the .iso images of the CDs (or of the DVD) in a directory
> > and do NFS network installs (HTTP and FTP do not support this).
> >
> >> 2.  If I use http where do I put the files. (under /var/www/...??)
> >
> > If you're not familiar with how to configure Apache, you should probably
> > just use NFS (it gives better performance anyway).  The other option is
> > to create a subdirectory under /var/www/html/ (on Red Hat,
> > /var/www/htdocs/ or /srv/www/htdocs/ on almost all other systems) on the
> > web server computer you want to use and then put the contents of the CDs
> > in there
>
> This is one way. I configure a virtual host for each distro, so each has
> its own name space.

Why bother with separate virtual hosts?  That's just extra work for no 
benefit.  When I do this with HTTP (which I almost never do, BTW, as NFS is 
faster for installs), I simply create one virtual host called something 
like "os.example.com" and then create a dir for each distro under 
there; "http://os.example.com/FC5/", "http://os.example.com/FC6/" 
and "http://os.example.com/RHEL5/", for example.

Then, as new distros are added or removed, there's no editing of web server 
configs (or restarting/reloading the server); I simply create appropriate 
directories and destroy them later when I no longer want them around.

> Placing the tree outside /var/www is possible,

Absolutely, but the original post seemed to me to indicate that he was rather 
unfamiliar with Apache (and probably SELinux), so I stuck with the default 
location, even though I didn't like it.

> but selinux steps on your 
> toes.

Yeah, but it's really easy to fix these days.

> >> 3.  I made a directory called /tmptest and copied the iso image to it.
> >> I edited the /etc/exports file and added a line like this
> >>     /tmptest   192.168.107.14(rw,sync)  <-- I assumed this means
>
> I prefer not to litter the root directory; I generally use /var/local
> (and sometimes have a whole disk there), others (I think) use /local

I can see that.  In this case, I chose to stick with the directory that the OP 
used so as not to confuse the issue.

Personally, I'm not a fan of having to type in all the extra path info 
everytime I want to do an NFS mount.  Putting all of your exports under some 
other dir tree doesn't provide any security benefit and simply means that 
every mout needs more typing.  So, I have dirs like "/doenload/ and /os/ on 
my file server.  That way, my NFS mount commands are simply:

 mount server:/os/ /mnt/os/

Also, as many of those same dirs are shared bia both NFS and SMB (using samba, 
of course), this lets me make the SMB share name the same as the NFS path, 
which is much easier for everyone to use.

> > There is no reason to make it rw, use ro for something like this.  It's
> > important security-wise.
>
> I managed to delete lots that way once; I was using the then-new (but
> not mine I hasten to add) script to create a rescue compact disk, and it
> had to be run as root. There was a bug in it.... It's saner now.

hehe :) That's *exactly* the kind of story I had in mind when writing about 
the "evils of rw where writing isn't needed".

[snip]
-- 
Lamont Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]

NOTE:  All messages from this email address should be digitally signed with my
       0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as
       well as other keyservers that sync with MIT's.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-xen/attachments/20070509/a71b988e/attachment.sig>