Rodney Fletcher’s Blog

Ok, it’s time to get 1990’s on yo’ ass. I admit this post is old news but sometimes it’s better late than never.

Anyway, on occasion, you may wish for the ability to log into to other Linux boxes or securely copy files between Linux boxes, using SSH, without being prompted for passwords. I.e. scripts. In my case, I wanted to copy the contents of my CentOS web development directory on a VM machine back to the VMWare Server 2 host system, so that I have an extra backup, that’s “not on the same machine” (it is actually a physically different disk and it’s not in the same config so despite sharing hardware, this is sort of true).

Anyway, enough background. Here’s the how.

Step 1. Log into the source computer. I.e. the computer that will run the script.

Step 2. Generate some SSH public keys as follows.
ssh-keygen -t dsa

Step 3. Load the newly created public key to the destination server, as follows.
ssh-copy-id -i ~/.ssh/id_dsa.pub user@destination.servername
Please note: user should be the same on both boxes.

Step 4. Test it out by trying to SSH to the destination server.

Step 5. Test copying your files. Here’s an example:
scp /backup/friday/* root@192.168.1.1:/u02/backup/webdev/friday

That’s it. You should now be able to use SCP to securely copy files between machines with no password prompts.

• Leave a comment... (0)

Here’s something a little embarrassing. Today I was wondering which version of CentOS a computer at home was using, which I was connected to via SSH. It’s easy enough to tell the Kernel or Linux version (uname -a or cat /proc/version) but I realised I couldn’t remember how to tell the “named” version of the OS. A quick Google set me straight.

[root@selene ~]# tail /etc/redhat-release
CentOS release 5.2 (Final)


• Leave a comment... (0)

It turns out one more of the many things yum can break is ntop. A quick Google found me this answer as to how to repair it, so I am archiving it here, in the hope that the next time this happens, I find the answer more quickly and maybe I even help someone else.

When you update from ntop to 3.3.6 (or install it) you will find you can run it as an application but not a daemon (service). It gives an error message like:

[root@selene ~]# service ntop restart
Stopping ntop: [FAILED]
Starting ntop: Processing file /etc/ntop.conf for parameters...
Thu Oct 2 22:20:26 2008 NOTE: Interface merge enabled by default
Thu Oct 2 22:20:26 2008 Initializing gdbm databases
FATAL ERROR: Unrecognized/unprocessed ntop options...
, --user ntop, , --db-file-path /var/ntop, , , , --use-syslog, , , , , , ,

run ntop --help for usage information

Common problems:
-B "filter expressions" (quotes are required)
--use-syslog=facilty (the = is required)

It turns out that the way ntop accepts command parameters has changed in 3.3.6. So now, we need to parse the config file before parameters. To fix, simply locate the daemon file and change a single line. Specifically:

1. Edit /etc/init.d/ntop
2. Find the line that says: daemon $prog -d -L @/etc/ntop.conf
3. Change it to: daemon $prog @/etc/ntop.conf -d -L

You should now be able to run ntop as a daemon (service). Note that the config file is now read before the parameters in the start up line.

An odd change to make but there you have it!

• Leave a comment... (112)

Recently, I moved to CentOS 5 for my VM Server. As pretty much the only thin I do with it is host VM sessions, I pretty much do everything as root. I know this isn’t “best practice” but it’s easier to manage – and like I said, it’s just there to house my VM sessions which do the real work.

So anyway, one thing that really bugs me is that under root on the newer brands of KDE – there is no trash can icon. When you delete something, it goes into “trash” by default – but you can’t see trash. You have to magically know the file location, by heart, then go and delete it.

Dumb.

Anyway, here’s how to make the trash can come back.

1. Create a new text file on the desktop.
2. Paste this into it:
[Desktop Entry]
Comment=Contains removed files
EmptyIcon=trashcan_empty
Encoding=UTF-8
Icon=trashcan_full
Name=Trash
Type=Link
URL=trash:/

3. Save the text file.

That’s it A trash can will now appear and you can start off by trashing that text file you just made.

Too easy.

• Leave a comment... (0)

I have recently been in the very unfortunate position of needing to get data off a deceased Linux system, which was running a software RAID-1 Linux LVM.

Normally, getting data off such drives is fairly simple – you put them in another build and copy the data. However for a long list of reasons, this wasn’t possible. In short, the only option I had available was to boot the dead system of a Live CD of Fedora 9 and then attempt to get the data onto a USB hard drive.

The problem was, my external USB hard drive was NTFS and couldn’t be made FAT as the files I needed are all larger than 32GB (which is the largest size a FAT partition can get to, let alone file size, which I think is around 2GB). The large files are VMWare disks, if you’re wondering.

The disk needed to remain visible to Windows, so I could load up the VMWare sessions ASAP, which meant NTFS it needed to stay.

So here’s the “howto” bit, in keeping with my policy of blogging anything I think I might need to remember in future.

How do you mount an NTFS permission in read/write, within Linux?

Firstly, you need ntfs-3g installed. If you don’t have it, you should be able to grab it with up2date, yum, apt-get etc. On a RedHat variant, like Fedora, you can see if it’s there as such:

{please note: all as root}

rpm -q ntfs-3g

Fortunately, I can see it happily sitting there: ntfs-3g-1.2506.1.fc.x86_64.

Now all I needed to do was mount it. This is just the mount command, with a few extra options:

Firstly, find the drive:
fdisk -l (that’s a lowercase L btw)

Here I see I am after /dev/sdb1

Now I just make a folder to mount it to:
mkdir /media/ntfs
mount /dev/sdb1 /media/ntfs -t ntfs-3g -rw -o umask=0000

If that tells you the drive wasn’t shut down cleanly (and it probably will) and you need to tell Windows to let go kindly, just repeat as follows:
mount /dev/sdb1 /media/ntfs/ -t ntfs-3g -rw -o force

There. Pretty simple. I can now copy my precious files to my NTFS drive and use them on my Windows PC, while I wait for Linux to reinstall on the crashed box.

• Leave a comment... (1)

Ok, the second problem I got with my power drop was the failure of the software RAID running on the VMWare host CentOS box. This can be seen as follows:

[root@selene ~]# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[2](F) sda2[0]
155227904 blocks [2/1] [U_]

(The (F) after the sdb1[2] is a bad thing, by the way, implying something failed).

Now, to fix this, I will need to rebuild the RAID (and also have some faith in the power supply, while I am doing it).

More detail can be picked up as follows:

[root@selene ~]# mdadm -D /dev/md0
/dev/md0:
Version : 00.90.01
Creation Time : Fri Mar 16 07:53:50 2007
Raid Level : raid1
Array Size : 155227904 (148.04 GiB 158.95 GB)
Device Size : 155227904 (148.04 GiB 158.95 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Mon Jan 28 15:43:15 2008
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0

UUID : 870a8c32:61f98f07:8433c71a:2d84006c
Events : 0.4444326

Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 0 0 – removed

2 8 17 – faulty /dev/sdb1

Uh oh, something has failed out of the RAID… Looks like we need to bring it back in. We do this as follows.

We know that /dev/sdb1 is the one which has failed out, so let’s bring it back in as follows:

[root@selene ~]# mdadm /dev/md0 –remove /dev/sdb1
mdadm: hot removed /dev/sdb1
[root@selene ~]# mdadm /dev/md0 –add /dev/sdb1
mdadm: hot added /dev/sdb1

Now we can see it’s rebuilding, again by using mdstat:

[root@selene ~]# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[2] sda2[0]
155227904 blocks [2/1] [U_]
[>....................] recovery = 0.1% (226560/155227904) finish=57.0min speed=45312K/sec
unused devices:

So that’s it. Just keep an eye on the recovery and watch it as it goes. You can do this by just running mdstat (as above) a few times every 15 minutes or so, to see how far along it’s gotten.

Good luck!

P.S. For the record, my RAID-1 with 2*160GB IDE drives (47% full) took around an hour.

• Leave a comment... (5)

Because I mainly use this blog to remind myself of fixes for things that crop up from time to time, here is the next one.

Recently, I was performing a yum update on a VMWare guest OS, running Fedora 7, when the power dropped (the device was on a UPS – ironically the only thing to fail was the UPS… guess it’s had its day). Anyway, when it came back up, it couldn’t complete the yum update, due to a segmentation fault.

Anyway, the way to fix this problem is pretty simple. Just go to the bash and enter:

rpm –rebuilddb (that’s two hyphens).

This should correct the issue.

Cya!

• Leave a comment... (2)