Hi @all,
is it possible to use defines with Foreman when acting as ENC? I would like
to use https://github.com/unbc/puppet-sssd which is configured with a
define but I only see the possibility to use classes inside Foreman for
configuration. Any hints or tips?
Regards Thomas
Seems like to use this module, you'll need to make a wrapper class to
include for hosts where ever might be appropriate…
class myauth {
class { 'sssd':
domains => [ 'mydomain.local' ],
}
sssd::domain { 'mydomain.local':
ldap_uri => 'ldap://mydomain.local',
ldap_search_base => 'DC=mydomain,DC=local',
krb5_realm => 'MYDOMAIN.LOCAL',
ldap_default_bind_dn => 'CN=SssdService,DC=mydomain,DC=local',
ldap_default_authtok => 'My ultra-secret password',
simple_allow_groups => ['SssdAdmins'],
make_home_dir => true,
}
}
You could also sub-class the myauth class around some
environment/domain/hostgroup structure. I've done this in a couple of
modules and either use Foreman/Puppet parameters or set parameters at the
appropriate container in Foreman (e.g. domain, hostgroup, etc.)
Or am I missing your point?
AFAIK puppet doesn't support definition in ENC output
see doc there :
http://docs.puppetlabs.com/guides/external_nodes.html#enc-output-format
You need to include in Foreman a class which define your ressource as you
want.
You may consider to transform the definition into a parameterized class if
this is relevent (a
parameterized class can only be instanciated once)
Regards,
Hi @all,
is it possible to use defines with Foreman when acting as ENC? I would
like to use https://github.com/unbc/puppet-sssd which is configured with
a define but I only see the possibility to use classes inside Foreman for
configuration. Any hints or tips?Regards Thomas
Linux … enjoy the ride!
–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.
Thanks for the answers, I have a common wrapper class in my module
repository, will use this one together with parameters to work around the
problem.
Regards Thomas
Seems like to use this module, you’ll need to make a wrapper class to
include for hosts where ever might be appropriate…class myauth {
class { ‘sssd’:
domains => [ ‘mydomain.local’ ],
}
sssd::domain { ‘mydomain.local’:
ldap_uri => ‘ldap://mydomain.local’,
ldap_search_base => ‘DC=mydomain,DC=local’,
krb5_realm => ‘MYDOMAIN.LOCAL’,
ldap_default_bind_dn => ‘CN=SssdService,DC=mydomain,DC=local’,
ldap_default_authtok => ‘My ultra-secret password’,
simple_allow_groups => [‘SssdAdmins’],
make_home_dir => true,
}
}You could also sub-class the myauth class around some
environment/domain/hostgroup structure. I’ve done this in a couple of
modules and either use Foreman/Puppet parameters or set parameters at the
appropriate container in Foreman (e.g. domain, hostgroup, etc.)Or am I missing your point?
On Monday, August 19, 2013 9:34:32 AM UTC-4, thbe wrote:
Hi @all,
is it possible to use defines with Foreman when acting as ENC? I would
like to use https://github.com/unbc/**puppet-sssdhttps://github.com/unbc/puppet-sssd which
is configured with a define but I only see the possibility to use classes
inside Foreman for configuration. Any hints or tips?Regards Thomas
Linux … enjoy the ride!
–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.
–
performance, security, automation, SAP
cimt consulting ag, Burchardstrasse 17, 20095 Hamburg
fon: +49 (163) 6081 302, fax: +49 (40) 5 33 02-22, web: www.cimt.de
key: FED7C867 at wwwkeys.de.pgp.net
Sitz der Gesellschaft: Hamburg, Amtsgericht Hamburg, HRB 74173
Vorstand: Christoph Friedlaender, Dr.-Ing. Thorsten Kuhlmann
Vorsitzender des Aufsichtsrats: Christian Gottsmann
Hi,
Sorry for resurrecting an ancient thread, but this exactly addresses the
problem I have. Unfortunately I don't understand the answer.
I am trying to use the same sssd module and cannot see how to set anything
in sssd::domain. I would have thought these values should be defined in my
ENC, which in my case is Satellite 6.
Sean's response seems to exactly address the issue I have, but I don't
understand the reply (puppet being one of the mainly learning curves I am
currently tackling). Does it mean that I should amend the sssd module to
contain a class definition like myauth as in his example? I tried that and
when I published it through sat6 I could see 'myauth' as a class available
to the node I am testing on. After associating that class with the node
using the WebUI and initiating a puppet run I get this error though:
Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find class myauth for serverx.local on node serverx.local
Even if I could get around that then I can see that I have effectively
hard-coded the config in the module, which seems counter productive. So
the comment 'You could also sub-class the myauth class around some
environment/domain/hostgroup structure' sounds like exactly what I want to
do, but I don't know how to 'sub-class myauth'.
Apologies if this all seems obvious - hopefully one day it will to me too,
but right now it doesn't! :O)
Regards,
David
Hi David,
To answer your question about modifying the sssd module. That's not what I
was referring to, in our environment here, I have several modules that I've
written and deployed into the puppet environments. In the example case
above, your puppet environment would need at least (not sure of the
dependencies for puppet-sssd) to have the myauth module and the sssd module.
For example:
[user@host:/etc]$ tree puppet
puppet
└── environments
└── production
└── modules
├── myauth
│ └── manifests
│ └── init.pp
└── sssd
├── LICENSE
├── manifests
│ ├── domain.pp
│ ├── homedir.pp
│ ├── init.pp
│ └── params.pp
├── Modulefile
├── README.markdown
└── templates
├── domain.conf.erb
└── header_sssd.conf.erb
And the myauth class code I made above would live in
environments/production/modules/myauth/manifests/init.pp
Hope that helps.
Hi David,
guess you mean my answer. I've created a class called local_wrapper where I
put all things in that need "special" handling. In this case I have a class
local_wrapper::sssd which include sssd and call the define. The
local_wrapper class has paramters which I can pass to the sssd define.
Regards Thomas
Hi,
Sorry for resurrecting an ancient thread, but this exactly addresses the
problem I have. Unfortunately I don’t understand the answer.I am trying to use the same sssd module and cannot see how to set anything
in sssd::domain. I would have thought these values should be defined in my
ENC, which in my case is Satellite 6.Sean’s response seems to exactly address the issue I have, but I don’t
understand the reply (puppet being one of the mainly learning curves I am
currently tackling). Does it mean that I should amend the sssd module to
contain a class definition like myauth as in his example? I tried that and
when I published it through sat6 I could see ‘myauth’ as a class available
to the node I am testing on. After associating that class with the node
using the WebUI and initiating a puppet run I get this error though:Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find class myauth for serverx.local on node serverx.localEven if I could get around that then I can see that I have effectively
hard-coded the config in the module, which seems counter productive. So
the comment ‘You could also sub-class the myauth class around some
environment/domain/hostgroup structure’ sounds like exactly what I want to
do, but I don’t know how to ‘sub-class myauth’.Apologies if this all seems obvious - hopefully one day it will to me too,
but right now it doesn’t! :O)Regards,
DavidOn Monday, 19 August 2013 15:52:58 UTC+1, Sean Alderman wrote:
Seems like to use this module, you’ll need to make a wrapper class to
include for hosts where ever might be appropriate…class myauth {
class { ‘sssd’:
domains => [ ‘mydomain.local’ ],
}
sssd::domain { ‘mydomain.local’:
ldap_uri => ‘ldap://mydomain.local’,
ldap_search_base => ‘DC=mydomain,DC=local’,
krb5_realm => ‘MYDOMAIN.LOCAL’,
ldap_default_bind_dn => ‘CN=SssdService,DC=mydomain,DC=local’,
ldap_default_authtok => ‘My ultra-secret password’,
simple_allow_groups => [‘SssdAdmins’],
make_home_dir => true,
}
}You could also sub-class the myauth class around some
environment/domain/hostgroup structure. I’ve done this in a couple of
modules and either use Foreman/Puppet parameters or set parameters at the
appropriate container in Foreman (e.g. domain, hostgroup, etc.)Or am I missing your point?
On Monday, August 19, 2013 9:34:32 AM UTC-4, thbe wrote:
Hi @all,
is it possible to use defines with Foreman when acting as ENC? I would
like to use https://github.com/unbc/puppet-sssd which is configured
with a define but I only see the possibility to use classes inside Foreman
for configuration. Any hints or tips?Regards Thomas
Linux … enjoy the ride!
–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
–
performance, security, automation, SAP
cimt consulting ag, Burchardstrasse 17, 20095 Hamburg
fon: +49 (163) 6081 302, fax: +49 (40) 5 33 02-22, web: www.cimt.de
key: FED7C867 at pgp.mit.edu
Sitz der Gesellschaft: Hamburg, Amtsgericht Hamburg, HRB 74173
Vorstand: Christoph Friedlaender, Dr.-Ing. Thorsten Kuhlmann
Vorsitzender des Aufsichtsrats: Christian Gottsmann
Hi,
Thanks to both of you for the fast and helpful responses!
Sean's tree structure helped particularly and using that as a guide I now
have a working sssd config. I'm glad I asked too as I think this helps me
understand how to write better puppet modules. I also think I can see how
to develop the myauth and sssd modules to meet future requirements.
Thanks again for your help.
Regards,
David