My take on Android vs. iPhone

After months and months of research, I finally broke down a few weeks ago and purchased a smart phone. When I first decided to replace my aging Motorola RAZR, I wanted something that didn’t cost a fortune and provided a basic ‘net experience when i was away from my Mac. After playing around with a number of phones, I narrowed my choices down to the Apple iPhone, the Motorola DROID and the Sprint EVO. I went back and forth for weeks, but decided to purchase a Sprint EVO for a couple of reasons:

1. Sprint has the most cost effective plans IMHO. I’m currently paying around $60/mo for unlimited texts, unlimited data and unlimited calls to mobile phones. Comparable iPhone plans would have run me well over $100/mo.

2. The Android, like the iPhone has numerous awesome applications in the application market.

3. Sprint has 4G coverage where I live, and I’m currently getting over 10MB/s of throughput. Nice!

4. I’m not too keen on having to visit Apple when I want to replace my battery.

5. The Sprint EVO allows you to swap out microsd cards at will. This is awesome since microsd card capacities will grow over time.

So far I have been extremely happy with my purchase, though all of the complaints about EVO battery life are spot on (mine lasts for 4 hours with continuous use). I have to keep a charger at home, one in my car and another at my desk. This is kinda annoying, but I’m hopeful Sprint will issue an update to address this limitation. Battery issues aside, you really can’t go wrong with the Sprint EVO. Great phone!

Forcing your Linux users to wait after they input an incorrect password

When I run through my security checklist after building a host, one of the first things I change is the login fail delay. This option allows you to force a user to wait a given number of microseconds after a login failure before being able to try another password. For applications that perform brute force attacks this can be extremely handy, since the application performing the brute force attacks will stall in between unsuccessful passwords, hopefully allowing you to catch them in the act through log event notifications (this of course assumes the password attack occurs serially).

To configure a login delay on a CentOS or RHEL server, you can do one of two things. You can add the FAIL_DELAY variable to /etc/login.defs:

$ grep FAIL_DELAY /etc/login.defs
FAIL_DELAY 10000000

or you can add to /etc/pam.d/system-auth configuration file:

auth optional delay=10000000 <---- add this auth required auth sufficient nullok try_first_pass auth requisite uid >= 500 quiet
auth required

Once one of these two items is in place, you will now be required to wait for FAIL_DELAY microseconds prior to being able to enter another password. This is a handy option, and one that should be implemented on every Linux server!

Implementing a home security alarm on the cheap

I currently live in an apartment, and was looking for a cheap and easy solution to sound off an alert if a door or window was opened. Most home security systems are really tailored for houses, and I wasn’t real found of paying $30 – $40 per month to monitor a relatively secure apartment. After reading a BUNCH of reviews, I came across the First Alert alarm sets. I have now been testing these out for a few weeks, and am extremely happy with them!. Here are the pros:

1. First alert sets are dirt cheap (you can find used / new sets on eBay for next to nothing)

2. They run on three LR44 batteries, which you can find dirt cheap on eBay

3. Each device has an off switch, so you can enable / disable them with a flip of the switch

These devices are no replacement for a home security system, but rather a nice addition to them. If you are looking for a cheap way to get notified when a window or door is opened, you should check these out!

Using to control when people can log into your servers

Most admins have to support system logins in one form or another. These logins include everything from application service accounts, operations accounts, SysAdmin accounts and pretty much everything else you can think of. Some of these accounts may not need to access your servers 24/7, and you may want to limit the timeframes when users or groups of users can login. This is super easy to do on Linux systems with the pam_time module.

Pam_time is pretty simple. To configure it to allow logins during a specified time period, you can edit /etc/security/time.conf and add entries to limit access. Entries in this file take the following format:


The pam service name contains the name of the pam service to disallow access to, the ttys field controls the devices to limit access to, the user list contains the users to deny access to, and the time field controls allows you to list the times when a user can login. Here is an sample entry:


In the example above, the users haroldp and kumarj would only be able to login via ssh between the hours of 9am and 5pm. To enforce the limits in the time.conf configuration file, you will need to add the module to the account section in your pam configuration. For a CentOS server, you can append the pam_time entry to the top of the account section in /etc/pam.d/system-auth:

account required <--- New entry
account required
account sufficient uid < 500 quiet account required If a user tries to login outside of the hours listed in the fourht field above, they will be denied access. One important note regarding the time field. This field contains the times you WANT to grant access. To deny access during a time range you will need to append a bang (!) to the time. This module gives a whole new flare to the phrase “ACCESS DENIED!”. :)

ipmitool + LOM = rad amounts of hardware data collection.

There are so many different hardware sensors on machines now. If you have a machine with a iLOM (like Sun’s line of x86 hardware) you can probe all of this information over the network using ipmitool and direct it at the iLOM.

Usage for ipmitool over the network:

$ ipmitool -I lan -H (ip address of your lom) -U (username on lom) (command)

Typically Sun iLOMs use either "root" or "admin" as the username.   Adjust to your hardware / environment.  Note, ipmitool does send traffic across the wire in clear text.  It isn't encrypting a password, so keep that in mind.

Reporting on if there are any active fault LEDs on the box. (sunoem is of course, just for Sun gear)

$ ipmitool -I lan -H lomipddy -U root sunoem sbled get
LOCATE           | OFF
OK               | ON
SERVICE          | ON
FAN_FAULT        | OFF
PS_FAULT         | ON
MB/P0/D0/SVC     | OFF
MB/P0/D1/SVC     | OFF
MB/P0/D2/SVC     | OFF
MB/P0/D3/SVC     | OFF

Reporting what components make up the machine (FRU = field replaceable units)

$ ipmitool -I lan -H ilomipaddy -U root fru
FRU Device Description : Builtin FRU Device (ID 0)
 Product Manufacturer  : ASPEED
 Product Name          : BMC CONTROLLER

FRU Device Description : /SYS (ID 27)
 Chassis Type          : Rack Mount Chassis
 Chassis Part Number   : 541-1982-06
 Board Part Number     : 511-1394-02
 Board Extra           : 50
 Board Extra           : DT_MB
 Product Manufacturer  : SUN MICROSYSTEMS
 Product Name          : SUN FIRE X4140  
 Product Part Number   : 4534567-4

FRU Device Description : MB/P0/D4 (ID 12)
 Product Manufacturer  : Micron Technology
 Product Name          : 4096MB DDR-II 666
 Product Part Number   : 36HTF51272PY-667E1
 Product Version       : 0100
 Product Serial        : D93D8C07

FRU Device Description : MB/P1 (ID 7)
 Product Manufacturer  : AMD
 Product Name          : Six-Core AMD Opteron(tm) Processor 2435
 Product Part Number   : 1008
 Product Version       : 00

iLOM event logs of what happened to the machine in the past

$ ipmitool -I lan -H ilomipaddy -U root sel elist
   1 | 12/24/2009 | 02:49:24 | Power Supply PS1/PWROK | State Deasserted
   2 | 06/05/2010 | 07:49:00 | System ACPI Power State ACPI | S0/G0: working | Asserted
   3 | 06/05/2010 | 07:49:03 | Power Supply PS1/PWROK | State Deasserted
   4 | 06/05/2010 | 07:49:04 | Power Supply PS1/VINOK | State Deasserted
   5 | 06/05/2010 | 07:55:14 | Power Supply PS1/PWROK | State Asserted
   6 | 06/05/2010 | 07:55:16 | Power Supply PS1/VINOK | State Asserted
   7 | 06/05/2010 | 08:09:04 | Power Supply PS0/PWROK | State Deasserted
   8 | 06/05/2010 | 08:09:06 | Power Supply PS0/VINOK | State Deasserted
   9 | 06/05/2010 | 08:09:10 | Power Supply PS0/PWROK | State Asserted
   a | 06/05/2010 | 12:23:46 | System ACPI Power State ACPI | S0/G0: working | Asserted
   b | 06/05/2010 | 12:23:51 | Power Supply PS0/VINOK | State Deasserted

And of course, current voltage / temperature / RPMs of fans, etc.

$ ipmitool -I lan -H ipaddyoflom -U root sdr elist
ACPI             | EAh | lnc |  7.0 | 0 unspecified
INTSW            | EBh | ok  | 23.0 | 
MB/P0/PRSNT      | 01h | ok  |  3.0 | Device Present
MB/P1/PRSNT      | 02h | ok  |  3.1 | Device Present
MB/P0/T_CORE     | 09h | ok  |  3.0 | 7 degrees C
MB/P1/T_CORE     | 0Ah | ok  |  3.1 | 18 degrees C
MB/P0/V_VDDCORE  | 05h | lnr |  3.0 | 0 Volts
MB/P1/V_VDDCORE  | 06h | ok  |  3.1 | 1.03 Volts
MB/P0/V_+0V9     | 0Dh | ok  |  3.0 | 0.90 Volts
MB/P1/V_+0V9     | 0Eh | ok  |  3.1 | 0.90 Volts
MB/P0/V_+1V8     | 11h | ok  |  3.0 | 1.80 Volts
MB/P1/V_+1V8     | 12h | ok  |  3.1 | 1.79 Volts
MB/P0/V_VDDNB    | 15h | lnr |  3.0 | 0 Volts
MB/P1/V_VDDNB    | 16h | ok  |  3.1 | 1.31 Volts
MB/P0/PROCHOT    | 19h | lnc |  3.0 | 0 unspecified
MB/P1/PROCHOT    | 1Ah | lnc |  3.1 | 0 unspecified
MB/T_AMB         | 32h | ok  |  7.0 | 29 degrees C
MB/V_+12V        | 1Eh | ok  |  7.0 | 12.10 Volts
MB/V_+1V2HT      | 26h | ok  |  7.0 | 1.22 Volts
MB/V_+1V5        | 20h | ok  | 10.0 | 1.50 Volts

Note, since we are hitting a iLOM here to query this information using ipmitool, we're not directly interacting with a machine. In all the examples above, the actual server was powered off. Some cool stuff!

Also, all of these ipmitool commands can also be ran locally from the O/S. Instead of using -I Lan to communicate over the network, you'll want to use -I BMC (if you leave it out, it defaults to this) so the O/S knows to communicate with its own LOM.

Sweet! Only thing left is to gather this data and graph it into Zenoss or throw alerts in Nagios based off of poor values. =)

Note, that ipmitool gathering data is only as useful as the hardware it probes that support it. Various SPARC / x64 machines may return other values. Dell / HP gear may also report on things differently, so check out your vendor's LOM's ability to use ipmitool. You can download the source for ipmitool here.