I often forget about the Centos Linux chage utility, and it’s ability to manage the expiration data in /etc/shadow. In addition to being able to manage password policies, chage can be be run with the “-l” option to view the policy set for a user, and the date when a users password was last changed:
$ chage -l matty
Minimum: 0
Maximum: 99999
Warning: 7
Inactive: -1
Last Change: Dec 25, 2006
Password Expires: Never
Password Inactive: Never
Account Expires: Never
If you have a security organization, ‘chage -l’ is a great command to allow them to run through sudo.
I needed to setup password policies on a few CentOS 4.4 machines last week. The password policy needed to define the minimum length of a password, the number of days a password is valid, the strength of a password, and a warning period to alert individuals that their password is about to expire. Expiration data for each user is stored in their entry in /etc/shadow, and is initially populated based on the password policies in /etc/logins.defs. Here is a list of password policies that I typically set in /etc/logins.defs:
# Password aging controls:
#
# PASS_MAX_DAYS Maximum number of days a password may be used.
# PASS_MIN_DAYS Minimum number of days allowed between password changes.
# PASS_MIN_LEN Minimum acceptable password length.
# PASS_WARN_AGE Number of days warning given before a password expires.
#
PASS_MAX_DAYS 60
PASS_MIN_DAYS 0
PASS_MIN_LEN 8
PASS_WARN_AGE 10
For accounts that were created without a password policy, the chage command can be used to create one. To enforce strong passwords, you need to add the pam module pam_cracklib.so to the password management group in /etc/pam.conf (or the applicable service definition in /etc/pam.d). Managing passwords is a pain, but it is one of the most important tasks in securing any server platform.
While setting up two new ESX 3.0 server nodes, I ran into a bizarre problem where the VI client refused to initialize several Clariion CX700 devices. Since the VI client isn’t the best environment to debug problems, I ssh’ed into the service console, and began my research by running esxcfg-vmhbadevs to list the devices on the system:
$ esxcfg-vmhbadevs -q
vmhba0:0:0 /dev/sda
vmhba1:0:0 /dev/sdc
vmhba1:0:1 /dev/sdd
vmhba1:0:2 /dev/sde
vmhba1:0:3 /dev/sdf
vmhba1:0:4 /dev/sdg
vmhba1:0:5 /dev/sdh
vmhba1:0:6 /dev/sdi
vmhba1:0:7 /dev/sdj
vmhba1:0:8 /dev/sdk
vmhba1:0:9 /dev/sdl
This listed the correct number of devices, so I decided to use dd to read data from one of the devices that was causing problems:
$ dd if=/dev/sdl of=/dev/null
195728+0 records in
195728+0 records out
Dd worked fine, but I was still unable to create a file system with the VI client or vmkfstools:
$ vmkfstools -C vmfs3 /vmfs/devices/disks/vmhba1:0:0:9
Error: Bad file descriptor
To get a better idea of the disk device layout. I decided to run fdisk to list the label type and layout of each device:
$ fdisk -l
< ..... >
Disk /dev/sdl (Sun disk label): 256 heads, 10 sectors, 40958 cylinders
Units = cylinders of 2560 512 bytes
Device Flag Start End Blocks Id System
/dev/sdl3 u 0 40958 52426240 5 Whole disk
/dev/sdl4 u 0 1 1280 f Unknown
/dev/sdl5 u 2 40958 52423680 e Unknown
Hmmm – each Clariion device contained an SMI label, and I started to wonder if this was causing the problem. To test my hypothesis, I used the fdisk utility to write a DOS label to one of the problematic devices:
$ fdisk /dev/sdl
Command (m for help): o
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.
The number of cylinders for this disk is set to 40958.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
Once I labeled the device with a DOS label, vmkfstools and the VI client allowed me to initialize and use the device. I am not certain why ESX server was having an issue with the SMI label, but writing a DOS label looks to have fixed my problem.
My Dell C400 runs Windows XP, and it was taking 5 - 10 minutes to boot. This wasn’t always the case, so I started poking around to see which services where being enabled during startup. Windows maintains two registry keys for startup items, as well as the old trusty “Startup” folder in the start menu. Here are the keys you can check to see which services will start when Windows XP initializes:
Registry key #1 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Registry key #2 HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
My problem turned out to be with VMWare server, and removing it made my machine boot quickly again. Nice!
I found a couple of interesting ZFS links this week:
ZFS best practices: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide
ZFS tuning: http://www.princeton.edu/~unix/Solaris/troubleshoot/zfs.html