From the Things I Learned During Winter Solstice Break department, I've been toying with generating my system reports in PDF. Normally, my reports are generated in ASCII text, but for some bizarre reason, there are some organizations that are wanting reports in PDF.
I ran into two problems. The first is that the native Linux tools will change text to PostScript, and PostScript to PDF, but not text to PDF. The second problem was that I could not get the PDF converter to accept piped input. This meant it would be a two step process.
ls -l /etc | enscript -o x.ps; ps2pdf x.ps x.pdf
The first pipe captures the text output, converts it to PostScript, then redirects it to a file. Next, the ps2pdf utility reads the PS file and converts it to PDF. It's actually pretty sharp.
I was showing this to some folks and explained my two step dilemma. The next day, one of them caught me in the hall and showed me how to get ps2pdf to accept piped input:
ls -l /etc | enscript -o - | ps2pdf - x.pdf
The second pipe has changed to output to "-". We now pipe to ps2pdf, and replace our input with "-". This has the effect of attaching the output of one to the input of the other. Sweet!
This generated a four page PDF (on my laptop-- YMMV). The next trick was to use mpage to get this onto a single sheet. As it turns out, mpage can do the ASCII to PS conversion:
ls -l /etc | mpage - | ps2pdf - x.pdf
We use the same dash trick to get it in one step. I felt like this needed one more option, to install a margin around each pane on the page:
ls -l /etc | mpage -M20 - | ps2pdf - x.pdf
Adding the "-M20" option to mpage, provided a clean, even margin on all sides of the output.
Wednesday, January 04, 2006
TILDWSB: LVM on Software Raid
From the Things I Learned During Winter Solstice Break department, it turns out that LVM on Raid is not as straight forward as it may seem. I had thought I would migrate one of my systems remotely, but decided it would be smarter to try it on a development box first. Lucky me for being prudent, as it did not work the first time.
The server had software raid running across two drives, containing /home. I wanted to get /var/spool/mail on the raid, also, and felt LVM seem a good solution. I realized it would be destructive, so I did a backup and moved it offsite. I then replicated the hardware configuration, and restored the backup onto the development server.
First, I issued pvcreate /dev/md0, which (as I expected) corrupted the ext3 filesystem. Second, I created the new volume group with vgcreate vg1 /dev/md0 (I already had a vg0). Third, I set up the new home filesystem with lvcreate -L +256M vg1 -n lv.home. Everything is still on track.
Since pvcreate had wiped out the ext3 filesystem, the lv.home had to be reformated. This required mke2fs -j /dev/vg1/lv.home. Oh no! An error!
mke2fs: bad fragment size - /dev/vg1/lv.home
Good thing this wasn't the production system. Unfortunately, this didn't seem to have any bearing on the actual command, as I had not specified an block sizes at all.
Turns out, there is a problem building an LVM on an existing raid. The solution was to dismantle the LVM, stop the raid, use fdisk to delete the partitions, then start over. This time, I did not format the raid. On the second attempt, the logical volume formatted without error.
The server had software raid running across two drives, containing /home. I wanted to get /var/spool/mail on the raid, also, and felt LVM seem a good solution. I realized it would be destructive, so I did a backup and moved it offsite. I then replicated the hardware configuration, and restored the backup onto the development server.
First, I issued pvcreate /dev/md0, which (as I expected) corrupted the ext3 filesystem. Second, I created the new volume group with vgcreate vg1 /dev/md0 (I already had a vg0). Third, I set up the new home filesystem with lvcreate -L +256M vg1 -n lv.home. Everything is still on track.
Since pvcreate had wiped out the ext3 filesystem, the lv.home had to be reformated. This required mke2fs -j /dev/vg1/lv.home. Oh no! An error!
mke2fs: bad fragment size - /dev/vg1/lv.home
Good thing this wasn't the production system. Unfortunately, this didn't seem to have any bearing on the actual command, as I had not specified an block sizes at all.
Turns out, there is a problem building an LVM on an existing raid. The solution was to dismantle the LVM, stop the raid, use fdisk to delete the partitions, then start over. This time, I did not format the raid. On the second attempt, the logical volume formatted without error.
Thursday, December 22, 2005
Patriot Act Renewal
They renewed the Patriot Act for another six months. In protest of this blatant violation of my civil liberties, I've made a list of my rights which have been infringed by this legislation. I will not rest until we regain these lost freedoms.
1.
2.
3.
This list is by no means complete. Check back often, as I will be adding additional items to the list whenever the "jack booted thugs" impose upon my life, liberty, and pursuit of happiness.
1.
2.
3.
This list is by no means complete. Check back often, as I will be adding additional items to the list whenever the "jack booted thugs" impose upon my life, liberty, and pursuit of happiness.
Friday, December 02, 2005
Fun with bash
In an effort to secure my internal network, I'm adding an access server. Initially, the firewall routed SSH to one of my application servers. Now it routes to a dedicated access server.
Previous: Internet -> Router - > Server -> Network
Current: Internet -> Router - > Access -> Network
Admittedly, this doesn't seem that different. The issue is the configuration of the system. The application server has to be accessible to other systems, so its security systems are somewhat basic. By using the access server, I can rachet the security as tight as it will go. Toward that goal, I've implemented within bash a few fun features.
In /etc/bashrc, I've appended:
if [ "$PS1" ]; then
USER=`cat /etc/passwd | grep ":$UID:$UID:" | awk -F: '{print $1}'`
date +"%d %H:%M:%S" | mail -s "$USER login" someuser@somewhere.com
fi
Whenever someone logs in (or su's to root) I get a message.
In each users .bash_logout file, I've added:
(sleep 3; mv ~/.bash_history /tmp/flytrap/`date +"%d%H%M%S"`; touch ~/.bash_history) &
The parens make this compound command execute in the background. The user's history file is committed to the drive, then (3 seconds later) moved to the flytrap. The flytrap is a directory where users can write, but they can not read (thus view):
# ls -ld /tmp/flytrap
d-------wt 2 root root 4096 Dec 2 13:35 /tmp/flytrap
Of course, I've changed the ownership and permissions on ~/.bash_logout to prevent the script kiddies from messing with it.
Previous: Internet -> Router - > Server -> Network
Current: Internet -> Router - > Access -> Network
Admittedly, this doesn't seem that different. The issue is the configuration of the system. The application server has to be accessible to other systems, so its security systems are somewhat basic. By using the access server, I can rachet the security as tight as it will go. Toward that goal, I've implemented within bash a few fun features.
In /etc/bashrc, I've appended:
if [ "$PS1" ]; then
USER=`cat /etc/passwd | grep ":$UID:$UID:" | awk -F: '{print $1}'`
date +"%d %H:%M:%S" | mail -s "$USER login" someuser@somewhere.com
fi
Whenever someone logs in (or su's to root) I get a message.
In each users .bash_logout file, I've added:
(sleep 3; mv ~/.bash_history /tmp/flytrap/`date +"%d%H%M%S"`; touch ~/.bash_history) &
The parens make this compound command execute in the background. The user's history file is committed to the drive, then (3 seconds later) moved to the flytrap. The flytrap is a directory where users can write, but they can not read (thus view):
# ls -ld /tmp/flytrap
d-------wt 2 root root 4096 Dec 2 13:35 /tmp/flytrap
Of course, I've changed the ownership and permissions on ~/.bash_logout to prevent the script kiddies from messing with it.
All EMF Products - Shielded Cap - Emf Protection
Finally, people won't think I'm crazy! The site, Block EMF, offers baseball caps made of copper core thread that will sheild your brain from dangerous RF waves. People will no longer ask me why I'm wearing an aluminum foil hat! See, I figure if the hat will keep the RF out, than it will keep the signals in my brain from going into outer space where they can be intercepted by aliens.
Though, the foil hat did go well with my cape.
Though, the foil hat did go well with my cape.
Monday, November 21, 2005
Minimuim Priviledges: mysqlhotcopy
I'm setting up a MySql server to run the database from a ramdrive (tmpfs). In order to protect the data, the system has to replicate the database in memory to the drive. The utility, mysqlhotcopy, can be used for this by adding it to a crontab. In my configuration, I'll copy the database to disk every 20 minutes. As my database is primarily read-only, if there were a crash, at worse I'd loose only a few updates.
The problem is that mysqlhotcopy requires a username and password, which must be issued on the command line. Since the command is stored in a crontab, the authentication information is stored in the clear. If someone were to comprimise the machine, I don't want to give them a free ride to the database.
The solution is to create a dummy account with minimuim priviledges. For my dummy account I set all priv's to 'N' except:
Select_priv='Y'
Reload_priv='Y'
Lock_tables_priv='Y'
This allows mysqlhotcopy to replicate the data to disk, but limits an intruder to switching the database to read only.
The problem is that mysqlhotcopy requires a username and password, which must be issued on the command line. Since the command is stored in a crontab, the authentication information is stored in the clear. If someone were to comprimise the machine, I don't want to give them a free ride to the database.
The solution is to create a dummy account with minimuim priviledges. For my dummy account I set all priv's to 'N' except:
Select_priv='Y'
Reload_priv='Y'
Lock_tables_priv='Y'
This allows mysqlhotcopy to replicate the data to disk, but limits an intruder to switching the database to read only.
Sunday, November 20, 2005
Apache modules
I've been needing this for a while: OpenSA has a list a quick reference to Apache modules. I was able to comment out about half the modules and slim the servers by about 12%. That mean more users, less swap. Woohoo!
Friday, November 11, 2005
Car Rentals: DAY beats MCO
...but not in a good way. Just got back from Dayton Ohio and was very dissappointed with the organization of their car rental layout. In fact, I think it is the first airport I've found that is worse than Orlando. (It astounds me that Orlando is so disorganized: With all the Disney tourists, you'd think theyed have thier act together!)
Normally, the Avis car counter has a score board that displays customer's names, and give information about their car. In Dayton, you have to know that the score board is on mounted backwards: You have to walk up to the counter, then turn your back on the counter representative to see the scoreboard.
Once you have you keys, you step outside the bagage area, turn to the right, and walk the one hundred yards to the cars. The cars are in an uncovered lot-- in Ohio. I've lived in Ohio-- it snows in Ohio. Sometimes allot. I don't want to have to load my lugage into a rental car in the snow. (The good new is that the hundred yard walk is not uncovered, they have you walk through a set of tent-like tunnels. This was especially entertaining since its still tornado season-- the tents were acting more like windtunnels than weather protectors.
But here's the best part. The rental return is on the complete opposite end of the airport from the checkin. Now its a two hundred yard walk. Returns should be more convient than pickup. If you arrive in a town late, you simply call your appointment, and blame missing you appointment on the airline. Everyone understands that. If get at the gate late for your flight home because of a problem with the rental car, the airline does not hold the plane for you.
Other than that, Dayton was OK.
Normally, the Avis car counter has a score board that displays customer's names, and give information about their car. In Dayton, you have to know that the score board is on mounted backwards: You have to walk up to the counter, then turn your back on the counter representative to see the scoreboard.
Once you have you keys, you step outside the bagage area, turn to the right, and walk the one hundred yards to the cars. The cars are in an uncovered lot-- in Ohio. I've lived in Ohio-- it snows in Ohio. Sometimes allot. I don't want to have to load my lugage into a rental car in the snow. (The good new is that the hundred yard walk is not uncovered, they have you walk through a set of tent-like tunnels. This was especially entertaining since its still tornado season-- the tents were acting more like windtunnels than weather protectors.
But here's the best part. The rental return is on the complete opposite end of the airport from the checkin. Now its a two hundred yard walk. Returns should be more convient than pickup. If you arrive in a town late, you simply call your appointment, and blame missing you appointment on the airline. Everyone understands that. If get at the gate late for your flight home because of a problem with the rental car, the airline does not hold the plane for you.
Other than that, Dayton was OK.
Friday, November 04, 2005
Fedora 4 Kickstart Errors, Brilliant Fix
Yep, got kickstart working. The fix was AFL brilliant! But before I tell you the solution, you have to promise to understand what I'm saying, rather than blindly implementing the fix.
I added a %pre statement:
dd if=/dev/zero of=/dev/hda count=1000
In other words: I wiped out the partition table. Of course this means all my data was destroyed! But that's OK... Your not suppose to store any mission critical data on a Fedora system anyway.
The major downside is that the system I'm playing with is a dual boot box, supporting both FC4 and RHEL4. This means that if I want to reinstall Fedora, I will have to follow it up with a Red Hat install. The good news is that kickstart still works under RHEL4, so it shouldn't be that painfull, just time consuming.
And, like, I got plenty of time!
I added a %pre statement:
dd if=/dev/zero of=/dev/hda count=1000
In other words: I wiped out the partition table. Of course this means all my data was destroyed! But that's OK... Your not suppose to store any mission critical data on a Fedora system anyway.
The major downside is that the system I'm playing with is a dual boot box, supporting both FC4 and RHEL4. This means that if I want to reinstall Fedora, I will have to follow it up with a Red Hat install. The good news is that kickstart still works under RHEL4, so it shouldn't be that painfull, just time consuming.
And, like, I got plenty of time!
Fedora 4 Kickstart Errors
What a disappointment. Turns out, the kickstart function is virtually useless under Fedora 4. After half a dozen attempts to rebuild a system, I found Chris's Wiki :: blog/linux/FC4BuggyAnaconda, which confirmed that there are two very big bugs in the kickstart facility. One bug will not let Anaconda (the 'client' side of kickstart) allocate partitions. If we can't find the partitions, we can't very well install software to the disk. The second bug prevents the system from being able to identify which packages to install.
So, let's recap: We can't find the disk, and even if we could, we can't figure out what to put on it. Too bad somebody didn't test this before it went out the door.
So, let's recap: We can't find the disk, and even if we could, we can't figure out what to put on it. Too bad somebody didn't test this before it went out the door.
Subscribe to:
Posts (Atom)