Blog O’ Matty

I previously discussed using pca to get security updates. One thing I didn’t realize at the time was pca’s ability to list or install only the patches that are classified as security and reliability updates. This ability to filter patches is accomplished by adding the “r” (reliability updates) or “s” (security updates) character to one of the available patch group operands (e.g., missing, installed, all, total, unbundled, bad). The following example shows how the “r” and “s” characters can be used to list all patches that are classified as security and reliability updates:

$ pca -l missingrs

Using /var/tmp/patchdiag.xref from Jan/26/07
Host: tigger (SunOS 5.10/Generic_118833-24/sparc/sun4u)

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- -------------------------------------------------------
118666 09 < 10 -S-  16 J2SE 5.0: update 10 patch (5.0u10)
118667 09 < 10 -S-  16 J2SE 5.0: update 10 patch (5.0u10), 64bit
119213 10 < 11 -S-  17 NSS_NSPR_JSS 3.11.4: NSPR 4.6.4 / NSS 3.11.4 / JSS 4.2.4
119254 32 < 34 RS-   2 SunOS 5.10: Install and Patch Utilities Patch
119850 21 < 22 R--  18 SunOS 5.10: mpt driver & picl plugins patch
120719 01 < 02 RS-  16 SunOS 5.10 : SunFreeware gzip patch
120824 -- < 07 R--  12 SunOS 5.10: SunBlade T6300 & Sun Fire (T1000, T2000) platform patc
121118 08 < 10 R--  25 SunOS 5.10: Sun Update Connection System Client 1.0.8
122032 02 < 03 R--  16 SunOS 5.10: Update timezones patch
124943 -- < 01 -S-  16 SunOS 5.10: SunFreeware gzip man pages patch
124997 -- < 01 RS-  10 SunOS 5.10: /usr/bin/tip patch

If you want to install all of the available security and reliability updates, you can specify the “r” or “s” character as part of the installation process:

$ pca -i missingrs

Using /var/tmp/patchdiag.xref from Jan/26/07
Host: tigger (SunOS 5.10/Generic_118833-24/sparc/sun4u)

Patch  IR   CR RSB Age Synopsis
------ -- - -- --- --- -------------------------------------------------------
118666 09 < 10 -S-  16 J2SE 5.0: update 10 patch (5.0u10)
                       Download 1/11: done
                       Install  1/11: done

118667 09 < 10 -S-  16 J2SE 5.0: update 10 patch (5.0u10), 64bit
                       Download 2/11: done
                       Install  2/11: done

119213 10 < 11 -S-  17 NSS_NSPR_JSS 3.11.4: NSPR 4.6.4 / NSS 3.11.4 / JSS 4.2.4
                       Download 3/11: done
                       Install  3/11: done
    < ..... >

I wish I would have noticed this earlier, since it would have saved me having to write a shell wrapper. :)

One nifty feature that recently made it’s way into OpenBSD is the ability to remotely update packages with the pkg_add utility. This is accomplished by adding the URL of a remote repository to the PKG_PATH variable, and then running pkg_add with the “-u” (update packages) and optional “-v” (verbose output) and “-i” (interactice installation) options:

$ export PKG_PATH=”ftp://ftp.openbsd.org/pub/OpenBSD/3.9/packages/i386/”

$ pkg_add -uvi

Candidates for updating curl-7.15.3 -> curl-7.15.1 curl-7.15.3
Ambiguous: curl-7.15.3 could be curl-7.15.1 curl-7.15.3
Choose one package
         0: 
         1: curl-7.15.1
         2: curl-7.15.3
Your choice: 2
Looking for updates: complete
Running the equivalent of pkg_add -r curl-7.15.3
parsing curl-7.15.3
Already installed: curl-7.15.3

This is a super useful feature for busy admins, and will definitely make my life easier!

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!

EXT3, along with most other file systems, can incur file level fragmentation over time. To see how fragmented a file on an EXT3 file system is, the filefrag utility can be run with the “-v” (verbose) option and the name of a file to check for fragmentation:

$ filefrag -v ick

Checking ick
Filesystem type is: ef53
Filesystem cylinder groups is approximately 3832
Blocksize of file ick is 4096
File size of ick is 115910586 (28299 blocks)
Discontinuity: Block 858 is at 788667 (was 787807)
Discontinuity: Block 2716 is at 790536 (was 790527)
Discontinuity: Block 4754 is at 792592 (was 792575)
Discontinuity: Block 6784 is at 794632 (was 794623)
Discontinuity: Block 23144 is at 820195 (was 811007)
Discontinuity: Block 23149 is at 821452 (was 820199)
ick: 7 extents found, perfection would be 1 extent

The easiest way I have found to reduce file fragmentation is to copy a fragmented file to a new location in the file system hierarchy (i.e., a new directory), and use that file instead of the original. I really wish there was a tool similar to VxFS’s fsadm utility to defragment files w/o having to copy them (this is impractical for file systems that store lots of data).