Page MenuHomePhabricator

run-puppet-agent --enable flag is broken
Closed, ResolvedPublic

Description

❌cdanis@cp3060.esams.wmnet ~ 🕞🍵 sudo run-puppet-agent --enable 'cdanis deploying I558346d T272330'
Notice: Skipping run of Puppet configuration client; administratively disabled (Reason: 'cdanis deploying I558346d T272330');
Use 'puppet agent --enable' to re-enable.

For now I just did --force instead of specifying the message

Event Timeline

There's one related problem, which is that enable-puppet should check the given message both with and without appending - $SUDO_USER, as perhaps you set a disable-puppet from a context where that wasn't present, for example https://sal.toolforge.org/log/8BlxIXcBgTbpqNOm5XlV

There's one related problem, which is that enable-puppet should check the given message both with and without appending - $SUDO_USER, as perhaps you set a disable-puppet from a context where that wasn't present, for example https://sal.toolforge.org/log/8BlxIXcBgTbpqNOm5XlV

Actually, I think that is quite possibly the whole problem.

Change 657889 had a related patch set uploaded (by Jbond; owner: John Bond):
[operations/puppet@production] enable-puppet: allow fall back to enable puppet disabled by root

https://gerrit.wikimedia.org/r/657889

i sent a quick patch for this. in an ideal world it would be good to make it so only cumin* can disable puppet as root and when it dose so it also appends the user string (similar as if called by sudo). however i haven't thought of a practical way to enforce that. I guess the first thing would be to see if we an get cumin to populate some environment variable that scripts can reference.

*im making an assumption that you disabled puppet via cumin and then tried to re-enable it on an individual host?

i sent a quick patch for this. in an ideal world it would be good to make it so only cumin* can disable puppet as root and when it dose so it also appends the user string (similar as if called by sudo). however i haven't thought of a practical way to enforce that. I guess the first thing would be to see if we an get cumin to populate some environment variable that scripts can reference.

we might be able to set an envionment variable on the cumin host e.g. CUMIN_USER and update ssh_config to include SendEnv CUMIN_USER and then; as the clustershell transport calls the ssh binary it should work (although this will depend on sudo vs sudo -i)

of course this variable should not be trusted for any authorization uses but can be use full for simple logging

Legoktm triaged this task as High priority.

Change 657889 merged by Jbond:
[operations/puppet@production] enable-puppet: allow fall back to enable puppet disabled by root

https://gerrit.wikimedia.org/r/657889

Seems to be working

$ sudo disable-puppet 'test disable puppet with sudo'                                                               
$ sudo puppet agent -t                                                                                      
Notice: Skipping run of Puppet configuration client; administratively disabled (Reason: 'test disable puppet with sudo - jbond');
Use 'puppet agent --enable' to re-enable.
$ sudo enable-puppet 'test disable puppet with sudo'                                                                              
$ sudo su -                                                                                                                
$ disable-puppet 'test puppet disable as root'
$ puppet agent -t
Notice: Skipping run of Puppet configuration client; administratively disabled (Reason: 'test puppet disable as root');
Use 'puppet agent --enable' to re-enable.
$ enable-puppet 'test puppet disable as root'
$ disable-puppet 'test puppet disable as root (unlock with sudo)'
$ logout
$ sudo enable-puppet 'test puppet disable as root (unlock with sudo)'                                   
$ sudo puppet agent -t 
Info: Using configured environment 'production'
...