c0t0d0s0.org

Let's assume you want to limit ssh login for user junior to a certain timespan, let's say weekdays between 13:10 and 17:00. With Solaris 11.2 it's really easy to limit access to certain services based on times.

Just as i saw it in a blog on blogs.oracle.com (not link here) and my comment isn't published there: I wouldn't use rdate for syncing time between servers. rdate is largely considered as totally obsolete (installing pkg:/network/legacy-remote-utilities should tell you something just by the red part of the name of the package) and using ntp is really easy and has a much better mechanism to get time synced . I wrote a tutorial about that quite a while ago: "Configuring an NTP client in Solaris 11"

Before i forget someone: A very big "THANK YOU!" for all the nice wishes and congratulation for my birthday yesterday!

As much as there is often a lot discussion about configuration items inside the SMF repository (like the hostname), it brings an important advantage: It introduces the concept of dependencies to configuration changes. What services have be restarted when i change a configuration item. Do you remember all the services that are dependent on the hostname and need a restart after changing it? SMF solves this by putting the information about dependencies into it configuration. You define it with the manifests.

However, as much configuration you may put into SMF, most applications still insists to get it's configuration inside the traditional configuration files, like the resolv.conf for the resolver or the puppet.conf for Puppet. So you need a way to take the information in the SMF repository and generate a traditional config file with it. In the past the way to do so, was some scripting inside the start method that generated the config file before the service started.

Solaris 11.2 offers a new feature in this area. It introduces a generic method to enable you to create config files from SMF properties. It's called SMF stencils.

Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.

'nuff said.

This blog entry wasn't on my radar somehow, nevertheless it reports about an important change to OpenSSL on Solaris 11.2. The most important change from my point of view is the inlining of T4/T5 crypto to Solaris 11.2 openssl:

Years and years ago, I worked on the SPARC T2/T3 crypto drivers. On the SPARC T2/T3 processors, the crypto instructions are privileged; and therefore, the drivers are needed to access those instructions. Thus, to make use of T2/T3 crypto hardware, OpenSSL had to use pkcs11 engine which adds lots of cycles going through the thick PKCS#11 session/object management layer, Solaris kernel layer, hypervisor layer to the hardware, and all the way back. However, on SPARC T4/T4+ processors, crypto instructions are no longer privileged; and therefore, you can access them directly without drivers. [...]
What does that means to you? Much improved performance! No more PKCS#11 layer, no more copy-in/copy-out of the data from the userland to the kernel space, no more scheduling, no more hypervisor, NADA! [...]

Darren Moffat wrote an interesting blog entry about the security concept of Kernel zones. In "Overview of Solaris Zones Security Models". He is especially talking about a very small, but very very interesting detail:

Note that what follows is an out line of implementation details that are subject to change at any time: The kernel of a Solaris Kernel Zone is represented as a user land process in a Solaris non global zone. That non global zone is configured with less privilege than a normal non global zone would have and it is always configured as an immutable zone. So if there happened to be an exploit of the guest kernel that resulted in a VM break out you would end up in an immutable non global zone with lowered privilege.

Now you have a working Puppet testbed in your Solaris 11.2 beta installation it's time to try some Solaris specific stuff. Oracle a number of additional stuff in order to control Solaris specifics like boot environments, VNICs or SMF. You can find the respective code at java.net.

Am 12.6. findet auch in Hamburg ein Oracle Business Breakfast zum Thema Solaris 11.2 statt. Ich werde dort nicht vortragen, diesmal ist mein Kollege Stefan Hinker dran. Wenn Ihr die Möglichkeit habt nach Berlin zu fahren als Hamburger, würde ich vorschlagen, das ihr euch für Berlin anmeldet (Stefan, no insult intended, doch der VP Solaris Core OS als Vortragender ist ... sagen wir es mal so ... eine seltenere Gelegenheit dem Verantwortlichen die Meinung zu sagen ). Der Vortrag findet im Oracle CVC in der Innenstadt von Berlin statt und ist ganz gut vom Hauptbahnhof erreichbar. Habt ihr keine Gelegenheit dazu, ist Hamburg eine gute Alternative, die Agenda ist identisch in für beide Events. Die Anmeldung für Hamburg ist hier verfügbar.

At the recent announcement we talked a lot about the Puppet integration. But how do you set it up? I want to show this in this blog entry.

However this example i'm using is even useful in practice. Due to the extremely low overhead of zones i'm frequently seeing really large numbers of zones on a single system. Changing /etc/hosts or changing an SMF service property on 3 systems is not that hard. Doing it on a system with 500 zones is ... let say it diplomatic ... a job you give to someone you want to punish.

Puppet can help in this case making of managing the configuration and to ease the distribution. You describe the changes you want to make in a file or set of file called manifest in the Puppet world and then roll them out to your servers, no matter if they are virtual or physical. A warning at first: Puppet is a really,really vast topic. This article is really basic and it doesn't goes more than just even toe's deep into the possibilities and capabilities of Puppet. It doesn't try to explain Puppet ... just how you get it up and running and do basic tests. There are many good books on Puppet. Please read one of them, and the concepts and the example will get much clearer immediately.

To show this, i have a relatively simple setup. A global zone and three non-global zones. In this example i will set up the global zone as a Puppet master and will configure three non-global zone with the Puppet agent, the component that gathers information from the Puppet master in order to do something on the server running the agent.

The Puppet master is called master, the agents are called agent1, agent2 and agent3. This tutorial assumes that you have already set up the zones and that they have working network connection.

Am 13.6. findet ein Oracle Business Breakfast im Customer Visit Center in Berlin zum Thema "Solaris 11.2" statt. Es wird allerdings kein lokaler Kollege sprechen, sondern mit Markus Flierl ein Kollege aus dem Engineering, der die Entwicklung als VP Solaris Core Technology verantwortet. Die Agenda und die Möglichkeit zur Anmeldung findet ihr hier. Um zahlreiches Erscheinen wird gebeten!

Stefan Hinker wrote an interesting blog entry about recent performance improvements with LDOMs in his article "Improved vDisk Performance for LDoms":

In conclusion, with the new, improved virtual networking and virtual disk IO that are now available, the range of applications that can safely be run on fully virtualized IO has been expanded significantly. This is in line with the expectations I often find in customer workshops, where high end performance is naturally expected from SPARC systems under all circumstances.

Casper is - as usual - a good information about Solaris: In his blog he is writing about some changes in Solaris 11.2: For example he is writing about the removal of unlink/link for directories in "Solaris 11.2: unlink(2)/link(2) for directories: your time is up.". Another interesting article is "Solaris 11: Evolution of v_path." about the changes to the vnode-to-pathname mapping in the light of newer Solaris 11 features.

A hint for people trying out kernel zones: When you just enter the commands some blogs or websites were posting you may run into the problem that the zone won't boot and the boot fails with a message indicating lack of memory. When you want to use kernel zones please limit the ARC cache of ZFS like This can be done with a entry like set zfs:zfs_arc_max=0x40000000(for an 1 Gig ARC) in /etc/system. This is necessary due to the fact that a kernel zone is allocating a lot of memory in a short time and sometimes the ZFS arc can't get out of the way fast enough.

Sometimes small options are really useful. When you enable a service, for example the Apache HTTPD, you enter svcadm enable apache22. This command immediately return. There is no direct feedback at the command return, if the service has started. So you often see people doing something like that:

root@kusanagi:~# svcs -a| grep "apache22"
disabled       22:16:52 svc:/network/http:apache22
root@kusanagi:~# svcadm enable apache22
root@kusanagi:~# svcs -a| grep "apache22"
offline*       22:17:20 svc:/network/http:apache22
root@kusanagi:~# svcs -a| grep "apache22"
offline*       22:17:20 svc:/network/http:apache22
root@kusanagi:~# svcs -a| grep "apache22"
offline*       22:17:20 svc:/network/http:apache22
root@kusanagi:~# svcs -a| grep "apache22"
offline*       22:17:20 svc:/network/http:apache22
root@kusanagi:~# svcs -a| grep "apache22"
online         22:17:31 svc:/network/http:apache22

ust before you ask ... i included a sleep 10 at the right place in the method script of the http:apache22 service to delay the startup in order to demonstrate the command. The service goes from disabled to offline(the state where a service is enabled but the startup hasn't completed) and is flagged as a service in transition to a different state (like online) by the *.

However you can change this behaviour. When you use the -s the svcadm enable command just returns when the state transition has completed. So for example when the service got from offline to online. The svcadm command with the -s option will return as well when it determined that it can't do the desired state transition and needs admin intervention.

In our example we would use svcadm enable -s apache22. As we artificially delayed the startup of the Apache, the svcadm command should run at least 10 seconds. Let's check this:

# ptime svcadm enable -s  apache22

real       11.137908105
user        0.012195633
sys         0.018084807

This synchronous mode works with svcadm enable as well as with svcadm disable even in Solaris 10. In Solaris 11.2 the synchronous mode was introduced to all svcadm subcommands including the mechanism to define a timeout after which the svcadm command return with an error code that the state transition hasn't completed with the timeout. However it's just the waiting for the state transition that is timouted, the service itself proceeds with it's bring up.

This is a nifty small tool that i'm using quite often in scripts that stop something and do some tasks afterwards and i don't want to hassle around with the contract file system. It's not a cool feature, but it's useful and relatively less known. An example: As i wrote long ago, you should never use kill -9 because often the normal kill is intercepted by the application and it starts to do some clean up tasks first before really stopping the process. So just because kill has returned, it doesn't imply that the process is away. How do you wait for process to disappear?