c0t0d0s0.org

There is a really interesting tool to gather informations from a running process. Let´s assume a fellow admin is in her or his well-deserved vacation and now you have to reboot the new machine, because you have to service the memory. Of course you look into the documentation and you find a process that isn´t covered by the documentation and there doesn´t seem to be an startup script or SMF manifest that starts this application. D'oh ... yet another last-minute pre-vacation change ... shouldn't happen, but it does happen.

Let´s assume you found an process called application in the process list:

bash-3.2# ps -ef | grep "application" | grep -v "grep"
    root 27943 27888   0 23:08:23 pts/1       0:00 /bin/perl ./application --start --debug --foobar=e3421
jmoekamp 27945 27824   0 23:08:28 pts/2       0:00 grep application

You look into the application source code (it´s a perl script, so this isn´t a problem and you see, that the application uses environment variables for config information. Now you have a problem. What are the correct settings of the environment variables? How can you gather the correct information to startup the application again. Solaris can help here with a programm called pargs.

At first let´s check the environment of the application first. It´s important to know, that you just can lookup this informations for processes you own. You need to get root privileges to see this information for other processes. Okay, the pargs command offers the -e switch for this task.

# pargs -e 27943
27943:  /bin/perl ./application --start --debug --foobar=e3421
[...]
envp[3]: DATABASEHOST=foobar.server.de
[...]
envp[6]: USERNAME=snafu
[...]
envp[13]: DATABASEDB=importantdatabase
[...]

There is another interesting switch. You can use pargs with the -l switch to get the full command line that was used to start the script, albeit this isn't that interesting, as you could get similar information with /usr/ucb/ps -auxwwww. But with a known process id pargs is much more comfortable.

# pargs -l 27943
/usr/perl5/5.8.4/bin/perl ./application --start --debug '--foobar=e3421' 

Now you should have all informations to restart the script and -by the way- to update the documentation for the fellow admin.

There is a nice walkthrough for configuring Opensolaris as an CIFS fileserver for home use at the Sun Developer Network . It´s really simple: Developer Recipes: Setting Up an OpenSolaris NAS Box. And NFS ist just a zfs set sharenfs=on examplepool/examplefilesystem away.

How can you use this feature? Some use cases are really obvious. It´s a natural match for disaster recovery. The Sun Cluster Geographic Edition even supports this kind of remote mirror out of the box to do cluster failover with wider distances than just a campus. But it´s usable for other jobs as well, for example for migrations to a new datacenter, when you have to transport a large amount data over long distances without a time window for a longer service interruption.

A new scenario: Okay, the filesystem gets replicated now. Let´s assume that we use /dev/rdsk/c1d0s1 for a database. The filesystem and the database partition are used from the same application and it´s important, that the metadata in the database an the binary objects are in sync even when you switched over to the remote site, albeit it´s acceptable to lose the last few transactions, as both sites are 1000km away from each other and synchronous replication is not an option.

One of the most essential tasks when configuring disaster recovery mechanism is training the procedure. Thus let´s test the switch into our remote datacenter. We will simulate a failure now. This will show that the data really get´s replicated to a different system

After this short introduction in the theory of AVS Remote mirror, we will set up such an replication between two hosts.

Some words about Sun StorageTek Availability Suite at first: We´ve opensourced the product quite a while ago. While it´s a commercial product for Solaris, we´ve integrated it into Solaris Express Community Edition and Developer Edition.

Solaris was designed with commercial customers in mind. Thus this operating environment has some capabilities that are somewhat useless for the soho user, but absolutly essential for enterprise users. One of this capabilities is remote replication of disk volumes. Imagine the following situation. You have a database and a filesystem for a central application of your company. The filesystem stores binary objects (for example images or something like that). The application is so important for your company, that you plan to build a replicated site. And now your problems start.

I´ve wrote a quite long tutorial about RBAC and privileges. I had to divide it into 4 seperate parts:

• Less known Solaris features: RBAC and Privileges - Part 1: Introduction
• Less known Solaris features: RBAC and Privileges - Part 2: Role based access control
• Less known Solaris features: RBAC and Privileges - Part 3: Privileges
• Less known Solaris features: RBAC and Privileges - Part 4: Epilogue

PS: The topic is quite complex, thus i simplified some coherences. I hope i didn´t oversimplified them ...

The story of root - reprise
And then there was root again. And root was allmighty. And this time, it wasn´t a bad thing. root was able to distribute the powers between the servants. But no one was as powerful as root. They had only the powers to do their job. But not more. One servant had still the problem with to many prayers, but now this servant wasn´t able to destroy the world.

Privileges
We´ve talked a lot about RBAC, roles, role profiles. But what are Privileges? Privileges are rights to do an operation in the kernel. This rights are enforced by the kernel. Whenever you do something within the kernel the access is controlled by the privileges.

Some basic terms
As usual the world of RBAC has some special terms. Before using it, i´m want to explain the jargon. I copy the exact definition from the RBAC manual:

The Story of root
And then there was root. And root was allmighty. And that wasn´t a good thing. root was able to control the world without any control. And root needed control. It was only a short chant between the mere mortals and root. Everybody with the knowledge of the magic chant was able to speak through root.

The configuration walkthough is complete and i´ve posted it to the wiki. I will write additional explanations in the next days ...

Im Solarium ist jetzt der "Solaris Container Leitfaden" zu finden. Dem Dokument fehlt ein wenig noch der Kochbuchbereich, dafür beschreibt er schon recht gut die Einsatzgebiete. Für einen echten Walktrough-Guide empfehle ich aber immer noch das Zones-Tutorial von Brendan Gregg.