Before my wife and I had kids we thought it would be nice to collect the United States quarters that were released during 1999 through 2008 to commemorate each of the 50 states. Seemed like something simple to do and would be a nice gift for the kids when they got older. So we bought a couple of the blue books which you can fill up with quarters as you find them. Each book contains 100 slots, 2 for each state. One slot is for the Philadelphia minted version of the quarter, and the other slot is for the Denver mint.

Problem

Well we ended up having 3 kids so we have to collect 300 quarters. The task of finding the quarters has been more of a dad task so when I have a chance, I’ll put a $5 dollar bill in various soda machines at work and go quarter fishing. This approach has been working fairly well and we’ve collected ~130 of the 300 quarters thus far.

However I’ve started getting to the point where I’m netting a lot of duplicates and the job of having to bring them home to weed through them is starting to get old. Having a list of which quarters we already have would sure be nice, so I could quickly nix any duplicates.

Solution

Of course I wanted a low tech solution, i.e. a piece of paper in my wallet would do the job, but how to do it?

The answer? A text file that I could maintain would suffice. No need for a bloated spreadsheet or some fancy handheld app. So I created a file, quarters.txt, like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

State           Year  Cnt (P/D)
=====           ====  =========
Alabama         2003  2/1
Alaska          2008  3/1
Arizona         2008  3/0
Arkansas        2003  3/0
California      2005  3/0
Colorado        2006  3/0
Connecticut     1999  3/2
Delaware        1999  0/0
Florida         2004  2/0
Georgia         1999  2/1
Hawaii          2008  3/0
...

It’s about as simple a text file as you can get. 3 columns, State, Year, and Counts. The 3rd column shows how many P and D quarters I have for a given state. So for example, for Alabama, I’ve got 2 Philadelphia minted quarters, and 1 Denver minted.

So you’re probably wondering, “why the hell is this guy writing up this in a blog post?”

We’ll the interesting bit to this low tech solution is how I print this list out. For this task I make use of a pretty powerful UNIX command called enscript, which lets you do all kinds of nifty things to a text file to augment how it looks when it gets printed.

About the only thing enscript doesn’t do for you, is give you the ability to preview your text file prior to printing. To accomplish this bit, I made use of another powerful UNIX command called ps2pdf. This command will take a postscript file (ps) and convert it to a pdf file.

So putting all the pieces together I came up with the following command:

1

enscript --fancy-header -U 4 quarters.txt -o - | ps2pdf - quarters_sm.pdf

The first part of this command, will call enscript instructing it to convert the file quarters.txt, and print it to standard out -o -. The printout will include some fancy headers and enscript will print the text file out in what is called 4 UP. This means that 4 pages will be printed on a single piece of paper. You could also print the page out in 2 UP, 8 UP, etc. It only needs to be a power of 2. BTW, 2 and 4 are the most commonly used, 8 is pretty hard to read.

The second part of this command passes the postscript generated by enscript through a UNIX pipe which gets picked up by ps2pdf, and converts it into a PDF file, quarters_sm.pdf.

From here you can check what the page would look like using your favorite PDF viewer, such as evince or xpdf. Once you’re comfortable with the page you can actually print it out from the PDF reader, or via the command-line.

Here’s what the resulting PDF file looks like:

PDF file

Here’s a portion of the PDF file at a 150% of it’s original size:

screenshot of quarters_sm.pdf at 150%

Useful Links

• enscript printing guide

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.

From time to time I need to move and/or copy a subset of files from one directory to another. I typically would use something like one of these to do the task:

1
2
3
4
5

#-- COPY
find . -type f -ctime -1 | xargs -I {} cp {} /some/other/directory
 
#-- MOVE
find . -type f -ctime -1 | xargs -I {} mv {} /some/other/directory

NOTE: The 1st command finds all the files in the current directory that are less than 24 hours old, and copies them to /some/other/directory. The 2nd command finds all the files in the current directory that are less than 24 hours old, and moves them to /some/other/directory.

But then I realized that by using xargs’ –I switch I was basically limiting xargs to doing a single file at a time. According to xargs’ man page, when you use the –I switch you’re implying the –x switch AND the –L 1 switch. The L switch is what tells xargs how many lines of input to process at a time, so we’re basically telling it to only handle one file at a time. This made no sense. I was unintentially limiting xargs’ ability to optimize the command-line. So I found a better way.

New Approach

By utilizing 2 little used switches (–t | ––target-directory) on cp and mv I could un-tie xargs’ hands.

copy

1
2
3
4
5

# long form
find . -type f -ctime -1 | xargs -0 cp --target-directory=/some/other/directory
 
# short form
find . -type f -ctime -1 | xargs -0 cp -t /some/other/directory

move

1
2
3
4
5

# long form
find . -type f -ctime -1 | xargs -0 mv --target-directory=/some/other/directory
 
# short form
find . -type f -ctime -1 | xargs -0 mv -t /some/other/directory

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.

This one threw me for a bit but I finally realized that when I had Compiz enabled on an Ubuntu 9.04 system, I couldn’t use VNC to connect via Remote Desktop Sharing in GNOME (aka. Vino, aka. VNC Server). Apparently this has been an issue going back since 2007 8-(, when Compiz is enabled. Since this is the first system that I actually bothered to enable Compiz I’m dealing with it for the first time.

The problem shows up when you try and connect remotely to a system that has Remote Desktop Sharing enabled –AND– Compiz. This thread on launchpad was helpful in showing the lineage of the problem, and the only real workaround to get Remote Desktop Sharing to work.

Solution

The workaround? If you’re coming at it remotely, and are too lazy to walk over to the remote system … ssh into the remote system and run these commands to effectively disable Compiz, and enable (re-enable?) the window manager Metacity.

1
2
3

ssh <remote system>
export DISPLAY=:0
nohup metacity --replace > /dev/null &

NOTE: I’m wrapping a “nohup … > /dev/null &” around the “metacity –replace” so that when/if I close the ssh connection, the metacity running in there doesn’t get inexplicably killed off. Additionally, this version of nohup (/usr/bin/nohup), likes to leave a nohup.out file lying around, which is just cruft in our case, so by sending all the output to /dev/null we are effectively disabling the creation of the nohup.out file.

Now you can do your work remotely with Compiz turned off. But now what to do when you’re all done and you want to turn Compiz back on? Easy. Do this:

1
2
3

ssh <remote system>
export DISPLAY=:0
nohup compiz --replace > /dev/null &

Useful Links

• launchpad bug #77442: compiz / vnc screen updates with nVidia restricted
• forum thread on how to restart compiz

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.

Recently at my day job I’ve been having to go through some pretty old Bash scripts that I’ve basically inherited. As I’ve been going through them I’ve been seeing a lot of confusion as to the proper use of Bash’s export command. The major offense? Not really understand whether a particular variables needs to be exported, or not. So I thought I’d take a moment just to clarify when and when not to use export.

The export command has really only one true purpose. To mark and/or unmark variables (and functions) that you want to have automatically exported to environments of subsequently executed commands. So if you create a script that calls other commands, and you want to push variables into the environment of these commands, then you’ll want to use export.

Example #1 (without export)

For example, let’s say we have the following 2 scripts:

1
2
3
4
5
6
7

#!/bin/bash
# script #1: parent.bash
 
var1="this was set by the parent shell script"
echo "inside $0 script: $var1"
 
./child.bash

1
2
3
4

#!/bin/bash
# script #2: child.bash
 
echo "inside $0 script: $var1"

And when I run the script parent.bash I get this output:

1
2
3
4
5

# output from parent.bash & child.bash (without export)
 
% ./parent.bash
inside ./parent.bash script: this was set by the parent shell script
inside ./child.bash script:

Notice how the variable $var1, which was set in the parent.bash script, didn’t get displayed by the child.bash script? Now watch this example with the variable $var1 exported in the parent.bash script.

Example #2 (with export)

1
2
3
4
5
6
7

#!/bin/bash
# script #1: parent.bash
 
export var1="this was set by the parent shell script"
echo "inside $0 script: $var1"
 
./child.bash

1
2
3
4

#!/bin/bash
# script #2: child.bash
 
echo "inside $0 script: $var1"

And when we run parent.bash

1
2
3
4
5

# output from parent.bash & child.bash (with export)
 
% ./parent.bash
inside ./parent.bash script: this was set my the parent shell script
inside ./child.bash script: this was set my the parent shell script

Example #3 (un-exporting)

Export isn’t just a one trick pony. It can also unmark a previously exported variable.

1
2
3
4
5
6
7
8
9

#!/bin/bash
# script #1: parent.bash
 
export var1="this was set by the parent shell script"
echo "inside $0 script: $var1"
 
./child.bash
export -n var1
./child.bash

1
2
3
4

#!/bin/bash
# script #2: child.bash
 
echo "inside $0 script: $var1"

1
2
3
4
5
6

# output from parent.bash & child.bash (with a before/after export)
 
% ./parent.bash
inside ./parent.bash script: this was set by the parent shell script
inside ./child.bash script: this was set by the parent shell script
inside ./child.bash script:

Here we see the effects of the export -n on child.bash the 2nd time it’s called.

Which Variables are Flagged for Export?

You can use the command export -p to get a list of all the variables marked for export, like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

% export -p
declare -x CCACHE_DIR="/var/cache/ccache"
declare -x CCACHE_UMASK="002"
declare -x COLORTERM="gnome-terminal"
declare -x CVS_RSH="ssh"
declare -x DESKTOP_SESSION="gnome"
declare -x DISPLAY=":0.0"
...
...
declare -x SHELL="/bin/bash"
declare -x SHLVL="4"
declare -x TERM="xterm"
declare -x USER="root"
declare -x WINDOWID="77021004"
declare -x XMODIFIERS="@im=imsettings"
declare -x var1="this was set by the parent shell script"

What else?

There is one additional trick related to exporting variables, but it doesn’t make use of the export command. It uses Bash’s set command. This command allows you to automatically export ALL the variables that have been modified or created to the environment of subsequent commands.

Here’s a quick example:

1
2
3
4
5
6
7
8
9
10
11
12

#!/bin/bash
# script #1: parent.bash
 
# automatically export EVERYTHING
set -a
 
var1="this was set by the parent shell script"
var2="this was set by the parent shell too"
echo "inside $0 script: $var1"
echo "inside $0 script: $var2"
 
./child.bash

1
2
3
4
5

#!/bin/bash
# script #2: child.bash
 
echo "inside $0 script: $var1"
echo "inside $0 script: $var2"

Useful links

• Daniel Robbin’s 3 part Bash tutorial
• Bash Reference Manual

A while back I was trying to get the vim textile plugin installed and ran into a problem. Apparently the vim that’s included with Fedora 10, 11, and CentOS 5 doesn’t include ruby support. This bug report explains what’s wrong with vim and how it’s missing ruby support. The problem is visible with this command:

1
2
3
4

% vim --version | grep ruby
+printer +profile +python +quickfix +reltime +rightleft -ruby +scrollbind 
...
...

The –ruby tells us that ruby support isn’t enabled. The only solution I’ve seen thus far is to rebuild vim. Not really a huge deal but it’s work non the less 8-).

Rebuilding vim with ruby support

Here’s how I fixed it.

download vim Source RPM (SRPM)

1

% wget http://mirrors.xmission.com/fedora/updates/10/SRPMS/vim-7.2.148-1.fc10.src.rpm

confirm that ruby is installed

1
2
3
4
5
6

% yum list installed ruby*|column -t|grep ruby
ruby.i386        1.8.6.287-2.fc10  installed
ruby-devel.i386  1.8.6.287-2.fc10  installed
ruby-irb.i386    1.8.6.287-2.fc10  installed
ruby-libs.i386   1.8.6.287-2.fc10  installed
ruby-rdoc.i386   1.8.6.287-2.fc10  installed

make sure you have your own rpmbuild directory

1
2
3
4

% mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
 
# caution with this second command if you already have your own .rpmmacros, this will overwrite!
% echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros

rebuild vim / re-install vim

1
2

rpmbuild --rebuild vim-7.2.148-1.fc10.src.rpm
rpm --force -Uvh /root/rpmbuild/RPMS/i386/vim-{c,e,m,X}*

check that vim now has ruby support

1
2
3
4

% vim --version | grep ruby
+printer +profile +python +quickfix +reltime +rightleft +ruby +scrollbind 
...
...

Ahh. a +ruby means it worked.

Textile Plugin for vim

Now onto installing the vim textile plugin.

First things first, we need to install rubygems

1

% yum install rubygems

Next we need to install the RedCloth gem, it’s required by the textile plugin

1
2
3
4
5
6

% gem install RedCloth
Building native extensions.  This could take a while...
Successfully installed RedCloth-4.2.2
1 gem installed
Installing ri documentation for RedCloth-4.2.2...
Installing RDoc documentation for RedCloth-4.2.2...

Finally, install the textile plugin

Downloading the textile plugin from here,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# unpack the zip
% unzip textile-0.3.zip
   creating: textile/
   creating: textile/doc/
  inflating: textile/doc/textile.txt  
   creating: textile/ftplugin/
  inflating: textile/ftplugin/textile.vim  
   creating: textile/plugin/
  inflating: textile/plugin/textile.vim  
   creating: textile/syntax/
  inflating: textile/syntax/textile.vim  
 
# cd into the textile dir
% cd textile
 
% tree .
.
|-- doc
|   `-- textile.txt
|-- ftplugin
|   `-- textile.vim
|-- plugin
|   `-- textile.vim
`-- syntax
    `-- textile.vim
 
4 directories, 4 files
 
# install the plugin
% cp -r * ~/.vim/

screenshot of textile plugin in action

vim's textile plugin

For my second attempt, I opted to do each VE independently, to get a better understanding of what the best approach would be for doing mass upgrades like this now, and in the future. The first hurdle to overcome had to do with some of the VEs running out of memory (RAM) during the upgrade process.

NOTE: A VE = Virtual Environment (aka. a virtual host), while HN = Host Node

Issue #1, not enough RAM for yum to run

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# RAM budgets for VEs
 
# NOTE: values are in # of pages (1 pg. = 4K)
 
% (printf "vm feature held maxheld barrier limit failcnt\n"; grep privvm /proc/bc/1*/resources)|column -t
vm                       feature      held    maxheld  barrier  limit   failcnt
/proc/bc/101/resources:  privvmpages  31904   82215    65536    69632   2
/proc/bc/102/resources:  privvmpages  119803  196620   166400   179200  9517
/proc/bc/103/resources:  privvmpages  27125   35974    65536    69632   0
/proc/bc/104/resources:  privvmpages  56251   107250   104960   115200  0
/proc/bc/105/resources:  privvmpages  73559   82926    98304    103304  0
/proc/bc/106/resources:  privvmpages  30219   68097    65536    69632   0
/proc/bc/108/resources:  privvmpages  30081   84291    65536    69632   1
/proc/bc/109/resources:  privvmpages  32790   74199    98304    103304  0
/proc/bc/110/resources:  privvmpages  40497   69408    65536    69632   1
/proc/bc/111/resources:  privvmpages  26990   35371    65536    67840   0
 
# NOTE: converted the columns to megabytes (MB), it's just easier to read
 
(printf "vm feature held maxheld barrier limit failcnt\n"; grep privvm /proc/bc/1*/resources|awk '{sub($3,$3*4096/2^20) sub($4,$4*4096/2^20) sub($5,$5*4096/2^20) sub($6,$6*4096/2^20)}1')|column -t
vm                       feature      held     maxheld  barrier  limit    failcnt
/proc/bc/101/resources:  privvmpages  124.625  321.152  256      272      2
/proc/bc/102/resources:  privvmpages  467.98   768.047  650      700      9517
/proc/bc/103/resources:  privvmpages  105.957  140.523  256      272      0
/proc/bc/104/resources:  privvmpages  219.73   418.945  410      450      0
/proc/bc/105/resources:  privvmpages  287.34   323.93   384      403.531  0
/proc/bc/106/resources:  privvmpages  118.043  266.004  256      272      0
/proc/bc/108/resources:  privvmpages  117.504  329.262  256      272      1
/proc/bc/109/resources:  privvmpages  128.086  289.84   384      403.531  0
/proc/bc/110/resources:  privvmpages  158.191  271.125  256      272      1
/proc/bc/111/resources:  privvmpages  105.43   138.168  256      265      0

According to this data 4 of the 11 images had gone over their allocation of RAM. So I tried restarting these and re-running yum update within the problem VEs. Again the update failed and so I needed to increase their allocation of memory. I didn’t want to devote more memory permanently, just a enough temporarily to do the upgrade. So I used this trick to temporarily bump up a VEs allocated memory.

1
2
3
4
5
6
7
8
9

# increase the RAM by 100MB
vzctl set 101 --privvmpages $((256+100))m:$((272+100))m --save
 
# ...
# do the upgrade (yum update)
# ...
 
# decrease the RAM back to the original value
vzctl set 101 --privvmpages 256m:272m --save

For the remaining 3 VEs that needed additional memory I used these commands to increase their allocations of RAM

1
2
3
4
5
6
7
8
9

# cmds. to increase RAM by 100MB
vzctl set 102 --privvmpages $((650+100))m:$((700+100))m --save
vzctl set 108 --privvmpages $((256+100))m:$((272+100))m --save
vzctl set 110 --privvmpages $((256+100))m:$((272+100))m --save
 
# cmds. to decrease
vzctl set 102 --privvmpages 650m:700m --save
vzctl set 108 --privvmpages 256m:272m --save
vzctl set 110 --privvmpages 256m:272m --save

Issue #2, not enough diskspace for yum to run

The next snag I ran into had to do with a couple of the VEs running out of diskspace. And here’s the commands I used to reconfigure more diskspace.

1
2
3
4

# reconfigure with 2GB of diskspace
vzctl set 101 --diskspace 2048M:2252M --save
vzctl set 102 --diskspace 2048M:2252M --save
vzctl set 103 --diskspace 2048M:2252M --save

At this point I was able to yum update all my images, and work through any packages that had been updated.

Issue #3, unfinished yum transactions

One final snag that I didn’t really pick up on until probably the 2nd or 3rd time I went through this “process” was that some of the VEs would report during yum update that there were incomplete transactions, and that I really should run the yum-complete-transaction command. I’d never heard of this command, so I went looking and apparently if yum fails to complete a transaction, it remains queued up, causing you to get warnings during subsequent yum updates. So to get yum-complete-transaction command you need to install a package called yum-utils.

1

yum install yum-utils

Then you’ll want to run yum-complete-transaction. Pay special attention to how many unfinished transactions this command finds. Multiple yum transactions can get queued up so you may need to run yum-complete-transaction multiple times. If you do need to run it more than once, it runs the last unfinished transaction first, and then the 2nd to last, and so on until they’re all completed. Don’t be alarmed if it says it’s removing what appear to be critical packages such as bash. This occured on several of my systems and it turned out that there was multiple bashes installed (at least according to the RPM database) and the unfinished transaction was merely trying to uninstall the previous version, leaving the latest version intact.

A bonus to running yum-complete-transaction, is that it helps reduce the memory footprint that yum needs when it has unfinished transactions vs. when it doesn’t. I was seeing yum using 50-100MB in some cases due to all the unfinished transactions, so fixing this issue helped with minimizing future problems that I may see related to issue #1, not enough RAM.

Final Thoughts

My original plan was that I would create a single OpenVZ image that included everything that I needed as far as packages go, and then selectively turn on and off apps that I didn’t need, like apache, for example. Going forward I’m going to try a completely different approach, and thin out each image to only include the bare minimum, to perform it’s job, i.e. mail server, samba server, etc. This should help out with a lot of redundant updating to all the VEs with packages that only 1 or 2 will actually need. The downside with this approach, and reason I avoided it to begin with, was that it seemed to be more work in maintaining many different images, but in practice this may not be as bad as having a single monolithic image multiplied many times across many VEs.

OpenVZ is still a tremendous tool here. Many times when I ran into a problem, I simply restored an image from backup and then resumed, so this isn’t a slam on it, and more a workflow issue and what’s the best way to manage many instances of machines. Really what I want is a way to manage roles of machines. Perhaps it’s time to revisit using something like puppet?

I recently saw a post over on Linux Journal that discussed how to glean information about a system’s hard drive, such as its serial number, without having to actually open up the case and physically check it. So I thought I’d take the opportunity to write up a blog post with the specifics of how to do this under Fedora & CentOS, just so I’d have this info handy for future use.

BTW, I was able to accomplish this task several different ways, so this post will cover all the different ways that I could get this info.

Command #1: lshw

This is probably the best tool for getting at a system’s internals. First make sure it’s installed.

1

yum install lshw

For our example you would run the command lshw -class disk:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

% lshw -class disk
  *-disk                  
       description: ATA Disk
       product: HTS726060M9AT00
       vendor: Hitachi
       physical id: 0
       bus info: scsi@0:0.0.0
       logical name: /dev/sda
       version: MH4O
       serial: MRH403M4GS551Y
       size: 55GiB (60GB)
       capabilities: partitioned partitioned:dos
       configuration: ansiversion=5 signature=cccdcccd
  *-cdrom
       description: DVD reader
       product: UJDA755yDVD/CDRW
       vendor: MATSHITA
       physical id: 1
       bus info: scsi@1:0.0.0
       logical name: /dev/cdrom
       logical name: /dev/cdrw
       logical name: /dev/dvd
       logical name: /dev/scd0
       logical name: /dev/sr0
       version: 1.71
       capabilities: removable audio cd-r cd-rw dvd
       configuration: ansiversion=5 status=nodisc

The first section that’s returned is called -disk. Here’s you’ll see the vendor: Hitachi, the product number, HTS726060M9AT00, and my serial number: MRH403M4GS551Y.

Command #2: smartctl

The next tool that would give this type of info is called smartctl. It’s a tool that’s part of the smartmontool package. You may be familiar with the acronym S.M.A.R.T.. The acronym stands for: Self-Monitoring, Analysis, and Reporting Technology. This is a standard that most modern disks have in which vital statistics about a disk drive are provided through a standard API. Here’s how to install it.

1

yum install smartmontools

…and once installed you can use the bundled in tool smartctl like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# smartctl example
 
% smartctl -i /dev/sda
smartctl version 5.38 [i386-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
 
=== START OF INFORMATION SECTION ===
Model Family:     Hitachi Travelstar 7K60
Device Model:     HTS726060M9AT00
Serial Number:    MRH403M4GS551Y
Firmware Version: MH4OA6BA
User Capacity:    60,011,642,880 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   6
ATA Standard is:  ATA/ATAPI-6 T13 1410D revision 3a
Local Time is:    Mon Sep 21 00:03:50 2009 EDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Command #3: hdparm

Another way that I’ve used to get at hard drive meta data is with the command hdparm. This is probably the oldest way, at least that I’m familiar with, for getting at hard drive meta data. To install it:

1

yum install hdparm

Using it is simply:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# hdparm example
 
% hdparm -i /dev/sda
 
/dev/sda:
 
 Model=HTS726060M9AT00                         , FwRev=MH4OA6BA, SerialNo=      MRH403M4GS551Y
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=7877kB, MaxMultSect=16, MultSect=?0?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=117210240
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
 AdvancedPM=yes: mode=0xC0 (192) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:  ATA/ATAPI-2,3,4,5,6
 
 * signifies the current active mode

Command #4: lsscsi

Here’s another tool, lsscsi, that I’ve used off and on to get at hard drive meta data. It’s probably the least known of all the tools mentioned here. Installation is the same as the others:

1

yum install lsscsi

It’s usage is pretty much in-line with the other commands too:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# lsscsi example
 
% lsscsi -lll -vvv
 sysfsroot: /sys
[0:0:0:0]    disk    ATA      HTS726060M9AT00  MH4O  /dev/sda
  device_blocked=0
  iocounterbits=32
  iodone_cnt=0x92983
  ioerr_cnt=0x4f
  iorequest_cnt=0x92983
  queue_depth=1
  queue_type=none
  scsi_level=6
  state=running
  timeout=60
  type=0
  dir: /sys/bus/scsi/devices/0:0:0:0  [/sys/devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0]
[1:0:0:0]    cd/dvd  MATSHITA UJDA755yDVD/CDRW 1.71  /dev/sr0
  device_blocked=0
  iocounterbits=32
  iodone_cnt=0xa0f7
  ioerr_cnt=0x0
  iorequest_cnt=0x283a7
  queue_depth=1
  queue_type=none
  scsi_level=6
  state=running
  timeout=0
  type=5
  dir: /sys/bus/scsi/devices/1:0:0:0  [/sys/devices/pci0000:00/0000:00:1f.1/host1/target1:0:0/1:0:0:0]

Command #4: /dev/disk/by-id directory

Finally you can get the manufacturer’s product number & serial number can be had by going directly to the /dev directory, specifically here: /dev/disk/by-id. In the resulting output you’ll see 2 important substrings. The first, HTS726060M9AT00, is he product number while the second, MRH403M4GS551Y, is the serial number.

1
2
3
4
5
6
7
8
9

# /dev/disk/by-id example
 
% ls -1 /dev/disk/by-id
ata-HTS726060M9AT00_MRH403M4GS551Y
ata-HTS726060M9AT00_MRH403M4GS551Y-part1
ata-HTS726060M9AT00_MRH403M4GS551Y-part2
scsi-SATA_HTS726060M9AT00_MRH403M4GS551Y
scsi-SATA_HTS726060M9AT00_MRH403M4GS551Y-part1
scsi-SATA_HTS726060M9AT00_MRH403M4GS551Y-part2

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.

I’m a vim guy through and through. Always have been. But I’m no zealot. I say you use the tool that does the job. So for example, I’ve used xemacs on occasion, and it definitely has its strengths. But for day to day I’ve always come back to using vim. So when I setup this blog, I knew early on that if I was going to post at any sort of meaningful frequency, I would have to figure out how to do it through vim. Additionally I’ve grown accustom to mark up languages such as markdown & textile, so I knew I’d want to mix this capability in to both my blog & vim, as well.

NOTE: refer to these Wikipedia pages if you’re unfamiliar with vim, xemacs, markdown or textile.

Preliminary Step

Before we get started, make sure that your blog is configured to accept XML-RPC. This is a remote procedure call mechanism that allows external tools to submit posts to your blog. The option is underneath the site admin section of Wordpress. You can get to the option under Settings –> Writing. The option looks like this:

XML-RPC Option

Getting Started

After googling a bit I came across a plugin for vim called Blogit. The main developers page for Blogit is here, while the primary vim.org plugin page is here. The latest version at the time of this article was 1.3. Installation couldn’t have been simpler.

Installation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# get into vim's dot directory
% cd ~/.vim
 
# download Blogit
% wget http://symlink.me/attachments/download/16/blogit-1.3.tar.bz2
 
# install blogit
% tar jxvf blogit-1.3.tar.bz2
 
# ~/.vim directory should look similar to this
% tree -A 
.
└── plugin
    ├── blogit.vim
    └── mock_vim.py
 
1 directory, 2 files

Configuration

The only other thing you need to do to setup the Blogit plugin is to create the following file: ~/.vim/plugin/passwords.vim. In it you’ll need to add 3 pieces of information about your blog. A username & password along with the URL to your blog’s xmlrpc.php file. Here’s an example:

1
2
3
4

" login credentials for blog
let blogit_username='user1'
let blogit_password='password1'
let blogit_url='http://www.lamolabs.org/blog/xmlrpc.php'

Blogit’s Interface

After firing up vim, you can get a list of all the Blogit commands with the vim command Blogit help, like so:

blogit help

You should get a split window in vim with the list of Blogit’s commands. BTW, most of these commands should be pretty self explanatory.

blogit commands

To get a list of all the posts available, run the command “Blogit ls”.

list posts command

Again you’ll be presented with a list of all your blog posts, in a split window inside of vim.

list of posts

You can use your arrow keys to move the cursor up and down through the list of posts. Additionally you can open posts up by placing the cursor on one, and pressing the enter key. In the example below, I’ve selected post#: 2362. Hitting return results in this particular post being opened up in vim’s primary window.

scrollable window

Here’s the results of post#: 2362 being opened.

view selected post

Running the command “Blogit ls” again brings up the list of all the existing posts.

scroll another post

Mark Up Languages

As I mentioned previously I’m a big fan of mark up languages such as markdown & textile. For no other reason, than I just prefer it, I chose to use Textile. To enable Textile support within Wordpress I installed the plugin Textile2. If you check out the Wordpress Plugins Directory there appears to be a number of suitable textile plugins. Even though this particular plugin hadn’t been updated for sometime it has worked flawlessly for 8+ months under the latest versions of Wordpress (i.e. 2.7 up to 2.8.4+).

Here’s a screenshot of Textile2’s configuration pane in Wordpress:

Textile2 Config

Also to close one final loop, I installed the Wordpress plugin WP markItUp!, on the off chance that I might actually use the web based editor for tweaking a post here or there. Installing this plugin basically switches the default Wordpress editor out for one that can handle an assortment of mark up languages, Textile being one of them. Here’s a screenshot of post#: 2362.

WP markItUp! Editor Example

Here’s how I configured the WP markItUp! plugin:

WP markItUp! Config

Conclusions

I’ve been using this setup for several months and it has just worked. I highly suggest you check it out if you maintain your own blog in Wordpress and you too prefer working in vim.

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.