In my last post I had a look at the Solaris RAD API to manage ZFS, this time I am testing the UserMgr RAD module. As far as I know it is also the oldest RAD module and the backend for the “Solaris User Manager GUI”.
As the name promises the GUI allows to manage user accounts on Solaris.
A few months ago I had the chance to test an Oracle ZFS Storage Appliance (ZFS SA) and the appliance made a very good impression on many areas. It especially brought to my mind again, that ZFS shines even more if you use it as NAS (Network Attached Storage), as central fileserver which shares its storage capacity for example via NFS.
But I did not really like the distributed storage configuration. E.g. a database server needs the correct ZFS properties set on the ZFS storage appliance via the web-interface or the custom CLI and also the corresponding NFS mount options in /etc/vfstab on the database server. Maybe this sounds like no big issue to you, for example, if you are also the admin responsible for the storage appliance, or if you have a perfect collaboration with the storage team. But especially if you want to automate the storage configuration, this distribution adds a significant complexity.
Of course I wanted to manage the configuration with Puppet like a local ZFS filesystem.
I don’t yet have a ZFS SA at work to deal with, but the availability of the new RAD REST interface in Solaris 11.3 motivated me to experiment with an own Puppet resource type to manage the remote ZFS filesystems directly on the client server.
Solaris 11.3 beta ships with a REST-API for the Solaris Remote Administration Daemon (RAD), which makes RAD finally easy to use with Ruby and Puppet. The following is a small experiment to test its capabilities.
Puppet provides a nice abstraction layer of the configuration of a system. A Puppet manifest is usually easier and faster to understand than a documentation with many CLI commands. But there is no magic involved, Puppet usually executes also the same CLI commands in the background. With the debug option you can observe this command executions.
ZFS is a great filesystem, with many, many features. But for all that it is still easy to manage, in my opinion easier than other filesystems. Managing storage is usually a high risk task, which makes automation harder. Would you change the size for a critical filesystem with an automated method? If it is an ext3 filesystem on LVM and software-raid, maybe not. If it is on ZFS, a low risk modification of the quota could be enough, e.g. zfs set quota=800g rpool/criticalfilesystem. That’s easy to automate. Nowadays automation becomes even necessary because, the amount of ZFS filesystems is growing. And if you like to use more features you likely need to set more ZFS properties.
I will be at Oracle Openworld 2014, finally as speaker. Together with Glynn Foster and Eric Saxe I will talk about Puppet on Solaris. There are still some free seats, so register if you are interested:
Session: Best Practice Configuration Management with Puppet [CON7849]
A few days before I will also attend the Automation event of the year. This time I will finally take part on my first PuppetConf in person. The line-up is amazing with speakers like Gene Kim the author of “The Phoenix Project” and many other early drivers of the DevOps community.
I am in San Francisco from 23rd September to 2nd October, if you like to meet in person just ping me.
Update 25th Dec 2014: With the latest Solaris SRU (11.2.5.5.0) the important bugs which are listened here, are fixed for me. Also Puppet, Facter and Hiera are now shipped in a modern version.
With 11.2, Puppet is shipped for the first time directly with Solaris. I think it is a quite good first release, but of course not yet perfect. Puppet itself is open source software and Oracle also published all patches and Puppet types under the CDDL, so you would have the option to maintain your own build.
The huge open source community is an important part of Puppet, maybe the most important. But with Solaris you have the additional advantage that you have this open source software also covered under your usual Oracle Premier Support. With no additional cost!
This post is a follow-up to the article how to install Solaris 11.2 with Unified Archives. As explained in a former post I think the combination of Golden Images and Puppet makes a lot of sense. But what is the best or easiest method to install and configure the Puppet agent on a newly deployed server? This post shows an easy way for Solaris 11.2.
Facter is Puppet’s component for discovering information about the hardware and the operating system where the Puppet agents runs. The many auto-discovered variables (“facts”) are convenient, but facter is also a potential source for slow puppet agent executions. This post shows some tricks for troubleshooting the performance of facter.
In a former post I covered already my enthusiasm for Puppet support in Solaris 11.2. But what does it really mean? Is Puppet now the strategic systems management framework for all the Solaris stuff? In my opinion this is definitely not the case. The Solaris developers invested many years into good base technologies for systems management like the “Service Management Facility” (SMF). And with new Solaris releases, more and more systems configuration moves into SMF, into so called “SMF properties”. For example since Solaris 11 the DNS servers need to be configured in SMF properties and no longer in /etc/resolv.conf.
So if Puppet can talk to SMF the full power of SMF is also available in Puppet. In this post I will show how the managing of SMF in Puppet is possible in Solaris 11.2.
This post is part of a blog series which tries to simplify the adoption of configuration management frameworks.
Many admins are already excited about configuration management frameworks like Puppet, that’s good! With these frameworks it is possible to implement all sorts of automation for many operating systems. But does this mean you should automate every task from the beginning to the end with a single tool?
If you can do it, then of course! It has some advantages, for example you need fewer different automation skills in the company. But there is always the big risk that automating a task takes just too long.