Who has tried to use salt-stack, at least minion - on AIX?

[Michael Felt]

I have packaged a newer python (v2.7.11, v3.4.4 and 3.5.1), and have a patch for python so that the client (minion) at least tries to start.

I have seen that there is a package from salt that installs, and runs - but is using a much older version of python (and so also misses my (pending) patch for ctypes/util (which is just plain broken on AIX). However, the numbering of salt for that fileset is 15.8.7.1 (while, via pip it is 15.8.7.0).

What is the better way to get the 15.8.7.1 release?

Michael

[Dave Neeley]

We have 2015.8 minion compiling from source on AIX 6.1. We install our own Python and all other dependencies, built with gcc. I believe it's python 2.7 with 0mq 3 because we couldn't get 0mq 4 to compile. This setup does not work on our AIX 7.1 boxes, probably a changed dependent package. We just downloaded all of the packages we needed and wrote our own rudimentary tarball based on steps that have already been published on github: https://github.com/kriberg/blaagposts/blob/master/setting-up-salt-dev-aix.md

There are several things that don't work in the minion, such as the service states, because AIX only has init.d/rc.d script support, no 'service' module. The minion runs, but of course there are fewer useful built-in grains and you resort to cmd.run alot to get things done.

Enterprise customers get access to an enterprise minion for AIX, or at least an enterprise bootstrap script for install. I don't know if the enterprise minion actually works better than the open-source one or not. We have forked the salt repo, hack around problems we find on aix, repackage, reinstall, etc. It's better than nothing!

[Dave Neeley]

I don't think salt is fully supported on Python 3 yet either, at least not in 2015.8. My info might be out of date though.

[Florian Ermisch]

Hi Dave,

writing `service` modules for AIX should be rather simple than.
Just look at the ones for FreeBSD and OpenBSD. The still
supported FreeBSD has no `/sbin/service` and OpenBSD just
recently got `rcctl`. And under the hood both still use init-scripts.

And everything you can do with a `cmd.run` shouldn't be too
hard to wrap in an execution module ;)

Regards, Florian

[Michael Felt]

Hi Dave,

Thanks for your extensive answer.

In my experiments I struggled to get salt-minion to even start because I had not unpacked everything to .so files - so I worked on a patch for AIX and python ctypes. Yesterday I came up with an idea that, hopefully, will work with "old" (using unpacked .so files) and new (getting .so files from an .a archive).

In short, the problem has been that ctypes module was originally developed for windows, and then adjusted for MacOS and GNU/Linux and Solaris - but AIX was, simply put, ignored. So, I hope my approach will find some of you who give it a try - and give me feedback on what is missing.

(Note: I know my python build is missing a few modules - e.g., tcl/tk - because it does not require it - and I am trying to keep the requirements to a minimum - salt does require libsodium (for raet) - so I did package that as well.

In short, if you are interested in giving my packaging a try (on AIX 5.3, AIX 6.1 and/or AIX 7.1 - check out: http://www.aixtools.net/index.php/salt, http://www.aixtools.net/index.php/python and http://www.aixtools.net/index.php/libsodium

[Dave Neeley]

Sweet. Good to know there's a base we can look at for the service module. IIRC it took some time to figure out how platform-specific module loading worked so we could understand the error message we were getting on aix.

[Michael Felt]

This is something I shall be working on soon - to get salt-minion (in
anycase) added to the AIX SRC subsystem.

There are some scripts "ready" for rc.d/init.d - that could just be
renamed appropriately (or symbolic linked) to /etc/rc.d/rc2.d with SXXX
for start and KXXX to stop.

[Michael Felt]

As you get error messages, re: whatever - please share, even if you do not have the solution (yet) - so we all know it may be a common issue and especially - how to solve.

e.g., I was getting nowhere with "salt-minion -l debug" even as a masterless minion. On the IRC channel someone gave me this command "salt-call local state.highstate" and that taught me a) I was missing some things (libsodium.a aka libsodium.so (as requested); c) that I needed to imporve my python ctypes patch to deal with an request of libXXX.so and change that to the correct string using libXXX.a

Still not working - but that is because minion is asking for GNU tools that AIX does not have.

root@x069:[/]salt-call local state.highstate
[WARNING ] The tools 'dmidecode', 'lspci' and 'dmesg' failed to execute because they do not exist on the system of the user running this instance or the user does not have the necessary permissions to execute them. Grains output might not be accurate.
'local' is not available.

FYI:
root@x069:[/]oslevel -s
7100-03-05-1524

root@x069:[/]rpm -qa
AIX-rpm-7.1.3.0-1
root@x069:[/]lslpp -L | grep aixtools
  aixtools.libsodium.rte     1.0.8.0    C     F    built 20-Mar-2016 2209 UTC
  aixtools.python.man.en_US
  aixtools.python.rte       2.7.11.2    C     F    built 21-Mar-2016 2334 UTC
  aixtools.python.salt.man.en_US
  aixtools.python.salt.rte  15.8.7.0    C     F    built 24-Feb-2016 1301 UTC

--
You received this message because you are subscribed to a topic in the Google Groups "Salt-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/salt-users/HEABNTWzEPg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave Neeley]

change this:

salt-call local state.highstate

to this:

'salt-call state.highstate --local'

'salt-call' automatically assumes the target is the local machine. '--local' just tells salt not to contact the salt master (ie run masterless).

[Michael Felt]

Thanks - got a bit more, but not much. Still have to discover the configurable parts.

Question: where are templates supposed to be, and please give me the name of a standard example that should be available.

See details below!

At another interested party (I am assisting, or who got me started), it is not happy with just raet - seems it also demands the second transport - at least that is how I read it.

So, question: how to tell salt to only use raet (or zmq, were it available)?

[ERROR   ] Future exception was never retrieved: Traceback (most recent call last):

  File "/opt/lib/python2.7/site-packages/tornado/gen.py", line 282, in wrapper

    yielded = next(result)

  File "/opt/lib/python2.7/site-packages/salt/minion.py", line 500, in eval_master

    pub_channel = salt.transport.client.AsyncPubChannel.factory(self.opts, **factory_kwargs)

  File "/opt/lib/python2.7/site-packages/salt/transport/client.py", line 153, in factory

    import salt.transport.zeromq

  File "/opt/lib/python2.7/site-packages/salt/transport/zeromq.py", line 24, in <module>

    import salt.transport.mixins.auth

  File "/opt/lib/python2.7/site-packages/salt/transport/mixins/auth.py", line 16, in <module>

    import salt.master

  File "/opt/lib/python2.7/site-packages/salt/master.py", line 21, in <module>
    import zmq

ImportError: No module named zmq

[ERROR   ] An un-handled exception was caught by salt's global exception handler:

NameError: global name 'zmq' is not defined
Traceback (most recent call last):

  File "/opt/bin/salt-call", line 11, in <module> salt_call()

  File "/opt/lib/python2.7/site-packages/salt/scripts.py", line 335, in salt_call client.run()

  File "/opt/lib/python2.7/site-packages/salt/cli/call.py", line 43, in run caller = salt.cli.caller.Caller.factory(self.config)

  File "/opt/lib/python2.7/site-packages/salt/cli/caller.py", line 78, in factory return ZeroMQCaller(opts, **kwargs)

  File "/opt/lib/python2.7/site-packages/salt/cli/caller.py", line 269, in __init__ super(ZeroMQCaller, self).__init__(opts)

  File "/opt/lib/python2.7/site-packages/salt/cli/caller.py", line 101, in __init__ self.minion = salt.minion.SMinion(opts)

root@x069:[/]salt-call state.highstate --local

[WARNING ] The tools 'dmidecode', 'lspci' and 'dmesg' failed to execute because they do not exist on the system of the user running this instance or the user does not have the necessary permissions to execute them. Grains output might not be accurate.

[INFO    ] Loading fresh modules for state activity
[ERROR   ] Template was specified incorrectly: False
[ERROR   ] No contents found in top file
local:
----------
          ID: states
    Function: no.None
      Result: False
     Comment: No Top file or external nodes data matches found.
     Started:
    Duration:
     Changes:  

Summary for local
------------
Succeeded: 0
Failed:    1
------------
Total states run:     1

[Dave Neeley]

If you have a salt master, then the canonical templates location is /srv/salt/ on the master (configured via /etc/salt/master), and setup is explained in the tutorial below.  I believe the files from the master would get used if you did 'salt-call state.highstate' (without --local). When you use --local with salt-call, that uses the default file_roots location on the minion (configured via /etc/salt/minion on the minion). /etc/salt is also where you would configure RAET or 0MQ. Those are called transport layers in salt parlance.

The first tutorial from salt is here: https://docs.saltstack.com/en/latest/topics/tutorials/states_pt1.html. The canonical example is to install an apache webserver. https://gist.github.com/daveneeley/66c4a61e44e45a695363 shows a state for installing that on AIX with your tools. Those files would both go in /srv/salt on the master, or if you are using salt-call with --local, on the minion. 

The test module (https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.test.html) is also very helpful. 'salt-call test.versions_report --local' should you know the state of the possible python libraries that salt can use.

[Dave Neeley]

RAET documentation: https://docs.saltstack.com/en/latest/topics/transports/raet/index.html

[Michael Felt]

Thank you again Dave - homework for when I get off-site. Cannot get to my servers atm.

Futher - more for the google admins - which surprises me. At a customer site I am running into this - short - looks as iff google groups is using an expired (self-signed) certificate. Unfortunately, FF no longer lets me view the certificate, what I can report is:

This Connection is Untrusted

You have asked Firefox to connect securely to groups.google.com, but we can't confirm that your connection is secure.

Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.
What Should I Do?

If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.

This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox only connect to it securely. As a result, it is not possible to add an exception for this certificate.

groups.google.com uses an invalid security certificate.

The certificate is not trusted because it is self-signed.
The certificate is only valid for portal
The certificate expired on 26-Sep-14 16:33. The current time is 23-Mar-16 16:00.

(Error code: sec_error_unknown_issuer)
 (So, the implied Q - perhaps better in a new thread is: anyone else seeing this when approaching via: https://groups.google.com/forum/#!forum/salt-users

And, Dave - thanks again! :)

--

[C. R. Oldham]

On Wed, Mar 23, 2016 at 10:07 AM, Michael Felt <aixt...@gmail.com> wrote:

(Error code: sec_error_unknown_issuer)
 (So, the implied Q - perhaps better in a new thread is: anyone else seeing this when approaching via: https://groups.google.com/forum/#!forum/salt-users

I'm guessing you have some kind of MITM activity going on, either maliciously or via an intrusive firewall.   I see this when I check the cert at groups.google.com with Firefox:

--

--cro

C. R. Oldham, Platform Engineer, SaltStack

c...@saltstack.com / 801-564-4673

[Michael Felt]

Many thanks for showing the certificate. I suspect the client has some sort of proxy that is "in the way". I considered it unlikely, but did not wish to assume, re: the certificate.
Fortunately I could also verify contents via what I received as email.

[Michael Felt]

Thanks - got a bit more, but not much. Still have to discover the configurable parts.

See details below!

At another interested party (I am assisting, or who got me started), it is not happy with just raet - seems it also demands the second transport - at least that is how I read it.

[ERROR   ] Future exception was never retrieved: Traceback (most recent call last):

  File "/opt/lib/python2.7/site-packages/tornado/gen.py", line 282, in wrapper

    yielded = next(result)

  File "/opt/lib/python2.7/site-packages/salt/minion.py", line 500, in eval_master

    pub_channel = salt.transport.client.AsyncPubChannel.factory(self.opts, **factory_kwargs)

  File "/opt/lib/python2.7/site-packages/salt/transport/client.py", line 153, in factory

    import salt.transport.zeromq

  File "/opt/lib/python2.7/site-packages/salt/transport/zeromq.py", line 24, in <module>

    import salt.transport.mixins.auth

  File "/opt/lib/python2.7/site-packages/salt/transport/mixins/auth.py", line 16, in <module>

    import salt.master

  File "/opt/lib/python2.7/site-packages/salt/master.py", line 21, in <module>
    import zmq

ImportError: No module named zmq

[ERROR   ] An un-handled exception was caught by salt's global exception handler:

NameError: global name 'zmq' is not defined
Traceback (most recent call last):

  File "/opt/bin/salt-call", line 11, in <module> salt_call()

  File "/opt/lib/python2.7/site-packages/salt/scripts.py", line 335, in salt_call client.run()

  File "/opt/lib/python2.7/site-packages/salt/cli/call.py", line 43, in run caller = salt.cli.caller.Caller.factory(self.config)

  File "/opt/lib/python2.7/site-packages/salt/cli/caller.py", line 78, in factory return ZeroMQCaller(opts, **kwargs)

  File "/opt/lib/python2.7/site-packages/salt/cli/caller.py", line 269, in __init__ super(ZeroMQCaller, self).__init__(opts)

  File "/opt/lib/python2.7/site-packages/salt/cli/caller.py", line 101, in __init__ self.minion = salt.minion.SMinion(opts)

root@x069:[/]salt-call state.highstate --local

[WARNING ] The tools 'dmidecode', 'lspci' and 'dmesg' failed to execute because they do not exist on the system of the user running this instance or the user does not have the necessary permissions to execute them. Grains output might not be accurate.

[INFO    ] Loading fresh modules for state activity
[ERROR   ] Template was specified incorrectly: False
[ERROR   ] No contents found in top file
local:
----------
          ID: states
    Function: no.None
      Result: False
     Comment: No Top file or external nodes data matches found.
     Started:
    Duration:
     Changes:  

Summary for local
------------
Succeeded: 0
Failed:    1
------------
Total states run:     1

On 22-Mar-16 13:54, Dave Neeley wrote:

change this:

salt-call local state.highstate

to this:

'salt-call state.highstate --local'

'salt-call' automatically assumes the target is the local machine. '--local' just tells salt not to contact the salt master (ie run masterless).

(p.s., maybe this was sent long ago, (also been stick in gmail drafts list)