Re: [Radmind-devel] client config

[Andrew M. <adm...@um...>]

On Oct 26, 2005, at 8:44 AM, Adam Reed wrote:

> I appreciate the client config idea (I've written my own to a  
> degree) but I see a problem that I just don't think the proposed  
> solution solves which makes it redundant in my mind.
>
> To receive any form of client config you need to be able to  
> successfully connect to a radmind server. What happens if I need to  
> make a change to the server. I can't say require the use of two way  
> certificates as while I could enable it in the config, and on the  
> server, my clients can no longer connect to receive the  
> instructions. (Certificates aren't the best example but its all I  
> can think of at the moment). This is most likely an admin error but  
> I don't think that should exclude it from being seen as a problem  
> with any client config implementation.

Isn't this already a configuration problem? It must be, if you've  
been forced to throw a webserver into the mix.

> What I am many others do is make a call to a separate web server  
> first.

Sure, but then you need to have given the client a configuration so  
it knows what webserver to contact. And what happens if that server  
needs to be replaced, or to have its name changed? This doesn't seem  
like a solution to the problem here, rather a displacement of it.  
Your solution, as I read it, is partially a way to use the MAC  
address to determine access to your radmind server, but it's also a  
more general management tool for user experience. That's beyond the  
scope of a radmind client configuration file.

For the problem you pose here I think the simple solution is one of  
server, not client, configuration. You must first make sure that your  
server will allow the given client access to the server. You must  
then let the client know somehow where it should connect for the  
first time. Depending on your setup, subsequent runs will be able to  
rely on scripts to get this information, but bootstrapping is always  
complicated, whether it involves netbooting, manual configuration, or  
installing automation scripts. The default radmind server can be  
compiled into the tools, which would get around needing a  
configuration file at all, but then you need to get those tools on to  
the clients. Hey, you can do that with scp! But then you need to have  
ssh enabled on all the clients. At some point, you have to provide  
the machine with the settings it needs.

The client configuration I propose helps mitigate the first run  
problem to some degree. Because the configuration ktcheck pulls down  
will be available to all client tools immediately after it has been  
retrieved, you don't have to wait until the first full radmind update  
is complete before the tools can use current settings.

> My work flow is that I pass the machines ethernet address and  
> receive a plist back which among other things contains the radmind  
> server to use, as well as what checksum (if any) and any other  
> settings I like (not only for radmind but the machine as a whole).  
> This isn't the best solution but it adds a layer of abstraction  
> that gives me more flexibility in managing how my machines interact  
> with radmind.

The client configuration certainly wouldn't take that from you. If  
the server has no client configuration to offer, the client won't get  
one, and old solutions will continue to work.

> The problem I see is that the usefulness of radmind being able to  
> self configure is only useful in situations where the configuration  
> is already mostly known, limiting the scope of the usefulness of  
> global configuration.

This I think is a more general problem for large-scale management  
than it is a problem limited to radmind alone.

andrew