Sun clearview initiative

While perusing the Solaris network discussion forum today, I came across a cool post on Sun’s clearview initiative. This project will attempt to unify the existing IP HA features (e.g., IPMP, trunking, etc.), and will be well received by the SysAdmin community (especially the ipmpadm utility and ipmp interface types). If your interested in learning more about this technology or providing feedback, check out the design document and post comments to the Solaris networking forum! Your voice will be heard!!

Reading Solaris Memory

In the Solaris Operating System the /dev/mem pseudo-device provides access to the physical memory on a server. This pseudo-device can be immensly valuable for determing the contents of memory after an intrusion, locating the contents of a file when you accidentally delete it (this assumes the file was placed into memory and is still resident), or to test memory for errors (I believe the mem test utilities use /dev/mem). To view the contents of /dev/mem, you can use the less utility:

$ less -f /dev/mem
[ … ]
^@ (try again later)^@^@^@^@^@^@SUNW_OST_OSLIB^@^@socket: All ports in use
^@^@^@SUNW_OST_OSLIB^@^@connect to address %s: ^@SUNW_OST_OSLIB^@^@Trying %s…
^@^@^@SUNW_OST_OSLIB^@^@write: setting up stderr^@^@^@^@SUNW_OST_OSLIB^@^@socket: protocol failure in circuit setup.
^@SUNW_OST_OSLIB^@^@socket: protocol failure in circuit setup.
^@SUNW_OST_OSLIB^@^@socket: protocol failure in circuit setup.
^@SUNW_OST_OSLIB^@^@Protocol error, %s closed connection
^@^@^@SUNW_OST_OSLIB^@^@Protocol error, %s sent %d bytes
^@^@^@SUNW_OST_OSLIB^@^@%d: Address family not supported
^@^@^@SUNW_OST_OSLIB^@^@%s: unknown host

This page of memory looks to be part of a network library that was loaded recently. Viva la less!

How does nohup work?

I have used nohup(1) for years to startup processes, and to ensure they keep running when my shell exits. When a shell exits, each child process will receive a SIGHUP signal, which causes the process to exit if a signal handler is not installed to deal with the SIGHUP signal. When a command is invoked with the nohup(1) utility, the signal disposition for SIGHUP is set to ignored, allowing the process to continue executing when the shell exits. We can see this with the Solaris “psig” command:

$ ssh oscar &
[1] 958

$ psig 958 | grep HUP
HUP default

The psig utility indicates that the SIGHUP disposition is set to the default, which will cause the process to terminate when we exit the shell. When the same command is invoked with the nohup utility, we can see that the signal disposition for SIGHUP is set to ignored:

$ nohup ssh oscar &
[2] 967

$ psig 967 | grep HUP
HUP ignored

Solaris is an amazing Operating system, and allows the signal dispositions of running processes (and process groups!!) to be set on the fly. This is accomplished with nohup’s “-p” and “-g” options:

$ ssh -p 443 oscar &
[1] 1081

$ psig 1081 | grep HUP
HUP default

$ nohup -p 1081
Sending output to nohup.out

$ psig 1081 | grep HUP
HUP ignored

While this isn’t the best example, hopefully you get the point. Sessions, process groups, process group leaders and controlling terminals are really neat concepts, and explained on pages 677 – 700 of Solaris Systems Programming (ISBN: 0201750392). This is an INCREDIBLE book, and sits next to my lazy boy for easy reference.

LDAP search descriptors and ‘user_attr’

I setup several Solaris systems to authenticate via LDAP last year, and periodically get the following error message in /var/adm/messages:

Dec 21 08:44:17 sparky nscd[1174]: [ID 293258 user.error] libsldap: Status: 4 Mesg: Service search
descriptor for service ‘passwd’ contains filter, which can not be used for service ‘user_attr’.

We use SSDs (service search descriptors) to tailor the search string that is sent to the directory server. This allows us to tailor who can and cannot login to our Solaris systems. After doing some digging, it looks like the following search descriptors are required to make libsldap.so happy:

NS_LDAP_SERVICE_SEARCH_DESC= user_attr:ou=people,dc=daemons,dc=net?one?&(acctActive=yes)
NS_LDAP_SERVICE_SEARCH_DESC= audit_user:ou=people,dc=daemons,dc=net?one?&(acctACtive=yes)

Since we use sudo instead of RBAC, I am still researching why the secure LDAP client queries the directory server for the user_attr information. Hopefully I can find an answer in RFC 2307 ( An approach to using LDAP as a network information service), or the documentation on docs.sun.com.