Skip to main content

Salt Diaries: installing on SLES (episode 3)

Welcome to the third episode of the series! In the previous posts we have installed salt on CentOS machines and then moved on with a basic state configuration (we will cover more in the coming postst).

Now it's time to handle those pesky SLES hosts for which there are no pre built binaries. Therefore we'll have to install salt using pip.
I'll cover SLES11 in this post as that's the only variant I have. Hopefully other versions should require only minor changes.

Note: active subscription to Novell update service is required as the following packages can only be found on SLES 11 SDK (it's an iso, and a large one, so if you don't have it around start downloading it before you start): python-devel libopenssl-devel zlib-devel swig

Installation

Add the SDK iso in the Software Management sources. Then, as root, run the following commands (answer yes when required):

zypper in gcc-c++ python-devel libopenssl-devel zlib-devel swig
zypper -p http://download.opensuse.org/repositories/home:/fengshuo:/zeromq/SLE_11_SP1/ -v in zeromq
curl http://python-distribute.org/distribute_setup.py | python
curl https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python
pip install -U salt

Running salt-minion

Salt programs (salt-minion, salt, salt-key, etc) should now be installed. Since pip does not provide init scripts or configuration files, we'll have to handle that ourselves. For the configuration file there are lots of options: it can be copied from other minions, can be totally dispensed with (if your salt master is resolvable as salt) o can be as minimalistic as:

log_file: /var/log/salt/minion
master: your-master-hostname



In my case I went for the minimalistic option and created the minion file with just the lines above in /etc/salt.

To have salt-minion start and stop as a service I copied the /etc/init.d/skeleton template in /etc/init.d/salt-minion and customized it.

The edited version is available in this gist (remember to chmod it if you copy it from the gist).



The service can then be activated with:


chkconfig salt-minion on



Reboot and enjoy.












Labels:

































Comments
















Arlington Window Shutters said…




Thaanks great blog






12:13 PM




















Post a Comment
























Popular posts from this blog



















Mirth: recover space when mirthdb grows out of control




























I was recently asked to recover a mirth instance whose embedded database  had grown to fill all available space so this is just a note-to-self  kind of post.   Btw: the recovery, depending on db size and disk speed, is going to take long.    The problem   A 1.8 Mirth Connect instance was started, then forgotten (well neglected, actually). The user also forgot to setup pruning so the messages filled the embedded Derby database until it grew to fill all the available space on the disk.   The SO is linux.    The solution   First of all: free some disk space so that the database can be started in embedded mode from the cli. You can also copy the whole mirth install to another server if you cannot free space. Depending on db size you will need a corresponding amount of space: in my case a 5GB db required around 2GB to start, process logs and then store the temp files during shrinking.    Then open a shell as the user that mirth runs as (you're not running it as root, are you?) and cd in




















Post a Comment









Read more






























From 0 to ZFS replication in 5m with syncoid




























The ZFS  filesystem has many features that once you try them you can never go back. One of the lesser known is probably the support for replicating a zfs filesystem by sending the changes over the network with zfs send/receive.     Technically the filesystem changes don't even need to be sent over a network: you could as well dump them on a removable disk, then receive  from the same removable disk.   




















1 comment









Read more




























How to automatically import a ZFS pool built on top of iSCSI devices with systemd




























When using ZFS on top of iSCSI devices one needs to deal with the fact that iSCSI devices usually appear late in the boot process. ZFS on the other hand is loaded early and the iSCSI devices are not present at the time ZFS scans available devices for pools to import.     This means that not all ZFS pools might be imported after the system has completed boot, even if the underlying devices are present and functional. A quick and dirty solution would be to run  zpool import <poolname>  after boot, either manually or from cron.     A better, more elegant solution is instead to hook into systemd  events and trigger zpool import as soon as the devices are created.   




















Post a Comment









Read more