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