Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Could not start Service[sssd]: #10

Closed
ndelic0 opened this issue Jan 12, 2016 · 10 comments
Closed

Could not start Service[sssd]: #10

ndelic0 opened this issue Jan 12, 2016 · 10 comments

Comments

@ndelic0
Copy link
Contributor

ndelic0 commented Jan 12, 2016

Testing your module on Centos 6. System does not get in convergent state in a single run. It seems that not all the changes have been applied on a sssd.conf during the first Puppet run. Services array is geting default values and not the values defined in a config hash.

(/Stage[main]/Sssd::Config/File[sssd_config_file]/content) -services = nss, pam, autofs
(/Stage[main]/Sssd::Config/File[sssd_config_file]/content) +services = nss,pam

@edestecd
Copy link
Collaborator

Hmm, I have several CentOS 6 nodes and have not experienced this. My config always goes in first and then starts the service, due this ordering in init.pp:

anchor { 'sssd::begin': } ->
class { '::sssd::install': } ->
class { '::sssd::config': } ~>
class { '::sssd::service': } ->
anchor { 'sssd::end': }

@edestecd
Copy link
Collaborator

Can you provide a sample of the code you are using to include the main class?
Are you using hiera / PE console / Foreman or simple node definitions?

@ndelic0
Copy link
Contributor Author

ndelic0 commented Jan 12, 2016

Service is not even started as the config file is not in place.
Jan 12 20:06:51 localhost sssd: SSSD couldn't load the configuration database [2]: No such file or directory.

domains key in sssd.conf is empty here(after the first run), some keys are empty too but most of the keys declared in the hash are getting populated.

@edestecd
Copy link
Collaborator

Your example looks pretty similar to mine, except this part:

'nss' => {
  'filter_users' => [ 'root','ldap','named','avahi','haldaemon','dbus','radiusd','news','nscd','apache','mysql' ]
},

Is that correct? should that block have some other options?

@edestecd
Copy link
Collaborator

Other than that I'm not sure... I may be able to spin up a test box later this eve and play around.
What is your puppet version? Are you using future parser?

@ndelic0
Copy link
Contributor Author

ndelic0 commented Jan 12, 2016

That's exactly what I need in this block. My only guessing that the problem is with the Ruby and the way it handles a list of hashes here?

@edestecd
Copy link
Collaborator

These are puppet hashes, so we should be shielded from the underlying ruby....
Except in the template. But that does not explain the service starting before the config goes in.

So if you run puppet a second time, it puts in your config and starts the sssd Daemon just fine?
Somehow that scenario rings a bell from when I first started using this module. But I thought it was fixed.
What version of the module are you using. Is it the latest, 0.2.1, from the forge?

@ndelic0
Copy link
Contributor Author

ndelic0 commented Jan 12, 2016

The thing is that the config file is created but missing some pieces from the hash, thus preventing the service to start. After 2nd run the file is in place and service starts regularly.
PE2015.2 - everything on default., sssd module version 0.2.1 from the forge.

@edestecd
Copy link
Collaborator

I don't have any PE in my environment :(
I think we need some acceptance tests that use beaker with a PE box.

@edestecd
Copy link
Collaborator

closed by pr #11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants