On 03/29/2013 03:00 PM, jcbollinger wrote:
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.
definitely the first case. LDAP is authoritative for the network
configuration.
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.
this is very temting to implement, and i think this will be the road i
will take.
Somehow, I will have to provide proper providers and types also.
(based on http://forge.puppetlabs.com/adrien/network
<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
thanks for your input. The code will follow :)
Greets
Johan
.
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.
--
Johan De Wit
Open Source Consultant
Red Hat Certified Engineer (805008667232363)
Puppet Certified Professional 2013 (PCP0000006)
_________________________________________________________
Open-Future Phone +32 (0)2/255 70 70
Zavelstraat 72 Fax +32 (0)2/255 70 71
3071 KORTENBERG Mobile +32 (0)474/42 40 73
BELGIUM http://www.open-future.be
_________________________________________________________
--
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.
