Harry Hoffman wrote:
Hi All,
We've got cobbler/koan setup to dole out installations of both RHAS5.x
and CentOS5.x (and soon possibly Fedora to students).
The way it stands now we include legitimate keys in our kickstart files
and associated the kickstarts with a profile (i.e.
RHAS-5.1-x86_64-webserver).
This works fine and everyone who deserves to get a entitlement gets one.
Upon reboot (and connection to a publicly routed network) they update
their systems automagically.
We want to branch out and allow others to use the install server but
obviously we don't want them to install AS and get a valid entitlement
when they haven't purchased one.
Since we can't mask out certain profiles/kickstarts from the install
server I'm looking for advice and how to do this in a "non-hackish"
manner.
I'd prefer to only have the one cobbler server but the more I think
about it the less likely that seems to be. I'm guessing we'd need one
"free" cobbler server and one "you paid for it" cobbler server.
I suggested Harry ask this here as there are a lot of academic install
bases that may have similar questions (wanting to provide
installs for certain labs/machines different from other
labs/machines/dorms? Now that I think about it, offering free PXE
to Fedora on every network might be amusing -- especially if you also do
Windows tech support).
I think the best possible answer is to play some fun network games to
make each set of servers
get the "right" cobbler server.
As ultimately if you have a machine on your network that can get at the
install tree, it can still
run rhn_regks against RHN and Satellite to consume your entitlement that
you didn't want it
to consume.
You could also probably just play some other (simpler?) network games to
make sure it can't contact
RHN and keep using the same server, but that doesn't solve the problem
of them picking the wrong
install option.
It is possible to configure PXE menus and such to require passwords for
certain options, though
that doesn't cover --replace-self.
I think I like the 2 server approach best.
Anyone else have ideas?
--Michael
Any thoughts?
Cheers,
Harry
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
