On Thursday, March 28, 2013 9:03:31 AM UTC-5, Johan De Wit wrote: > > On 03/28/2013 02:20 PM, jcbollinger wrote: > > > > On Thursday, March 28, 2013 5:32:06 AM UTC-5, Johan De Wit wrote: >> >> Hi, >> >> I'm in the progress of writing custom facts to retrieve our network >> configuration for the nodes from the openldap ENC. >> >> > I'm confused. An ENC is a service for the master's use, so nodes should > have nothing to do with it. You can, of course, use the same LDAP server > to back an ENC as well as client LDAP services, but for those different > uses you should neither need nor want to access the same data. > > In this case, the problem we have is with the network configuration. > This is configured in ldap, and used both by puppet (using a n external > script) and cobbler. Last one retrieves all interfaces and mac-addresses, > and uses this in the autoyast file to populate the udev rules correctly. > >
Ok, this is a bit clearer to me now. I think what you're saying is that other than the custom facts you are working on, the nodes rely directly on LDAP only for their cobbler-managed initial provisioning. If that's the case then it tells me that the LDAP data do not, in fact, belong to the nodes, but rather to the site generally. With that being the case, it does not make much sense to me for the nodes to play an intermediary role in providing that data to the master, unless possibly there is an insurmountable barrier to the master retrieving the data directly. There is a separate question however: are you trying to find the parameters the nodes *should* have (for which LDAP is authoritative) or the parameters the nodes actually *do* have (which can be provided only by the nodes). If the latter, then the nodes would not be acting as intermediaries when they provided the data to the master, as they would need to get it by self-inspection, not LDAP. > >> Now, since the puppetmaster has also access to the ldap server, I'm >> thinking to move the custom facts to a function, so it runs on the >> puppetmaster only, end not on every node. >> >> [...] > > I think you gave me a third option in getting this data available : > > 1 - custom facts > 2 - functions > 3 - patching the ldap enc, to retrieve the complete subtree > > ha, maybe a forth ? > > 4 - Hiera custom ldap backend ? > I think an LDAP back end for hiera might fit very nicely into your picture. I doubt it would be much harder to create than the custom facts or custom function(s) you are already contemplating, and it would provide great abstraction and flexibility. > > Somehow, I will have to provide proper providers and types also. (based > on http://forge.puppetlabs.com/adrien/network as an example) > > This is a very specific setup, that maybe could have been implemented on a > better way, but for now we have to live with it. > > Since the objective seems to be for the master to instruct agents how to configure the correct network parameters on each node, I'd say that the data flow LDAP -> master -> agent makes far more sense than LDAP -> agent -> master -> agent . Best, John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
