![[Howto] Adopting Ansible Galaxy roles for Solaris](https://liquidat.files.wordpress.com/2014/02/ansible_logo_round.png?w=700){kind=logo}
It is pretty easy to manage Solaris with Ansible. However, the Ansible roles available at Ansible Galaxy usually target Linux based OS only. Luckily, adopting them is rather simple.
Background
As mentioned earlier Solaris machines can be managed via Ansible pretty well: it works out of the box, and many already existing modules are incredible helpful in managing Solaris installations.
At the same time, the Ansible Best Practices guide strongly recommends using roles to organize your IT with Ansible. Many roles are already available at the Ansible Galaxy ready to be used by the admin in need. Ansible Galaxy is a central repository for various roles written by the community.
However, Ansible Galaxy only recently added support for Solaris. There are currently hardly any roles with Solaris platform support available.
Luckily expanding existing Ansible roles towards Solaris is not that hard.
Example: Apache role
For example, the Apache role from geerlingguy is one of the highest rated roles on Ansible Galaxy. It installs Apache, starts the service, has support for vhosts and custom ports and is above all pretty well documented. Yet, there is no Solaris support right now… Although geerlingguy just accepted a pull request, so it won’t be long until the new version will surface at Ansible Galaxy.
The best way to adopt a given role for another OS is to extend the current role for an additional OS – in contrast to deleting the original OS support an replacing it by new, again OS specific configuration. This keeps the role re-usable on other OS and enables the community to maintain and improve a shared, common role.
With a bit of knowledge about how services are started and stopped on Linux as well as on Solaris, one major difference quickly comes up: on Linux usually the name of the controlled service is the exact same name as the one of the binary behind the service. The same name string is also part of the path to the usr files of the program and for example to the configuration files. On Solaris that is often not the case!
So the best is to check the given role if it starts or stops the service at any given point, if a variable is used there, and if this variable is used somewhere else but for example to create a path name or identify a binary.
The given example indeed controls a service. Thus we add another variable, the service name:
tasks/main.yml
@@ -41,6 +41,6 @@
- name: Ensure Apache has selected state and enabled on boot.
service:
- name: "{{ apache_daemon }}"
+ name: "{{ apache_service }}"
state: "{{ apache_state }}"
enabled: yes
Next, we need to add the new variable to the existing OS support:
vars/Debian.yml @@ -1,4 +1,5 @@ --- +apache_service: apache2 apache_daemon: apache2 apache_daemon_path: /usr/sbin/ apache_server_root: /etc/apache2
vars/RedHat.yml @@ -1,4 +1,5 @@ --- +apache_service: httpd apache_daemon: httpd apache_daemon_path: /usr/sbin/ apache_server_root: /etc/httpd
Now would be a good time to test the role – it should work on the suported platforms.
The next step is to add the necessary variables for Solaris. The best way is to copy an already existing variable file and to modify it afterwards to fit Solaris:
vars/Solaris.yml
@@ -0,0 +1,19 @@
+---
+apache_service: apache24
+apache_daemon: httpd
+apache_daemon_path: /usr/apache2/2.4/bin/
+apache_server_root: /etc/apache2/2.4/
+apache_conf_path: /etc/apache2/2.4/conf.d
+
+apache_vhosts_version: "2.2"
+
+__apache_packages:
+ - web/server/apache-24
+ - web/server/apache-24/module/apache-ssl
+ - web/server/apache-24/module/apache-security
+
+apache_ports_configuration_items:
+ - regexp: "^Listen "
+ line: "Listen {{ apache_listen_port }}"
+ - regexp: "^#?NameVirtualHost "
+ line: "NameVirtualHost *:{{ apache_listen_port }}"
This specific role provides two playbooks to setup and configure each supported platform. The easiest way to create these two files for a new platform is again to copy existing ones and to modify them afterwards according to the specifics of Solaris.
The configuration looks like:
tasks/configure-Solaris.yml
@@ -0,0 +1,19 @@
+---
+- name: Configure Apache.
+ lineinfile:
+ dest: "{{ apache_server_root }}/conf/{{ apache_daemon }}.conf"
+ regexp: "{{ item.regexp }}"
+ line: "{{ item.line }}"
+ state: present
+ with_items: apache_ports_configuration_items
+ notify: restart apache
+
+- name: Add apache vhosts configuration.
+ template:
+ src: "vhosts-{{ apache_vhosts_version }}.conf.j2"
+ dest: "{{ apache_conf_path }}/{{ apache_vhosts_filename }}"
+ owner: root
+ group: root
+ mode: 0644
+ notify: restart apache
+ when: apache_create_vhosts
The setup thus can look like:
tasks/setup-Solaris.yml
@@ -0,0 +1,6 @@
+---
+- name: Ensure Apache is installed.
+ pkg5:
+ name: "{{ item }}"
+ state: installed
+ with_items: apache_packages
Last but not least, the platform support must be activated in the main/task.yml file:
tasks/main.yml
@@ -15,6 +15,9 @@
- include: setup-Debian.yml
when: ansible_os_family == 'Debian'
+- include: setup-Solaris.yml
+ when: ansible_os_family == 'Solaris'
+
# Figure out what version of Apache is installed.
- name: Get installed version of Apache.
shell: "{{ apache_daemon_path }}{{ apache_daemon }} -v"
When you now run the role on a Solaris machine, it should install Apache right away.
Conclusion
Adopting a given role from Ansible Galaxy for Solaris is rather easy – if the given role is already prepared for multi OS support. In such cases adding another role is a trivial task.
If the role is not prepared for multi OS support, try to get in contact with the developers, often they appreciate feedback and multi OS support pull requests.
![[Howto] Solaris 11 on KVM](https://liquidat.files.wordpress.com/2016/01/kvm.png?w=1200)
Recently I had to test a few things on Solaris 11 and wondered how well it works virtualized with KVM. It does – with a few tweaks.
![[Howto] Managing Solaris 11 via Ansible](https://liquidat.files.wordpress.com/2015/12/tower-ansible-solaris.png?w=1200)
/home/liquidat 