Installing a Salt Minion on a 9627?

[Alejandro_del_Castillo]

The script I posted is an init script. Init scripts are run during startup, and in this case, it's used to call the main salt-minion entry point. There are tons of resources on the web if you are not familiar with initscripts, for example: https://www.linux.com/learn/managing-linux-daemons-init-scripts The salt-minion entry point (main python script that starts the minion) should be copied from salt/scripts/salt-minion (from your repo) into /usr/bin. As I mentioned above, you can run the main salt entry point in debug mode in the foreground if you need further debugging (salt-minion -l debug).

[Daklu]

I appreciate your patience with my rudimentary questions Alejandro.  I haven't yet been able to get a minion running on the target or the master running on my linux vm, but I was able to install the environment from the link below and see both the master and two minions running.  Now I'm doing comparisons between the vagrant environment and my own environments to see what I have done wrong.

https://docs.saltstack.com/en/getstarted/fundamentals/index.html

[Alejandro_del_Castillo]

No worries, glad to give some pointers. Running the vagrant environments will definetly get you more familiar with Salt, then the missing problems might become more obvious. Running on the foreground with debug flags and looking at the logs can help you out too.

[Daklu]

Progess is slow, but I think I'm narrowing it down.  I still haven't been able to start the minion in debug mode, so I've resorted to trying to execute the minion entry point (python script) interactively line by line via a terminal window.  As near as I can tell the python installation on the target isn't quite right.  Starting the python command line interpreter works, but I get the following messages:

Could not find platform independent libraries <prefix>

Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]

After starting python, I tried entering the first line in the entry point script:

>>> from salt.scripts import salt_minion

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "/usr/lib/python2.7/site-packages/salt/__init__.py", line 76, in <module>

    __define_global_system_encoding_variable__()

  File "/usr/lib/python2.7/site-packages/salt/__init__.py", line 43, in

    __define_global_system_encoding_variable__ import locale

ImportError: No module named locale

>>>

I found the locale.py file in /usr/lib/python2.7 on my desktop system, but the same file isn't there on the target.  Furthermore, the comments indicate it references the C library's locale API, which I'm guessing isn't supported yet on the sbRIO, so I'm not inclined to simply copy the file to the target.  I also couldn't find anything referring to python and locale via opkg.  Any clue which package on NI's opkg servers, if any, contains the correct module?

[Daklu]

The locale module call in site-packages/salt/__init__.py appeared to be related to Windows-specific code, so I commented out that block and proceeded.  I also removed the is_windows functions from /etc/init.d/salt-minion.  Neither of those edits appear to have broken things.  (Yet.)

While trying to execute the two imports remaining in the python entry point directly from the python environment, I've discovered dependencies on these packages, all of which I've been able to install with opkg:

python-logging

python-threading

python-multiprocessing

python-subprocess

Now I've run into another obstacle.  The salt.utils module needs to import a module named contextlib and I haven't found any references to it in NI's opkg repository.  I've copied contextlib.py from my linux vm to the target, tried salt-minion -l debug again, and now I'm getting an ImportError: No module named distutils.version.

I have no idea how long this string of copying and/or editing scripts is going to continue, and to be honest I feel like I'm fumbling around in the dark and hoping I don't wander into a chainsaw with all this blind copying and editing.  Is there a better way to go about this that I've overlooked?

[ScotSalmon]

The opkg package "python-modules" installs all the modules, which might save you some random guessing about dependencies, at the cost of probably wasting some disk space for modules you don't end up needing.

[Alejandro_del_Castillo]

I believe there is a meta package that installs all python modules. It's a bit overkill but will hopefully get you going. You can install it via "opkg install python-modules"

[Daklu]

Okay, here are my repro steps...

Starting with a fresh LinuxMint 17.3 vm:

Install Filezilla via Software Manager

Install PuTTy via Software Manager

> sudo apt-get install git

> sudo apt-get install expect

> sudo apt-get install python-tornado

Starting with a freshly formatted sbRIO-9627:

Install cRIO software dated Aug 2015.  No add-ons.

On target:

> opkg install python-modules

> opkg install python-pyyaml

> opkg install python-tornado

On VM:

> git clone -b v2016.3.2 https://github.com/saltstack/salt.git /home/dave/salt

Copy /home/dave/salt/conf/minion to /home/dave/salt/conf/salt-minion

Edit /home/dave/salt/conf/salt-minion to include the appropriate master address

Copy /home/dave/salt/scripts/salt-minion to /home/dave/salt/scripts/salt-minion-orig

Edit /home/dave/salt/scripts/salt-minion to remove references to is_windows

# copy salt binaries to target

> scp -r /home/dave/salt/salt admin@172.16.200.5:/usr/lib/python2.7/site-packages/

# copy salt-minion entry point to target

> scp /home/dave/salt/scripts/salt-minion admin@172.16.200.5:/usr/bin/

# copy salt-minion conf file to target

> scp /home/dave/salt/conf/salt-minion admin@172.16.200.5:/etc/salt

# copy other python files that are required by Salt but not available via opkg

> scp /usr/lib/python2.7/contextlib.* admin@172.16.200.5:/usr/lib/python2.7/

> scp /usr/lib/python2.7//dist-packages/tornado/concurrent.* admin@172.16.200.5:/usr/lib/python2.7/site-packages/tornado/

That's the setup.  Now, when I try salt-minion -l debug on the target, I get the traceback shown in the attached file.  I think the last line is the relevant part:

ImportError: cannot import name raise_exec_info

I can't find any information on raise_exec_info, nor is it obvious to me why it it being imported there.  Any clues on how I can work around this?

[Alejandro_del_Castillo · Accepted solution]

Which version of the NI Linux Real-Time distribution are you using? The version of LV that you use to install the distro would be good to know.

I am suspecting you are using a version that has feeds with an old version of tornado, which lacks raise_exec_info. My advice would be to remove the tornado package (opkg remove <package_name>) and install tornado via pip (https://en.wikipedia.org/wiki/Pip_(package_manager).  You can install pip via "opkg install python-pip".

Also, I don't think you need to edit the salt-minion script to remove reference to is_windows....shouldn't matter...

[Daklu]

I'm using LV2015 to install the RIO software from Aug 2015.

I'm away from my desk until next Wednesday, but I'll try your suggestion then.