Each and every operating systemI support has a different utility to report on swap usage. On my Soalris hosts, I use the swap and vmstat utilities to check utilization:
$ swap -s
total: 36176k bytes allocated + 4672k reserved = 40848k used, 1189004k available
On Linux hosts, I use teh free and top utilities:
$ free
total used free shared buffers cached Mem: 2055340 1427696 627644 0 179124 876300 -/+ buffers/cache: 372272 1683068 Swap: 1004052 0 1004052
And on my OpenBSD servers, I use the swapctl and systat utilities:
$ swapctl -l
Device 512-blocks Used Avail Capacity Priority swap_device 262068 0 262068 0% 0
Oh how I wish there was an administrator tool naming standard. :)
To protect the communciations between an iSCSI initiator and target, the iSCSI protocol allows an enhanced CRC32 checksum to be used (this isn’t enabled on most initiators and targets by default) to protect the iSCSI headers and data payload. The Solaris iSCSI initiator supports both header and data payload checksums, which can be enabled with the iscsiadm utility:
$ iscsiadm modify target-param --headerdigest CRC32 target1
$ iscsiadm modify target-param --datadigest CRC32 target1
I have been doing some testing to see how much overhead and latency this places on the iSCSI communication process, and will make sure to blog my findings once my research is complete.
LDAP indexes are extremely useful for speeding up directory searches, and come in four flavors (there are actually more than four index types, but the following four are the most common):
1 Approximate indexes
Approximate indexes are useful for speeding up seaches that look for attribute values that sound like a specific value. A good example of this is searching the directory for all first names that sound like “Amy”:
$ ldapsearch -b "dc=prefetch,dc=net" -w -D "cn=Directory Manager" 'givenName~=Amy'
2. Equality indexes
Equality indexes are useful for speed up searches that perform a direct comparison. The following search would benefit from an equality index:
$ ldapsearch -b "dc=prefetch,dc=net" -w -D "cn=Directory Manager" 'uid=matty'
3. Presence indexes
Presence indexes are useful for speeding up searches for entries that contain a specific attribute. The following search looks for all entries that contain the cn attribute, and would be a good fit for a presence index:
$ ldapsearch -b "dc=prefetch,dc=net" -w -D "cn=Directory Manager" 'cn=*'
4. Substring indexes
Substring indexes are the most complex index type to maintain, but are useful for speeding up searches that look for substrings. The following search will return all entries where the uid attribute contains the string “foo”, and would be a good fit for a substring index:
$ ldapsearch -b "dc=prefetch,dc=net" -w -D "cn=Directory Manager" 'uid=*foo*'
Figuring out which indexes to use is actually pretty easy, since most directory servers will tell you that an unindexed search was performed. If you want to determine indexes manually, your best bet is reviewing the logfiles to see which searches are perfomed, and then creating indexes based on your findings.
Most modern day UNIX operating systems store password expiration data in /etc/shadow. This expiration data includes the last time a user changed their password, the number of days a user can use a given password, an interval to warn a user that their password is going to expire, etc. There are six (I don’t count sp_flag since it’s reserved for future use) fields that apply to password expiration, and they are described in the shadow(3) manual page:
Field 3: sp_lstchg - days since Jan 1, 1970 password was last changed.
Field 4: sp_min - days before which password may not be changed.
Field 5: sp_max - days after which password must be changed.
Field 6: sp_warn - days before password is to expire that user is warned of pending password e xpiration.
Field 7: sp_inact - days after password expires that account is considered inactive and disabled.
Field 8: sp_expire - days since Jan 1, 1970 when account will be disabled.
If you are looking for a nifty tool to help visualize this data, you can check out the super useful chage utility.
I ran into an issue this week where the Solaris device tree wasn’t updated to reflect two new targets we added. After a bit of poking around, I noticed that the new targets we created weren’t present in the sd.conf configuration file. To get the host to see the storage, I first used my sdcreate script to populate the sd.conf file with the targets and LUNs I had allocated to the host:
$ cp /kernel/drv/sd.conf /kernel/drv/sd.conf.removeme.01.21.2007
$ sd-create.sh -c 2 -n sd -p lpfc 10 15 >> /kernel/drv/sd.conf
Once the sd.conf file was populated to my liking, I ran update_drv to have sd reread it’s configuration file:
$ update_drv -f sd
After the update_drv command completed, I ran the devfsadm utility to populate the /dev entries:
$ defvsadm -C
As soon as devfsadm completed, I was able to access my new storage. Niiiice!