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

Verification of installation not good enough #113

Open
trocade opened this issue Apr 20, 2017 · 4 comments
Open

Verification of installation not good enough #113

trocade opened this issue Apr 20, 2017 · 4 comments

Comments

@trocade
Copy link

trocade commented Apr 20, 2017

If the file puppet_joined exists the module seems to skip any other sanity checks when installing.
This could cause the issue that the /etc/pam files are configured for vas, when vas is actually not really installed on the server.
This can be verified by doing the following steps:

  • Install vas using puppet
  • Remove the binaries and make sure puppet restores the pam files
  • Install vas using puppet again

Worst case you have a server where you can not even logon as root from console.

I would suggest that for the next release that it checks both for puppet_joined and do verify that the packages are installed before.

@anders-larsson
Copy link
Contributor

I agree with this issue regarding the method used to check whether a AD domain is joined or not. I believe this solution was select because a file on the file system is constant and never lies while tools such as vastool or other dynamic methods might give us incorrect results.

Do we have any suggestions on good ways of resolving this?

@Phil-Friderici FYI since we're working on a new release "soon".

@anders-larsson
Copy link
Contributor

#4 is also regarding this.

@Phil-Friderici
Copy link
Contributor

As far as I understood the fact $vas_domain will only have a value after VAS has joined the domain.
If we would check the value of $vas_domain before managing the files in /etc/pam that would need an additional puppet run. In the first run the fact $vas_domain is empty/undef so the module would only run the VAS installation. In the second rund $vas_domain should have the domain as value. This should be possible with the cost of an additional Puppet run.

On the other side the described issue reminds my of the the pet vs cattle theory [1]/[2].

I recommend to not fiddling around with system in the meaning of pets. With configuration management and/or in cloud-like environment systems should be treated as cattle.
If a cattle doesn't behave as expected it gets replaced. Only pets will see a doctor so to speak.

[1] http://cloudscaling.com/blog/cloud-computing/the-history-of-pets-vs-cattle/
[2] https://www.hava.io/blog/cattle-vs-pets-devops-explained

@anders-larsson
Copy link
Contributor

See #4 (comment) too on what propyless mentioned earlier. The problem with $vas_domain is that it is grabbed from the configuration file and does not actually represent whether the system is actually joined or not. Using this fact does not help us in the current state. We would need to be able to dynamically determine whether the system is AD joined or not for this to work. Not sure such vastool command exists and if we can trust it enough. What we really do not want is "re-join" loops.

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

3 participants