Sexy Sexy Penguins

So pretty, so very pretty!

At least the install is quite pretty. The new look and feel of Fedora 7 is definitely nice. I did, however notice a couple things that I didn’t like. It wasn’t immediately obvious how to pass commands on the Anaconda boot line.  After a little looking around, I discovered that hitting the tab key will allow you to edit the boot line.

One device standard to rule them all

It’s been a long time coming and now Fedora 7 is running the 2.6.20 kernel with libata activated, all of the hard drives on my systems will now be referred to as a consistent /dev/sd. No more /dev/hd! Isn’t that great! This will definitely come in handy when writing kickstart files and mounting drives.

Fastest ‘user switching’ in town!

Although it broke a little for me, it was easy to switch from user clints to another user quite easily. It only took about 3 seconds and I had to enter the password for my other users. In addition, there are some glitches in the switching back and forth.

Let’s see what they give us tomorrow

Tomorrow is the release of Fedora 7 Test 3. I expect big improvements over Test 2. Go ahead and get the new release. It should be announced anytime now. Download the Test 3 release tomorrow (hopefully) at http://torrent.fedoraproject.org/.

Cheers,

Herlo

I was visiting the Fedora People website when I ran across a post by Thorsten Leemhuis.

The content of the post was a quick way to set up notifications using libnotify when someone either shouts your name or says your nick in irssi. So I thought I’d give it a try. His is an alteration to the original found here.

After about 10 minutes of effort and a little bit of tweaking, I now have a script that will notify me every time someone says my name in irssi. It was really easy to setup. His had one little bug which I’ve fixed, so the new script has been posted below.

Essentially, you need two scripts, the remote fnotify, which needs to be loaded into irssi, and the local irssi-script script, which should be loaded when you login. I recommend the ~/.bashrc file. Refer to the original article for helpful details.

Once you’ve got the scripts downloaded. Take the remote fnotify script and rename it to fnotify.pl and place it in your remote ~/.irssi/scripts directory

$ mv fnotify ~/.irssi/scripts/fnotify.pl

Then, inside irssi, go ahead and run the following three commands:

/unload perl
/load perl
/script load fnotify.pl

If successful, a message similar to this will appear in your irssi control window:

21:20 -!- Irssi: Loaded script fnotify

If any other errors appear when running the /load and /unload operations, it should be okay to continue.

Once this is working, its time to go ahead and start the irssi-script obtained previously.

$ ./irssi-script

Once this happens, get someone to say your name in irssi. Once they have done so, you should get messages that looks similar to this in the bottom right hand corner of your desktop:

This worked pretty well for me. A few things could work better but aren’t too bad. I currently have no way of running the local irssi-script as a service or on login without my ~/.bashrc hanging. I’ll have to look further into it before I have a solution.

I hope this is useful for you as it was for me.

Cheers,

Herlo

PS - As a quick aside; 15 minutes or so into my research, I also noticed another script at the bottom in the comments that was supposed to be able to do it without the extra startup script. When I tried it, I was getting failures within irssi –something about dbus not working properly.

How many of you have ever lost your data on a hard drive? I know I have, more than once. Usually, I give up on recovering the drive but this time I really couldn’t.

I was installing a machine as I normally do for class, I have a removable usb drive (80GB) that I keep the installation media spooled. For some reason, this time when the installation had completed, the disk appeared to be completely wiped. I thought I was screwed. The data I had was company data which has to be saved for several months. It was important that I recover this data.

Luckily for me, the data wasn’t gone, just the partition table. I hunted around the interweb for a while and struggled to find anything useful to help me recover the lost partition. After about a day and a half searching, I was about to give up, when I found this guide. The guide is a bit cryptic but nonetheless gets the job done.

This is my saving grace. I’ve got this tutorial bookmarked in several places now and intend on making a tutorial here on how to accomplish this as well, mainly just so I always have it available.

Now, I could have completely avoided the situation if I had backed up my partition table. And because of what had happened, I am going to show you how to back up your partition tables quickly and easily using sfdisk.

sfdisk, or scriptable fdisk is useful for creating partitions on the fly, or in our case, quickly backing up partition tables.

First, take a look at this partition table. Note that I have 7 partitions here:

# fdisk -l
Disk /dev/sdc: 66 MB, 66240512 bytes
3 heads, 43 sectors/track, 1002 cylinders
Units = cylinders of 129 * 512 = 66048 bytes

Device Boot Start End Blocks Id System
/dev/sdc1 1 152 9782+ 83 Linux
/dev/sdc2 153 259 6901+ 83 Linux
/dev/sdc3 260 305 2967 82 Linux swap / Solaris
/dev/sdc4 306 1002 44956+ 5 Extended
/dev/sdc5 306 563 16640+ fd Linux raid autodetect
/dev/sdc6 564 776 13738 fd Linux raid autodetect
/dev/sdc7 777 1002 14576+ 83 Linux

/dev/sdc1 is mounted at /mnt and has a couple files loaded:

# mount
..snip..
/dev/sdc1 on /mnt type ext3 (rw)

# ls -l /mnt
total 8353
-rw-rw-r-- 1 root root 65182 Mar 16 10:42 iah-sna.pdf
drwx------ 2 root root 12288 Mar 16 10:35 lost+found
-rw------- 1 root root 8437760 Mar 16 10:42 zlm-administrator-guide.pdf

To back up the partition table run the following command:

# sfdisk -d /dev/sdc > /tmp/sdc-backup.txt

What does that produce:

# cat /tmp/sdc-backup.txt
partition table of /dev/sdc
unit: sectors

/dev/sdc1 : start= 43, size= 19565, Id=83
/dev/sdc2 : start= 19608, size= 13803, Id=83
/dev/sdc3 : start= 33411, size= 5934, Id=82
/dev/sdc4 : start= 39345, size= 89913, Id= 5
/dev/sdc5 : start= 39346, size= 33281, Id=fd
/dev/sdc6 : start= 72628, size= 27476, Id=fd
/dev/sdc7 : start= 100105, size= 29153, Id=83

Looks pretty much like what fdisk -l show, but in a slightly different format. sfdisk will use this file later on to recover.

Let’s destroy the partition table. The dd command overwrites the first 512 bytes of the disk with zeros.

# dd if=/dev/zero of=/dev/sdc bs=512 count=1

# fdisk -l /dev/sdc
Disk /dev/sdc: 66 MB, 66240512 bytes
3 heads, 43 sectors/track, 1002 cylinders
Units = cylinders of 129 * 512 = 66048 bytes

Disk /dev/sdc doesn't contain a valid partition table

Oops, gone is the partition table. That’s not good. Luckily a backup has been made, and should be able to restore it quite easily:

# sfdisk /dev/sdc < /tmp/sdc-backup.txt
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdc: 1002 cylinders, 3 heads, 43 sectors/track

sfdisk: ERROR: sector 0 does not have an msdos signature
/dev/sdc: unrecognized partition table type
Old situation:
No partitions found
New situation:
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/sdc1 43 19607 19565 83 Linux
/dev/sdc2 19608 33410 13803 83 Linux
/dev/sdc3 33411 39344 5934 82 Linux swap / Solaris
/dev/sdc4 39345 129257 89913 5 Extended
/dev/sdc5 39346 72626 33281 fd Linux raid autodetect
/dev/sdc6 72628 100103 27476 fd Linux raid autodetect
/dev/sdc7 100105 129257 29153 83 Linux
Warning: no primary partition is marked bootable (active)
This does not matter for LILO, but the DOS MBR will not boot this disk.
Successfully wrote the new partition table

Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

Remount /dev/sdc1 to see if the partition data is still there:

# mount -t ext3 /dev/sdc1 /mnt
# ls -l /mnt
total 8353
-rw-rw-r-- 1 root root 65182 Mar 16 10:42 iah-sna.pdf
drwx------ 2 root root 12288 Mar 16 10:35 lost+found
-rw------- 1 root root 8437760 Mar 16 10:42 zlm-administrator-guide.pdf

There it is! Wow, data was never lost, just hidden for a while.

This can be helpful in other ways too. Using sfdisk to build scripted partitions is never easier now. Just build a file from one pre-partitioned disk, modify and use it everywhere else.

Cheers,

Herlo

What does that mean? Seeing Linux in Linux? Huh?

Well let me tell you a little about vnc - Virtual Network Computing.

vnc has been around quite some time, and in Fedora, its easy to setup. vnc supports communication over ssh too, which will help us securely perform over the network. There are two parts to vnc, the client vncviewer; and the server; vncserver. The easiest way to configure vnc is to set up vncserver first.

vncserver runs as a system V service in Fedora 6. We need to do some configuration to allow connections from different users. Modify the /etc/sysconfig/vncservers configuration file to set the connections up:

# vi /etc/sysconfig/vncservers

Find the lines that look like this:

VNCSERVERS="1:root"
VNCSERVERARGS[1]=”-geometry 800×600″

And add your configurations however you’d like. Many options are detailed in this configuration file. Here’s a few good ones:

-nolisten tcp - Prevents X connections to the VNC Server over TCP
-localhost - Prevents remote VNC clients from connecting, except when they do a ssh tunnel.

Here is my /etc/sysconfig/vncservers file on a system I recently configured:

# cat /etc/sysconfig/vncservers
..snip..
VNCSERVERS="1:root 2:student"
VNCSERVERARGS[1]=”-geometry 800×600″
VNCSERVERARGS[2]=”-geometry 640×480 -localhost”

Of course, we should make a password for each of our users as well. This password should probably not be the same as the user’s login, but nothing prevents the password from being the same. To change the users password, login as that user and run vncpasswd:

# vncpasswd
Password: mypassword
Verify: mypassword

Finally, we need to make sure vncserver starts correctly:

# /etc/init.d/vncserver restart
..snip..
Starting VNC server: 1:root
New 'station5.example.com:1 (root)' desktop is station5.example.com:1

Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/station5.example.com:1.log

2:student
New 'station5.example.com:2 (student)' desktop is station5.example.com:2

Starting applications specified in /home/student/.vnc/xstartup
Log file is /home/student/.vnc/station5.example.com:2.log

Once started, test out the connections. These two connections have been configured differently.

Connection 1 will let me connect as root with a screen size of 800×600 over an insecure vnc connection. Connection 2 will let me connect as student but only via an ssh tunnel. Let’s have a look at how we’d connect:

Connecting as root to station5:

$ vncviewer station5:1

or

$ vncviewer via root@station5 localhost:2

This prompt appears.   Enter the password you created earlier with vncpasswd.

And voila!! You should have access to that user’s desktop.

Cheers,

Herlo

Some of you might recall my article the other day about vim encryption. It is a very nice way to encrypt the file but has some holes in the process. Having extra files laying around while the encrypted file is open is not good enough, though with enough physical security it could be fairly safe.

Along comes gpg with another option for me to try. I’ve spent a fair amount of time digitally signing my documents with my gpg key. I’ve distributed my public key and kept my private key safe as well for when I do need to decrypt something important.

Today in my travels around the interweb, I came across a bit about gpg encryption and thought that it might be able to accommodate my request of a simple encryption utility for my passwords file. So lets have a look at it and see the results.

The simplest thing to do is to take my unencrypted passwords file and encrypt it with gpg:

$ gpg -c passwords
Enter passphrase: my pass phrase
Repeat passphrase: my pass phrase
$ ls passwords*
passwords passwords.gpg

Well, there’s my problem, right there. Did you see it? I did! The problem is that I now have two files, one encrypted and one not. I don’t want the unencrypted one anymore now that I have the encrypted one. Except, what if the encrypted one didn’t work? What if I lose the encrypted file, what if it’s on a bad block? Well, there’s my dilemma. And I am still waiting for a better solution, ho hum, I guess I’ll keep looking.

Meanwhile, back at the gpg ranch, I’ll show you how to decrypt the file so you can read it again.

$ gpg passwords.gpg
gpg: CAST5 encrypted data
Enter passphrase: my pass phrase
gpg: encrypted with 1 passphrase

And my file is restored to its original state. This is good for sure, but I think it isn’t quite what I am looking for… Thank you for trying gpg, I’ll keep looking. vim encryption seems appropriate for now.

Cheers,

Herlo

Hi all.

As the founder of the Utah Open Source Conference and one of its biggest proponents.  I just wanted to mention that if you hadn’t already seen the post from the Utah Open Source Planet, you will have now.

I am looking forwared to reading all of the outlines coming in over the next month.  Big things are afoot and much will happen in the coming days.  We anticipate a good load of submissions so get yours in early.

Lots of fun stuff will be presented we are sure, and choosing the presenters will be a lot of fun and I am sure looking forward to reviewing many outlines.

If you have anything, anything you want to talk about that relates even a little bit to Open Source in Utah, please submit it today.  You only have until the end of April to do so.

Cheers,

Herlo

I should have mentioned this earlier, but Fedora 7 Test 2 was released earlier this week.

Here’s the announcement: http://www.redhat.com/archives/fedora-announce-list/2007-March/msg00000.html

There are some subtle improvements so far:

• Merger of Core and Extras - There is no core or extras anymore, there is only Fedora 7
• Live CD Available - This is definitely cool and about time
• Desktop Improvements - New theme and a better version of Gnome by default
• Fast User Switching - I’ve not seen this concept before in Linux, looking forward to playing with this feature

All in all, things look promising. I am currently downloading the latest release and when I’ve had some time to evaluate these and some of the other cool features listed on the link above, I’ll report back.

Cheers,

Clint

Today, while trying to find a solution which still eludes me for storing passwords in a local file. I was informed about a cool feature of vim, which has been in there since version 5.7, encryption.

My main problem was that I wanted to save all of the non-browser passwords and accounts that I’ve been collecting over the past year or so, having them in one central location. This would make it easy to quickly obtain my usernames and passwords to my accounts on several boxen I maintain. Many of which have several passwords for my login, mysql and other services I regularly use.

vim provides this encryption feature in two ways. One is with the -x option, the other is within vim command mode using ‘:X’. vim does not go out of it’s way to make sure protect .swp temporary backup files or text in memory, so this isn’t perfect.

I am still looking for a packaged solution where I can have my passwords stored in an application where I can quickly obtain them by providing a simple pass phrase, either on a usb key, or the physical hard drive in one of my machines. I’d also like to be able to use my gpg and ssh keys as well with this method. A couple of tools that provide similar functionality would be KeePass (for Windows) and Password Safe (for Windows and Linux Source Only).

Comments are welcome, please tell me about all the cool tools I could use. Tell me how to use gnome-keyring too, and make suggestions with usage if you can.

Cheers,

Herlo