[et-mgmt-tools] Cobbler/Koan restrictions with AS/CentOS

Michael DeHaan mdehaan at redhat.com
Wed Jun 25 16:18:42 UTC 2008


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 at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>   




More information about the et-mgmt-tools mailing list