Tue 31 Mar 2009
Tags: linux, tips
Note to self: here's how to get a quick overview of the hardware on a
linux box:
perl -F"\s*:\s*" -ane "chomp \$F[1];
print qq/\$F[1] / if \$F[0] =~ m/^(model name|cpu MHz)/;
print qq/\n/ if \$F[0] eq qq/\n/" /proc/cpuinfo
grep MemTotal /proc/meminfo
grep SwapTotal /proc/meminfo
fdisk -l /dev/[sh]d? 2>/dev/null | grep Disk
Particularly useful if you're auditing a bunch of machines (via an ssh
loop or clusterssh or something) and want a quick 5000-foot view of
what's there.
Thu 27 Mar 2008
Tags: perl, tips
I wasted 15 minutes the other day trying to remember how to do this,
so here it is for the future: to find out if and when a perl module
got added to the core, you want Richard Clamp's excellent
Module::CoreList.
Recent versions have a 'corelist' frontend command, so I typically
use that e.g.
$ corelist File::Basename
File::Basename was first released with perl 5
$ corelist warnings
warnings was first released with perl 5.006
$ corelist /^File::Spec/
File::Spec was first released with perl 5.00405
File::Spec::Cygwin was first released with perl 5.006002
File::Spec::Epoc was first released with perl 5.006001
File::Spec::Functions was first released with perl 5.00504
File::Spec::Mac was first released with perl 5.00405
File::Spec::OS2 was first released with perl 5.00405
File::Spec::Unix was first released with perl 5.00405
File::Spec::VMS was first released with perl 5.00405
File::Spec::Win32 was first released with perl 5.00405
$ corelist URI::Escape
URI::Escape was not in CORE (or so I think)
Mon 03 Mar 2008
Tags: tips, linux
Find goodness (with a recent-ish find for the '-delete'):
find -L . -type l
find -L . -type l -delete
Mon 22 Oct 2007
Tags: blosxom, tips
The blosxom SourceForge developers
have been foolish enough to give me a commit bit, so I've been doing
some work lately on better separating code and configuration, primarily
with a view to making blosxom easier to package.
One of the consequences of these changes is that it's now reasonably
easy to run multiple blosxom instances on the same host from a single
blosxom.cgi executable.
A typical cgi apache blosxom.conf might look something like this:
SetEnv BLOSXOM_CONFIG_DIR /etc/blosxom
Alias /blog /usr/share/blosxom/cgi
<Directory /usr/share/blosxom/cgi>
DirectoryIndex blosxom.cgi
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /blog/blosxom.cgi/$1 [L,QSA]
<FilesMatch "\.cgi$">
Options +ExecCGI
</FilesMatch>
</Directory>
The only slightly tricky thing here is the use of mod_rewrite to allow
the blosxom.cgi part to be omitted, so we can use URLs like:
http://www.example.com/blog/foo/bar
instead of:
http://www.example.com/blog/blosxom.cgi/foo/bar
That's nice, but completely optional.
The SetEnv BLOSXOM_CONFIG_DIR setting is the important bit for running
multiple instances - it allows you to specify a location blosxom should
look for all its configuration settings. If we can set this multiple
times to different paths we get multiple blosxom instances quite
straightforwardly.
With separate virtual hosts this is easy - just put the SetEnv
BLOSXOM_CONFIG_DIR inside your virtual host declaration and it gets
scoped properly and everything just works e.g.
<VirtualHost *:80>
ServerName bookmarks.example.com
DocumentRoot /usr/share/blosxom/cgi
AddHandler cgi-script .cgi
SetEnv BLOSXOM_CONFIG_DIR '/home/gavin/bloglets/bookmarks/config'
<Directory /usr/share/blosxom/cgi>
DirectoryIndex blosxom.cgi
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ /blosxom.cgi/$1 [L,QSA]
<FilesMatch "\.cgi$">
Options +ExecCGI
</FilesMatch>
</Directory>
</VirtualHost>
It's not quite that easy if you want two instances on same virtual host
e.g. /blog for your blog proper, and /bookmarks for your link blog. You
don't want the SetEnv to be global anymore, and you can't put it inside
the <Directory> section either since you can't repeat that with a single
directory.
One solution - the hack - would be to just make another copy your
blosxom.cgi somewhere else, and use that to give you two separate
directory sections.
The better solution, though, is to use an additional <Location>
section for each of your instances. The only extra wrinkle with this is
if you're using those optional rewrite rules, in which case you have to
duplicate and further qualify them as well, since the rewrite rule itself
is namespaced i.e.
Alias /blog /usr/share/blosxom/cgi
Alias /bookmarks /usr/share/blosxom/cgi
<Directory /usr/share/blosxom/cgi>
DirectoryIndex blosxom.cgi
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} ^/blog
RewriteRule ^(.*)$ /blog/blosxom.cgi/$1 [L,QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} ^/bookmarks
RewriteRule ^(.*)$ /bookmarks/blosxom.cgi/$1 [L,QSA]
<FilesMatch "\.cgi$">
Options +ExecCGI
</FilesMatch>
</Directory>
<Location /blog>
SetEnv BLOSXOM_CONFIG_DIR /home/gavin/blog/config
</Location>
<Location /bookmarks>
SetEnv BLOSXOM_CONFIG_DIR /home/gavin/bloglets/bookmarks/config
</Location>
Because one blosxom just ain't enough ...
Thu 30 Aug 2007
Tags: linux, hardware, tips
I was building a shiny new CentOS 5.0 server today with a very nice
3ware 9650SE raid card.
Problem #1: the RedHat anaconda installer kernel doesn't support these cards
yet, so no hard drives were detected.
If you are dealing with a clueful
Linux vendor like 3ware, though, you can just go to their comprehensive
download driver page,
grab the right driver you need for your kernel, drop the files onto a
floppy disk, and boot with a 'dd' (for 'driverdisk') kernel parameter
i.e. type 'linux dd' at your boot prompt.
Problem #2: no floppy disks! So the choices were: actually exit the office
and go and buy a floppy disk, or (since this was a kickstart anyway) figure
out how to build and use a network driver image. Hmmm ...
Turns out the dd kernel parameter supports networked images out of the box.
You just specify dd=http://..., dd=ftp://..., or dd=nfs://..., giving it
the path to your driver image. So the only missing piece was putting the
3ware drivers onto a suitable disk image. I ended up doing the following:
# Decide what name you'll give to your image e.g.
DRIVER=3ware-c5-x86_64
mkdir /tmp/$DRIVER
cd /tmp/$DRIVER
# download your driver from wherever and save as $DRIVER.zip (or whatever)
# e.g. wget -O $DRIVER.zip http://www.3ware.com/KB/article.aspx?id=15080
# though this doesn't work with 3ware, as you need to agree to their
# licence agreement
# unpack your archive (assume zip here)
mkdir files
unzip -d files $DRIVER.zip
# download a suitable base image from somewhere
wget -O $DRIVER.img \
http://ftp.usf.edu/pub/freedos/files/distributions/1.0/fdboot.img
# mount your dos image
mkdir mnt
sudo mount $DRIVER.img mnt -o loop,rw
sudo cp files/* mnt
ls mnt
sudo umount mnt
Then you can just copy your $DRIVER.img somewhere web- or ftp- or
nfs-accessible, and give it the appropriate url with your dd kernel
parameter e.g.
dd=http://web/pub/3ware/3ware-c5-x86_64.img
Alternatives: here's an
interesting post
about how to this with USB keys as well, but I didn't end up going that way.