Salt: How salt cmd.run Works with OS ENV?

[Colstuwjx]

As I see in the source-code, salt cmd.run seems using python subprocess to run a shell cmd, but I strangely find that:

salt 'test' cmd.run 'service zabbix-agent restart;'   \# it works but LC_ALL=C, it use different delimtor etc.
salt 'test' service.restart zabbix-agent  \# it works but LC_ALL unset

How to set os env var in salt cmd.run?
help~~~

[basepi]

I want to say there's a point in salt where we force the LC_ALL to C because salt expects English from the commands it runs. We'll do some checking and get back to you.

[basepi]

Ah, yes, it's in the cmd module functions. Basically unless you pass in LC_ALL yourself using the env argument, or unless you pass in reset_system_local=False, it will set it to C to force to English wherever possible.

[umeboshi2]

@basepi , the point where that seems to have happened was to fix bug #3261. This was a problem in disk.usage, which calls cmd.run. Forcing LC_ALL=C should be done in disk.usage, instead of cmd.run. This is deeply hidden and unexpected behavior when wondering why a package install state hasn't run correctly. There is also nothing in the docs that explains what reset_system_locale actually does.

[basepi]

Hrm, you may be right. However, that flag has been that way for 2 years. I'm afraid if we just flip that switch other regressions will pop up. =\

[umeboshi2]

I so much agree with you! That is the point I was trying to make on the other issue. I would link, but having touchpad difficulties now. This is more of a policy bug instead of code bug, and will require planning and a milestone type goal. Link!

I firmly feel that this is necessary. This is one of the stranger bugs that will only appear infrequently and probably would have gone unnoticed, except for the fact that I want to be placing common tables (such as users and passwords) in template1, instead of depending on template0). That was what caused me to notice this. soundtech already provided me a link to a good workaround for that, but that is really just a temporary fix.

Please take a bit of time to read through my comments on the other bug report. Please take a look at how locales are set in the different distributions. What you will find is that the locale is _always_ determined by the environment. The fact that there may be a locale or locales defined in a file in /etc is merely a distro specific manner by which to either set the environment, or to build man pages, etc. for the locales supported on the system.

The system locale can never be determined reliably for an arbitrary distrubution!!!!

The only locale that can ever be inferred correctly is through the environment, and this is a consequence of the POSIX spec.

This is somewhat similar to the problem with PAM and an underprivileged user needing access to /etc/shadow. The system is already there with its requirements, and it is really up to us to understand this and work with or around this as necessary, or to be subject to difficult to fix problems later.

I'm taking a long time to try and explain this because it took me quite a bit a time to find the true source of this problem, then go back through the gitlog to determine how this happened and why. If I had to go back through this and determine why my system was acting unpredictably, somebody smarter and more capable than me will probably do the same thing. I am taking this time to explain this because I really like the project and how it has been moving compared to the alternatives that are available. (I am good friends with a lead developer of a competing project that couldn't get me to join up because I really need the zeromq transport and mswindows minion support). I want to be using salt in the future and be very proud of my decision to do this.

On a side note, it seems that excepting a few debian developers, that there are a lot of them who are resistant to using salt due to the manner by which the encryption system is working. For my purposes, as long as there is no need to for a minion and master to ever communicate beyond a local network, I am not really worried about potential attacks. However, I found something today that really piqued my interest. It seems that zeromq now has kerberos/gssapi support now., This means that the minions and master can be on a REALM that may be more secure than the default implementation. It seems pretty interesting.

[larsen0815]

I was bitten by this unexpected behavior when I called Puppet via cmd.run as the used locale caused a bug in Puppet whereby in turn all of my managed crontabs got corrupted (entries not managed by Puppet were removed; had to restore from backup; caused by a German umlaut in only one of those crontabs).

Workaround would be to use reset_system_locale=false or env='{LC_ALL: en_US.UTF-8"}' as a param to the cmd.run call.

Same problem can be seen here:

# salt 'example.com' cmd.run 'puppet agent --test --noop'
example.com:
(snip)
    Error: Puppet::Util::FileType::FileTypeCrontab could not read nobody: invalid byte sequence in US-ASCII
    Error: Could not prefetch cron provider 'crontab': Puppet::Util::FileType::FileTypeCrontab could not read nobody: invalid byte sequence in US-ASCII
(snip)

This ought to show a problem like the puppet-run before, but it doesn't:

# salt 'example.com' puppet.noop
example.com:
    ----------
    pid:
        29651
    retcode:
        0
    stderr:

    stdout:

The expected error:

# salt 'example.com' puppet.run
example.com:
    ----------
    pid:
        29736
    retcode:
        0
    stderr:
        Error: Puppet::Util::FileType::FileTypeCrontab could not read nobody: invalid byte sequence in US-ASCII
        Error: Could not prefetch cron provider 'crontab': Puppet::Util::FileType::FileTypeCrontab could not read nobody: invalid byte sequence in US-ASCII

Debian Jessie with Salt 2014.1.13 and Puppet 3.7.2-4

[dahrens]

This behaviour is really unexpected and time consuming to debug. Would be so nice if cmd.run respects locale settings of the minion or at least uses en_US.UTF-8 instead of C to ensure english.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.