Network Installations via RHN Proxy Servers

While I know there is no official support for this, everyone
must do
it or arrange network installs from somewhere else. We
maintain
network install trees for RHEL3, RHEL4, FC5, and FC6
currently and I
am getting tired of doing an installation and then needing
to apply
hundreds of updates immediately after a fresh install.

It doesn't seem to me that it would be that difficult to
update the
installation trees as packages are updated so a fresh
install will be
current right after it finishes. I am quite capable of not
understanding why some things are problematic though. At
least that
would be a lot nicer for users who do interactive installs.

Can someone tell me what would need to be changed in these
trees? I'm
thinking some repodata mods would be required for the fedora
side and
perhaps something in the base directory on the RHEL side.
And then
there is the question of how to get the updated packages
from RHN to
put into the trees. mrepo is the only tool I'm vaguely aware
of that
allows grabbing such updates in a single location. It would
be nice
though if Red Hat just accommodated the need for this
directly.

Thanks,
John

_______________________________________________
rhn-users mailing list
rhn-usersredhat.com
htt
ps://www.redhat.com/mailman/listinfo/rhn-users

Can't you just update your install trees with the RPMs from
the latest RHEL CDs/ISOs? 

-----Original Message-----
From: rhn-users-bouncesredhat.com
[mailto:rhn-users-bouncesredhat.com]On Behalf Of
inode0
Sent: Saturday, February 10, 2007 10:08 AM
To: Discussions about Red Hat Network (rhn.redhat.com)
Subject: [rhn-users] Network Installations via RHN Proxy
Servers


While I know there is no official support for this, everyone
must do
it or arrange network installs from somewhere else. We
maintain
network install trees for RHEL3, RHEL4, FC5, and FC6
currently and I
am getting tired of doing an installation and then needing
to apply
hundreds of updates immediately after a fresh install.

It doesn't seem to me that it would be that difficult to
update the
installation trees as packages are updated so a fresh
install will be
current right after it finishes. I am quite capable of not
understanding why some things are problematic though. At
least that
would be a lot nicer for users who do interactive installs.

Can someone tell me what would need to be changed in these
trees? I'm
thinking some repodata mods would be required for the fedora
side and
perhaps something in the base directory on the RHEL side.
And then
there is the question of how to get the updated packages
from RHN to
put into the trees. mrepo is the only tool I'm vaguely aware
of that
allows grabbing such updates in a single location. It would
be nice
though if Red Hat just accommodated the need for this
directly.

Thanks,
John

_______________________________________________
rhn-users mailing list
rhn-usersredhat.com
htt
ps://www.redhat.com/mailman/listinfo/rhn-users
-----------------------------------------
This email transmission and any accompanying attachments
may
contain CSX privileged and confidential information intended
only
for the use of the intended addressee.  Any dissemination,
distribution, copying or action taken in reliance on the
contents
of this email by anyone other than the intended recipient
is
strictly prohibited.  If you have received this email in
error
please immediately delete it and  notify sender at the above
CSX
email address.  Sender and CSX accept no liability for any
damage
caused directly or indirectly by receipt of this email.

_______________________________________________
rhn-users mailing list
rhn-usersredhat.com
htt
ps://www.redhat.com/mailman/listinfo/rhn-users

On 2/10/07, Lamon, Frank III <Frank_LaMoncsx.com> wrote:
> Can't you just update your install trees with the RPMs
from the latest RHEL CDs/ISOs?

Our install trees use the latest ISO's. Red Hat only updates
those
when they bump the update level and in the meantime hundreds
of
packages on them become out of date.

John

_______________________________________________
rhn-users mailing list
rhn-usersredhat.com
htt
ps://www.redhat.com/mailman/listinfo/rhn-users

On Sat, 2007-02-10 at 09:08 -0600, inode0 wrote:
> While I know there is no official support for this,
everyone must do
> it or arrange network installs from somewhere else. We
maintain
> network install trees for RHEL3, RHEL4, FC5, and FC6
currently and I
> am getting tired of doing an installation and then
needing to apply
> hundreds of updates immediately after a fresh install.
> 
> It doesn't seem to me that it would be that difficult
to update the
> installation trees as packages are updated so a fresh
install will be
> current right after it finishes. 

It sounds like you're looking for a consolidated install
repository,
with updates already included, so you can avoid an update
cycle.

Getting updated packages might be easier once RHEL5 is
released, as
they're moving towards yum updates.

I'm not sure what you need beyond createrepo. The evolving
Koan
(Kickstart over a network) tool looks like an interesting
future
addition too.

Thanks,
Mike

_______________________________________________
rhn-users mailing list
rhn-usersredhat.com
htt
ps://www.redhat.com/mailman/listinfo/rhn-users

On 2/10/07, MJang <mikemommabears.com> wrote:
> On Sat, 2007-02-10 at 09:08 -0600, inode0 wrote:
> > While I know there is no official support for
this, everyone must do
> > it or arrange network installs from somewhere
else. We maintain
> > network install trees for RHEL3, RHEL4, FC5, and
FC6 currently and I
> > am getting tired of doing an installation and then
needing to apply
> > hundreds of updates immediately after a fresh
install.
> >
> > It doesn't seem to me that it would be that
difficult to update the
> > installation trees as packages are updated so a
fresh install will be
> > current right after it finishes.
>
> It sounds like you're looking for a consolidated
install repository,
> with updates already included, so you can avoid an
update cycle.

Exactly.

> Getting updated packages might be easier once RHEL5 is
released, as
> they're moving towards yum updates.

I can hope, but even with yum there is a problem getting
the
aggregation of updates onto one machine that is the
distribution point
for all network installations.

> I'm not sure what you need beyond createrepo. The
evolving Koan
> (Kickstart over a network) tool looks like an
interesting future
> addition too.

I'm not too concerned about our kickstart users now, they
can automate
the updates at the end and typically aren't sitting at the
box waiting
for the installation to complete. But to help our many newer
RHEL
users we provide a special installation ISO from which they
can
interactively select which version of the OS they want to
install from
a grub menu at boot time and the installation will proceed
over the
network eliminating the hassles associated with each user
obtaining a
pile of ISOs and correctly burning them and flipping them in
and out
during the install, etc. In these interactive cases, the
need to apply
hundreds of updates at the end of what they expect is the
installation
of a fresh OS is not only annoying to them but doesn't
really convey
the impression of a polished installation system.

It seems to me we should be able to do this better so after
the
anaconda install the user has an up to date installation of
the OS.

John

_______________________________________________
rhn-users mailing list
rhn-usersredhat.com
htt
ps://www.redhat.com/mailman/listinfo/rhn-users

On Sat, 2007-02-10 at 10:12 -0600, inode0 wrote:
> On 2/10/07, MJang <mikemommabears.com> wrote:
> > On Sat, 2007-02-10 at 09:08 -0600, inode0 wrote:
> > > While I know there is no official support for
this, everyone must do
> > > it or arrange network installs from somewhere
else. We maintain
> > > network install trees for RHEL3, RHEL4, FC5,
and FC6 currently and I
> > > am getting tired of doing an installation and
then needing to apply
> > > hundreds of updates immediately after a fresh
install.
> > >
> > > It doesn't seem to me that it would be that
difficult to update the
> > > installation trees as packages are updated so
a fresh install will be
> > > current right after it finishes.
> >
> > It sounds like you're looking for a consolidated
install repository,
> > with updates already included, so you can avoid an
update cycle.
> 
> Exactly.
> 
> > Getting updated packages might be easier once
RHEL5 is released, as
> > they're moving towards yum updates.
> 
> I can hope, but even with yum there is a problem
getting the
> aggregation of updates onto one machine that is the
distribution point
> for all network installations.

Right, now that I've had some coffee, there's also the
anaconda tools
that you need to update the installation programs and key
files such as
comps.xml (or whatever it is Red Hat is moving towards on
RHEL 5).
> 
> > I'm not sure what you need beyond createrepo. The
evolving Koan
> > (Kickstart over a network) tool looks like an
interesting future
> > addition too.
> 
> I'm not too concerned about our kickstart users now,
they can automate
> the updates at the end and typically aren't sitting at
the box waiting
> for the installation to complete. But to help our many
newer RHEL
> users we provide a special installation ISO from which
they can
> interactively select which version of the OS they want
to install from
> a grub menu at boot time and the installation will
proceed over the
> network eliminating the hassles associated with each
user obtaining a
> pile of ISOs and correctly burning them and flipping
them in and out
> during the install, etc. In these interactive cases,
the need to apply
> hundreds of updates at the end of what they expect is
the installation
> of a fresh OS is not only annoying to them but doesn't
really convey
> the impression of a polished installation system.

Getting the anaconda tools working with an install repo
infused with
updates would be trickier, almost like creating a custom
anaconda spin
with each update cycle. Otherwise, things don't look
"polished."
> 
> It seems to me we should be able to do this better so
after the
> anaconda install the user has an up to date
installation of the OS.

I don't know if they have more insight on the Anaconda list.
I know
there are lots of people there look to create their own
custom spins,
with varying degrees of success.

Thanks,
Mike

_______________________________________________
rhn-users mailing list
rhn-usersredhat.com
htt
ps://www.redhat.com/mailman/listinfo/rhn-users

On Sat, 10 Feb 2007, inode0 wrote:

> While I know there is no official support for this,
everyone must do
> it or arrange network installs from somewhere else. We
maintain
> network install trees for RHEL3, RHEL4, FC5, and FC6
currently and I
> am getting tired of doing an installation and then
needing to apply
> hundreds of updates immediately after a fresh install.
> 
> It doesn't seem to me that it would be that difficult
to update the
> installation trees as packages are updated so a fresh
install will be
> current right after it finishes. I am quite capable of
not
> understanding why some things are problematic though.
At least that
> would be a lot nicer for users who do interactive
installs.
> 
> Can someone tell me what would need to be changed in
these trees? I'm
> thinking some repodata mods would be required for the
fedora side and
> perhaps something in the base directory on the RHEL
side. And then
> there is the question of how to get the updated
packages from RHN to
> put into the trees. mrepo is the only tool I'm vaguely
aware of that
> allows grabbing such updates in a single location. It
would be nice
> though if Red Hat just accommodated the need for this
directly.

We've discussed doing this on the mailinglist (and I have
had some 
conversations with people that have this on their
wishlist).

One of the problems is the differences between
distributions, another is 
the fact that mrepo starts from ISO images (and as a result
are read-only 
mounted) to save disk space.

What I am interested to look at is using fuse/unionfs to
make the 
ISO-images modifiable and as a result rewrite the on-disc
metadata to 
accomodate kickstart installations.

For this mrepo needs an understanding of anaconda's metadata
and apply the 
correct methodology, unionfs integration and the metadata
re-generation 
functionality.

Usually mrepo development is driven by effort from users.
The best way to 
get new features in mrepo is looking into specifics, join
discussions and 
providing patches/information.

PS Starting with RHEL5 this is really no longer necessary as
RHEL5 allows 
to use normal yum repositories. The fact that Yum is now
moving to an 
sqlite metadata format will probably mean that for FC7/RHEL6
will again 
have a different methodology 

Kind regards,
--   dag wieers,  dagwieers.com,  http://dag.wieers.com/  
--
[all I want is a warm bed and a kind word and unlimited
power]

_______________________________________________
rhn-users mailing list
rhn-usersredhat.com
htt
ps://www.redhat.com/mailman/listinfo/rhn-users

On 2/11/07, Dag Wieers <dagwieers.com> wrote:
> We've discussed doing this on the mailinglist (and I
have had some
> conversations with people that have this on their
wishlist).
>
> One of the problems is the differences between
distributions, another is
> the fact that mrepo starts from ISO images (and as a
result are read-only
> mounted) to save disk space.
>
> What I am interested to look at is using fuse/unionfs
to make the
> ISO-images modifiable and as a result rewrite the
on-disc metadata to
> accomodate kickstart installations.

While this is interesting for mrepo, my focus now is more on
fixing up
the anaconda metadata so installs can proceed from on-disk
installation trees. That would be one step toward what mrepo
would
need at least.

So does anyone know of tools for doing this before I start
down the
"figure it out yourself" development branch?

> For this mrepo needs an understanding of anaconda's
metadata and apply the
> correct methodology, unionfs integration and the
metadata re-generation
> functionality.
>
> Usually mrepo development is driven by effort from
users. The best way to
> get new features in mrepo is looking into specifics,
join discussions and
> providing patches/information.
>
> PS Starting with RHEL5 this is really no longer
necessary as RHEL5 allows
> to use normal yum repositories. The fact that Yum is
now moving to an
> sqlite metadata format will probably mean that for
FC7/RHEL6 will again
> have a different methodology 

Can you help me understand how this makes it possible?
Presumably this
means that I could now be doing up to date installs of FC5
and FC6
rather than what I am doing (dropping the original ISOs into
an
installation tree and doing hundreds of package updates
after the
install completes).

Thanks,
John

_______________________________________________
rhn-users mailing list
rhn-usersredhat.com
htt
ps://www.redhat.com/mailman/listinfo/rhn-users

On Sun, 11 Feb 2007, inode0 wrote:

> On 2/11/07, Dag Wieers <dagwieers.com> wrote:
>
> > For this mrepo needs an understanding of
anaconda's metadata and apply the
> > correct methodology, unionfs integration and the
metadata re-generation
> > functionality.
> >
> > Usually mrepo development is driven by effort from
users. The best way to
> > get new features in mrepo is looking into
specifics, join discussions and
> > providing patches/information.
> >
> > PS Starting with RHEL5 this is really no longer
necessary as RHEL5 allows
> > to use normal yum repositories. The fact that Yum
is now moving to an
> > sqlite metadata format will probably mean that for
FC7/RHEL6 will again
> > have a different methodology 
> 
> Can you help me understand how this makes it possible?
Presumably this
> means that I could now be doing up to date installs of
FC5 and FC6
> rather than what I am doing (dropping the original ISOs
into an
> installation tree and doing hundreds of package updates
after the
> install completes).

For FC6 (and probably FC5) you can just point to the RPMS
directory that 
has repomd metadata. So both should already work with a
normal merged 
mrepo repository. (os+updates)

Kind regards,
--   dag wieers,  dagwieers.com,  http://dag.wieers.com/  
--
[all I want is a warm bed and a kind word and unlimited
power]

_______________________________________________
rhn-users mailing list
rhn-usersredhat.com
htt
ps://www.redhat.com/mailman/listinfo/rhn-users