If you haven't read my disclaimer for my Learning SMF blog catetory, please do so.

My first SMF assignment is to add a security audit event for the creation of a child object. The new event name will be AUE_smf_create.

repcache_protocol.h documents the protocol between sys.configd and its clients. In my case the message of interest is ENTITY_CREATE_CHILD which is designated by the REP_PROTOCOL_ENTITY_CREATE_CHILD request code defined in the rep_protocol_requestid enum in repcache_protocol.h.

The question I now have is where does this request code get processed in configd? The communication between sys.configd and its clients takes place over Solaris doors. The main() function in configd.c calls setup_main_door(). This in turn calls door_create(3c) specifying main_switcher() as its service procudure. main_switcher only processes REPOSITORY_DOOR_REQUEST_CONNECT requests, however.

When main_switcher gets a connect request, it calls create_connection() which in turn calls create_client(). create_client in client.c creates a new door for communication between sys.configd and the new client. It does this by calling door_create specifying client_switcher() as the service procedure. To summarize, when sys.configd gets a connect request from a client, it creates a new door for communication with that client. Subsequent requests that come in on that door will be serviced by client_switcher in client.c

client_switcher extracts the request code from the incomming messages, and uses it to index into the array of protocol_entry structures at protocol_table in client.c. After performing some checks, client_switcher calls the function whose address is in the pt_fd_handler member of the protocol_entry structure. From this, I can see that entity_create_child() is the function that is used to process REP_PROTOCOL_ENTITY_CREATE_CHILD requests. I'll leave the discussion of this function for my next blog.

Technorati Tags: OpenSolaris, Solaris, smf

If you haven't read my disclaimer for my Learning SMF blog catetory, please do so.

I am looking at the code in on/usr/src/cmd/svc/configd/configd.c which contains the main() function for svc.configd(1M). I won't go into everything that main does, but here are the highlights.

Undocumented Command Line Options

There are a number command line options that are not documented in the man page. I assume that they are undocumented, because they are primarily for use by SMF developers in testing and debugging the configd code. The options are:

-d door_path

Normally, configd listens on the door at /etc/svc/volatile/repository_door for calls from its clients. This option allows you to specify an alternate door location. It also sets is_main_repository to 0, but I haven't figured out the effect of this yet. Finally, have_npdb is set to 0 to indicate that there are no non-persistent databases.

-n

Don't turn the process into a daemon. That is to say, do not fork and run in the background.

-p

Run in privileged mode. In this mode, configd will only accept connections from its parent process. The use of syslog is turned off (log_to_syslog set to 0), and is_main_repository is set to 0. In addition the global variables, privileged_pid and privileged_psinfo_fd are set. privileged_pid gets the PID of the parent, and privileged_psinfo_fd is a file descriptor for reading the parent's psinfo data in /proc.

-r db_path

Sets the path to the persistent repository database. By default configd uses /etc/svc/repository.db.

-t npdb_path

Sets the path for the non-persistent database repository. Default is /etc/svc/volatile/svc_nonpersist.db.

Other Things that main() Does

This is not an exhaustive list of what main does, but here are the highlights.

• If not running as root, only users with our effective user ID can access configd.
• Turn into a daemon unless -d was specified.
• Initialize the back end database (backend_init).
• Set up a list pool for threads.
• Call door_server_create() to tell the door software to use new_thread_needed() to create new threads.
• Call setup_main_door() to create the door for our clients to use.

Technorati Tags: OpenSolaris, Solaris, smf

I am moving off of my work on the Solaris Volume Manager (SVM) to join the Service Management Facility (SMF) team, so I have a lot of new code to learn. In the past when I had to learn a new body of code, I would keep notes in a file that I could refer to as time went on. This time, however, in the spirit of Open Solaris, I'm going to try keeping my notes in a blog. To that end, I've created a new blogging category called Learning SMF.

Make no mistake, my ramblings in this category are not going to be a well thought out authoritative explanation of some aspect of SMF. In the future I hope to generate some of those in a separate blog category, but for now all that you get from me are the ramblings of an SMF rookie digging into the code for the first time. Probably some of the things that I write in this category will turn out to be wrong. For more informed discussions of SMF check out the blogs of the long time members of the team — Jonathan Adams, Stephen Hahn, Dave Powell, and Liane Praza (in alphabetical order).

My first SMF assignment is to add code to svc.configd(1M) to generate security audit events. So in subsequent blogs, I'll be looking at the code in on/usr/src/cmd/svc/configd/configd.c.

Technorati Tags: OpenSolaris, Solaris, smf

Sun provides excellent Live Upgrade documentation in their Answer Books. Live Upgrade is a powerful tool that allows you to do many things, but all I wanted to do was a simple upgrade of my laptop every time a new Nevada build comes out. I like to be running the latest code. Thus, I wrote these notes that are aimed specifically at this need.

First of all you need enough room for two root slices. One is for the booted running system and the other is where the live upgrade takes place. The two root slices are called Boot Environments (BE) in live upgrade lingo.

At a high level live upgrade consists of the following steps:

• copy the running BE to a new BE
• upgrade the new BE
• activate the new BE
• reboot using init 6 into the new BE

Thus, the only down time is when you reboot.

You must have the latest live upgrade packages on your system, before creating a new BE. So the first step is to pkgrm SUNWluu, SUNWlur and SUNWlucfg. Then pkgadd them from the distribution media that you are going to upgrade to. They are on CD2 if you have a CD set.

Now for more details. Let's assume that your two root slices are sa and sb. They can be on the same disk or different disks. The process of creating the BE is a little different the first time that you do a live upgrade and when you do subsequent upgrades, so I'll discuss them separately.

First Time BE Creation

To start out with, you don't have any BEs, so you need to create one. Let's assume that you are running snv_37 (Nevada build 37) on sa and that you want to upgrade to snv_38 on sb. You would do something like:

lucreate -m /:/dev/dsk/sb:ufs -n snv_38 -c snv_37

The options are:

• -m specifies the root filesystem for the new boot environment
• -n is the name of the new BE
• -c gives a BE name to the currently running OS. You only need to use -c once.

This command does a newfs on sb and then copies the file system on sa to sb. You can create additional BEs using lucreate again, but without the -c option. I sometimes find this to be handy in testing situations, but I never have more than two BEs on my laptop.

Subsequent BE creations are discussed later.

Doing the Upgrade

Now you upgrade the snv_38 BE. First throw in the DVD or first CD into your machine and let vold(1m) mount it. The command to start the upgrade is:

luupgrade -u -n snv_38 -s <mount point of media>

If you have a DVD, this will do the entire upgrade. If you have CDs, wait for this command to exit. Eject the CD and then put in the next one. The command to use for the 2nd and subsequent CDs is:

luupgrade -i -n snv_38 -s <mount point of media>

Note that you're using -i instead of -u.

Booting

Now activate the new BE using:

luactivate snv_38
init 6

Don't use reboot. The system will boot up into the new BE.

Subsequent BE Creation

Now that you have two BEs (snv_37 and snv_38) the process is slightly different. Let's assume that you're booted into snv_38 on sb, and you want to upgrade to snv_39. Do the following:

lumake -n snv_37
lurename -e snv_37 -n snv_39

The first command copies the active BE to the BE named snv_37. It takes the place of lucreate. The second command renames snv_37 to snv_39. Now you do the upgrade the same way as before.

As you can see, you can alternate between the two boot environments as new Solaris builds become available.

A Few More Notes

• You can use luactivate to switch back and forth between BEs. If you don't like the upgrade for some reason, you can go back to the previous BE.
• The lu commands take care of the grub menu.lst on x86/x64 boxes.
• All lu* commands must be run as root.
• The lustatus command is handy to see where you are.

My Laptop Environment

Here is how my solaris fdisk partition is sliced up (Size is in MB):

Part Tag   Cylinders       Size
   0  2       3 -   959   7506.94
   1  3     960 -  1087   1004.06
   2  5       0 -  3822   29988.52
   3  0    1088 -  2044   7506.94
   4  0    2045 -  2306   2055.19
   5  0    2307 -  2680   2933.75
   6  0    2681 -  3725   8197.23

Slices 0 and 3 are the two root slices that I used for live upgrade. As I move from one Nevada build to another I alternate between these two.

• slice 1 = swap
• slice 4 = /opt/sfw (the software companion stuff)
• slice 5 = internal Sun stuff
• slice 6 = personal stuff like my home directory and places to store the CD/DVD images that I down load. That explains the large size.

Slices 4, 5 and 6 are shared by the two BEs, so they don't get touched during a live upgrade. Here is how much free space I have on each slice. This shows that you could probably get away with less space.

Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c0d0s0      7570275 3385054 4109519    46%    /
/dev/dsk/c0d0s4      2062186 1391065  609256    70%    /opt/sfw
/dev/dsk/c0d0s5      2943130 2219261  665007    77%    /pkg
/dev/dsk/c0d0s6      8266719 3379901 4804151    42%    /local

Technorati Tag: OpenSolaris
Technorati Tag: Solaris

Coming in Build 37 of Nevada is the ability to use descriptive names for metadevices and hot spare pools in Solaris Volume Manager (SVM). Ever since it's inception as Online Disksuite, the code that we now call SVM has been very restrictive about what you can call the metadevices. Metadevices had to be called dx, where x was an interger between 0 and 8191. Hot spare pools had to be named hspnnn where n was a 3 digit number between 001 and 999.

With the putback of the Bunnahabhain project into snv_37, you can use a much richer set of names for metadevices and hot spare pools. The names can now consist of alphanumeric characters plus -, _ ..

For example, let's create some metadevices for the engineering department. We'll create a two sided mirror called engr. This example assumes that you already have the required metadbs in place. First, we'll create the two submirrors:

metainit engr-1 1 2 c1t1d0s0 c1t2d0s0
metainit engr-2 1 2 c1t3d0s0 c1t4d0s0

We now have two metadevices, called engr-1 and engr-2. These are more descriptive names than d1 and d2.

Now let's create the mirror and attach the second side.

metainit engr -m engr-1
metattach engr engr-2

The output of metastat -c shows:

engr             m  4.1GB engr-1 engr-2
    engr-1       s  4.1GB c1t1d0s0 c1t2d0s0
    engr-2       s  4.1GB c1t3d0s0 c1t4d0s0

Now let's create a hot spare pool called engr-hsp and attach it to the stripes:

metahs -a engr-hsp c1t5d0s0
metaparam -h engr-hsp engr-1
metaparam -h engr-hsp engr-2

Now, metastat -c shows:

engr             m  4.1GB engr-1 engr-2
    engr-1       s  4.1GB c1t1d0s0 c1t2d0s0
    engr-2       s  4.1GB c1t3d0s0 c1t4d0s0
engr-hsp         h      - c1t5d0s0

Finally, we can create some soft paritions for the engineering departments.

metainit chemical -p engr 1gb
metainit electrical -p engr 1gb
metainit mechanical -p engr 1gb

Once again metastat -c shows:

mechanical       p  1.0GB engr
electrical       p  1.0GB engr
chemical         p  1.0GB engr
    engr         m  4.1GB engr-1 engr-2
        engr-1   s  4.1GB c1t1d0s0 c1t2d0s0
        engr-2   s  4.1GB c1t3d0s0 c1t4d0s0
engr-hsp         h      - c1t5d0s0

The SVM team always names their projects after single malt Scotches, and this project was named Bunnahabhain. The members of the team in alphabetical order were:

• Huajian Luo
• Andre Molyneux
• Sanjay Nadkarni
• Tony Nguyen
• Steve Peng (team lead)
• Harold Shaw (team lead)
• Sean Ye
• Victor Hu
• Tom Whitten

The question of time zones is often times framed as a mobility issue. If I hop on a plane in Colorado which is in the US/Mountain time zone and fly to California, I would like my lap top to display US/Pacific time while I'm in California. When I go back home, I want my laptop's times to be back in Mountain time.

I maintain that the time zone issue is more than just a mobility issue, however. When I'm sitting in my Colorado office and login to a machine in California, the California machine displays Pacific time. Wouldn't it be nice if it would show Mountain time for me. In this case neither the machine nor I are changing our locations.

There is a quick and dirty solution to both of these problems. Change the value of the TZ environment variable. The library routines that deal with the display of time check the value of the TZ environment variable and adjust the displayed time accordingly. Give it try on a machine near you. echo TZ and note the current value, so that you can restore it. Now set TZ to a different value and type date. The time is displayed according to the TZ environment variable. I use this trick when I login to machines in California.

The default value for TZ is established in /etc/default/init for a given machine. As we have seen, an individual can override the value of TZ. A crude tool for changing time zones could be provided. When the user invokes the tool, it could edit the .profile or .chsrc to set TZ to the desired time zone. There are a number of major disadvantages to this, however:

• It is not nice to edit a users .profile or .chsrc.
• It is difficult to automatically determine how to edit these files to accomplish the desired effect.
• Processes that are already running would not see the new TZ, so the user would need to logout and login again.

I propose a different mechanism that requires more work. Instead of modifying .profile, the tool should place the user's desired time zone in a user specific repository. For this discussion, I do not want to dwell on the mechanism of a user specific reprository. It could be a dot file in the user's home directory, or it could be something more fancy. Next we need to modify the libraries that deal with the display of time, and find all the routines that interrogate the value of the TZ environment variable. These routines should be changed to first look for the time zone specification in the user specific repository. If this check fails, then look at the TZ environment variable. Changing the libraries in this way, means that running processes will see the change and begin displaying the time in the new time zone.

Here are features of this approach that are appealing to me:

• The realtime clock is not changed. See Casper Dik's blog on the problems of chaning the RTC in a multiboot environment.
• A corollary to the previous item is that the RTC clock can be set for UTC (GMT) time. This is what Unix has done from its inception.
• The solution is user specific, rather than machine wide. Thus, on a multi-user system (this is Solaris after all), each user can see the time in the zone of her or his choice.

My name is Tom Whitten, and I've worked for Sun for about 8 years. Most of that time has been spent working as a test engineer and product engineer on Solaris Volume Manager (SVM) and its predecessor, Solistice Disksuite. I've been working on one form of Unix or the other since the early 1980s, but I do not remember the exact date.

I live in southwestern Colorado, USA and telecommute to Sun's Broomfield campus which is outside of Denver, Colorado. Southwestern Colorado is part of the four corners area. It gets this name, because it is the only place in the United States where the boundries of 4 states meet at right angles. This explains the name of my blog area—Four Corners Noise.

My office is in Cortez, Colorado, and my workstation is a Dell Precision 650 running the latest build of Solaris Nevada. As of this writing that is build 17. I use live upgrade to keep up with the biweekly Nevada builds without loosing work time.

In the future I'll be talking about SVM and some of the Solaris tools that facilitate my telecommuting.