Problem mounting NFS on startup

Posted on by Simon

The previous post mentioned that the machine would not start properly, and how to get a serial console going. The reason for the failure was that the NFS share did not mount properly. Not entirely sure why, but this solved it;

In /etc/fstab, I had:

[2a01:4f8:nnn:nnn::nnn]:/srv /srv nfs defaults,noatime 0 0

Changing to this seems to have solved it. I’m no expert in NFS, but it works for me:

[2a01:4f8:nnn:nnn::nnn]:/srv /srv nfs rw,noatime,hard,intr,rsize=8192,wsize=8192,timeo=14 0 0

 

Enable serial console under Xen

Posted on by Simon

Today I needed to see why a virtual machine under Xen was not starting up properly, and I knew it was possible to connect via a serial interface. Unfortunately this is not enabled by default (at least not in my installation). So here’s what to do.

ON GUEST MACHINE (my case is Ubuntu 12.04, using Startup system):

Add this in a new file /etc/init/hvc0.conf:

# Launch serial console for Xen

start on stopped rc RUNLEVEL=[2345] and (

not-container or

container CONTAINER=lxc or

container CONTAINER=lxc-libvirt)
stop on runlevel [!2345]
respawn

exec /sbin/getty -L 9600 hvc0 xterm

# End of file

 

ON HOST MACHINE:

In the VM’s config (my case this is /etc/xen/some_guest.cfg), add a line like this: extra=”console=hvc0 xencons=tty”. That’s hvc-zero btw.

 

Now you have to reboot the machine, possibly shutdown and re-create the VM for the Xen config to kick in.

 

Now you can connect to the console by:

xm list (to find your VM’s ID)

xm console [ID] to connect. You hit Ctrl+] to escape from it, which on my Swedish Mac means pressing Ctrl+Å.

Expanding a guest VM’s disk

Posted on by Simon

Looks like I’m running low on disk on my virtual machine (VM) running ownCloud. Luckily, there’s plenty more available on the host so today I’m expanding the logical volume (LV).

Step one – as always, BACKUP your data. I use rsnapshot together with ssh and mysqldump.

Step two – shutdown the guest.

Step three – On host run (as root): ssm resize /dev/vg0/cloudStorage -s+250G. Where vg0 is the name of your storage pool and cloudStorage is the name of your LV. SSM is a smart tool that takes care of partitioning, logical volumes, storage pools and file system.

Step four – Start your guest: virsh start ownCloud (or whatever the name of your VM).

Done. Happy clouding!

SSH Agent and pubkey authentication

Posted on by Simon

In my quest to increase security on a few servers I run that are facing the Internet, I’ve started to utilize private/public key authentication and limit which IP’s that can connect via SSH. The priv/pubkey is not new to me, in fact I’ve used it for the past ten or so years. Only that the certificate I’ve used for that time is very weak. So figured I’d do something. And I also do not like typing passwords all the time, but I want a pass phrase on my certificate. Insert SSH Agent!

Essentially, SSH Agent loads your private key, you type in the password once and then it remembers if for you. And it can be forwarded to the next server to chain it all together nicely.

I won’t do an overly detailed to-do this time, but essentially here’s what I did:

  1. Build a new certificate pair: ssh-keygen -b 4096 -t rsa -C MyKey. You will be asked to enter a password, which is recommended. In ~/.ssh you’ll find id_rsa and id_rsa.pub.
  2. Copy the contents of id_rsa.pub into your server’s ~/.ssh/authorized_keys. One key per line if there are multiple ones.
  3. Try the connection: ssh -o PasswordAuthentication=no you@yourserver. This should force the use of the keys. If all works well, you’ll get to enter the password OF YOUR KEY, not the account password. Then connect.
  4. All good? Then let’s start agent (this is preferably done in ~/.bash_profile): eval `ssh-agent`. Followed by ssh-add. You can specify which key(s) to load here, but that’s for another time. Try step #3 again, and you should pop right in, no questions asked.
  5. Good! Then let’s disable password authentication. Edit /etc/ssh/sshd_config and find PasswordAuthentication. In some cases it explicitly says “PasswordAuthentication yes”, in others it’s commented out because it’s the default. We want to uncomment this and set to NO. So: PasswordAuthentication no.
  6. Now restart SSHd, by sending “killall -HUP sshd“. There are other elegant ways to do this, but it does the trick. If your key does not let you in now, then you’re in trouble… Don’t blame me. :)
  7. Optional: In addition to this, I opt to only trust IP’s that I know.  So I added this to /etc/hosts.deny: sshd: ALL and to /etc/hosts.allow; sshd: [2001:123:456:789a::]/64. This makes sure that only my IPv6 range can get in. The changes to hosts.allow and hosts.deny takes immediate effect, so be careful.
  8. Should be pretty safe now :)

 

If you’re on a Windows client and use PuTTY, there are tools for this too. Use PuTTYgen to create or convert the keypair, and Pageant as the running agent. PuTTY and WinSCP will use Pageant when you try to connect, by default.