BVLog Bryan Voss’ mental synchronization point

Linux force password change

I needed to have a user change their password on their next login, so I had to look up how to do that. Since I had to do a little more searching than usual to find an answer, I'm posting it here for posterity.

First, change the user's password to a temporary:
passwd [username]

Next, reset the password expiration to 90 days (-M) and set the last change date to 0 (-d) to force a change:
chage -M 90 -d 0 [username]

Finally, verify the info:
chage -l [username]

Linux process elapsed time

I'm working on a script to dump a daily audit log from one of our clinical systems. The script invokes Oracle's sqlplus and runs a query provided by the vendor to show all user activity in the past 24 hours. I started the query running with the expectation that it would take at most a few minutes to run. That was before lunch. It's now late afternoon and the script is still running.

The output file is slowly growing, so it's still working. I attached an strace to the process and see it mostly waiting in a read state, so I assume that we just need to optimize the indexes on the database to make it run faster. That's mostly outside my responsibility, but I did want to check to see how long the process had been running in order to make a preliminary report to my coworkers. Digging around in the /proc directory for the process didn't immediately show me what I wanted to know, so I turned to the "ps" command. I had to do some reading, but ended up with the following:
ps -o etime,stime,time,cmd -C sqlplus

This gave me what I was looking for: elapsed time, system time, wait time, and the command for all sqlplus processes.

Total elapsed time so far: 5 hours. Wow. That's quite a while for a single query.

ssh login via shared key

Since I only need to set this up the first time I get a new PC/server online, I figured I might as well document it here to make it easier to remember.

Very briefly, we're creating a new key with ssh-keygen. (Don't run this if you have an existing key you want to use). We're then copying the public portion of the key to [server]'s authorized_keys, which will allow us to login without a password from now on. Many assumptions are made here, so if you run into problems, google "ssh key login" for more info.

Use wisely.

ssh-keygen
cat ~/.ssh/id_rsa.pub | ssh [server] 'mkdir -p .ssh ; cat >> .ssh/authorized_keys'

More shell scripting

for file in Pyramis*.ps ; do name=`echo $file | cut -d'.' -f 1` ; ps2ascii $file > $name.txt ; done

Converting a bunch of Postscript files to ASCII text files. Posted here for my future reference. (And anybody else that may happen to be interested.) It's a fairly basic example, but I tend to fumble around on these if I haven't done much shell scripting in a while.

We're iterating through the list of files named Pyramis*.ps . The filename ($file) is passed through cut to chop off the extension (.ps) and the resulting name is assigned to the $name variable. We then run the original filename ($file) through ps2ascii to do the actual conversion and write the output to $name with a .txt extension. We end up with a bunch of files with the same name as the original Postscript file, but with a .txt extension.

Groovy.

Why commandline is important

Some interesting BASHing I did today:

find . -type f -print | cut -d'/' -f 2 | uniq | sort > content
for files in *; do echo $files; done | sort | grep -v content | grep -v -f content | xargs -n 1 rm -rf

The first line finds all subdirectories of the current directory that contain files and prints the list to the file contents. The second line deletes all the subdirectories that are not contained in the file content.

I had to do this to clean up a huge number of orphaned batch directories left by our document imaging system (Windows, but I'm running Cygwin and pointing to a drive mapped to the DI fileserver). The vendor provides a GUI app to do this, but it takes the larger part of eternity to map out all the directories, then you have to click on each directory and click delete. Pretty useless for the thousands of directories I had to deal with. My commandline solution took about 5 minutes to work out and around 15 seconds to run. Several hours of menial mouse clicking saved.

I had to shut down a release process in order to make sure I didn't catch any legitimate directories that had been created but not yet populated. The next iteration will probably include a bit more logic to only include directories that are more than a day old or so. A simple -mtime tweak to the find command should do it. That will enable me to run it while the entire system is live.

grep for yesterday’s syslog entries

I was asked by a coworker how to grep syslog files for entries from the past 24 hours. Although it is simple to do manually, I thought it might be nice to put together a simple script to do the work for her. Here's what I came up with:

#/bin/sh
# bvoss 2008/05/08 grep for yesterday's date in any syslog-formatted file
# (May 7)
yesterday="`date -d "-24 hours" | cut -b 5-10`"
grep "$yesterday" $1

Just put it somewhere in the path (/usr/local/bin works nicely) and "chmod +x" to make it executable. Works on any syslog-formatted file with month and day at the beginning of each line. Syntax is grep_yesterday [file]. It returns all entries from midnight until 23:59:59 yesterday.

Remote CD eject

Ok, I'm probably being a n00b, but I think it's just plain cool to sit down at a PC and ssh into a server, type "eject /dev/cdrom", and see the CD tray pop out on the server across the room.

Maybe I'm just easily entertained.

Redundancy? We don’t need no stinkin’ redundancy!

We recently experienced a hard drive failure on one of our critical Linux servers. The server stopped responding on a weekend, of course. (Why do failures inevitably occur outside the hours that I'm normally in the office?) Since the server has two drives and was staged by the application vendor, I just assumed it was set up with a RAID1 mirror and at worst I would have to remove the failed drive and reboot to get it back up and running in degraded state. It turns out the drives were set up as a RAID0 volume with no redundancy. When the single drive failed, it took the whole volume down.

I was eventually able to get the drive back online by reseating it and resetting the RAID adapter. I called vendor support to ask why the volume was set up with no redundancy and the answer was, "Our staging group doesn't configure servers that way. We always set them up with redundant RAID volumes."

"Well, thanks for the info, but I have a server here with a RAID0 volume that was provided by your staging group," I said.

"Sorry, there must be some mistake. See, we don't set servers up that way."

"(Sigh) Ok, thanks for your time." Weekend support was obviously not going to be any help.

I went through all the other servers that were a part of that system and were staged at the same time. All but one were configured as RAID0. We had received three additional severs that were staged later. They were configured with RAID1 redundancy, rather than RAID0.

We called our vendor rep Monday morning, and explained that the industry standard is to set your RAID volumes up with redundancy since hard drives tend to fail on occasion. He initiated an investigation into the problem and eventually admitted that there was a period of time that all Linux servers they shipped were configured as RAID0 rather than RAID1, but that the issue had been resolved. (The guy in their staging group who was setting them up that way was probably promoted to a manager or something, and the new guy knew more about industry standards.)

We asked them to provide us with a plan on transitioning to RAID1 on all the affected servers, but have not received a response yet. I suspect we will have to do it ourselves. Sigh. These vendors don't seem to have any contact with reality at times.