CentOS 6.3: Installing a TFTPD server for uploading configuration files

These days I’m reading Vyatta Core’s documentations as I’m planning to deploy virtual routers and firewalls on my OpenNebula cloud laboratory. I remember the days I worked with Cisco routers and how many times I had to use a tftp server to store configurations. You don’t need a tftp to store remotely your virtual router configurations (you can use ssh or ftp) but I feel nostalgic and I want to use that server in my CentOS machine.

yum install tftp-server
adduser tftpd
chown tftpd:tftpd /var/lib/tftpboot
# if you are running iptables and want to save your firewall rules
iptables -I INPUT -p udp --dport 69 -j ACCEPT
service iptables save
# if you want xinetd/tftpd start on boot
chkconfig xinetd on

I’ve created a tftpd user and added some parameters suggested in the /usr/share/doc/tftp-server-0.49/README.security. As I want to be able to upload files I need -c and -p arguments and I’ve set the umask for the new files 117 (read write permissions for tftpd user and group). These are the lines I’ve modified in the /etc/xinitd.d/tftpd :

  • disable = no
  • server_args = -c -p -u tftpd -U 117 -s /var/lib/tftpboot

Finally start the xinetd service:

  • service xinetd start

Your TFTPD server will be running in the UDP 69 port.

Advertisements

OpenNebula : VNC Access

I will repeat it again, OpenNebula documentations is your friend. This is the documentation section which I’ve followed to enable VNC/Console for my VM:

http://opennebula.org/documentation:archives:rel3.0:sunstone

When creating the virtual machine template I’ve set the following values in the Add Graphics section:

  • Graphics Type: VNC
  • Listen IP: 0.0.0.0
  • Port:
  • Password:
  • Keymap:

If you want to open a vnc session in your virtual machine, you’ll need to install first noVNC using the install script available:

[root@haddock one]# cd /usr/share/one/
[root@haddock one]# ./install_novnc.sh
Downloading noVNC latest version...
######################################################################## 100,0%
Extracting files to temporary folder...
Installing Sunstone client libraries in /usr/lib/one/sunstone/public...
Installing SelfService client libraries in /usr/lib/one/ruby/cloud/occi/ui/public...
Downloading Websockify VNC proxy files
######################################################################## 100,0%
######################################################################## 100,0%
Backing up and updating /etc/one/sunstone-server.conf with new VNC proxy path...
Backing up and updating /etc/one/occi-server.conf with new VNC proxy path...
Installation successful

I’ve added a rule in my firewall so I can connect to the VNC port (29876 is the default, read the documentation section I’ve linked where an explanation is provided):

iptables -I INPUT -p tcp --dport 29876 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

Maybe I can configure this rule somewhere in OpenNebula, I’ll investigate it.

And here is a screenshot of a vnc session!

VNC_connection

OpenNebula – KVM QEMU could not open disk image disk.0: Permission denied

I’ve been trying to figure out why this error was logged when trying to submit and run a virtual machine in OpenNebula with QEMU and KVM: “could not open disk image disk.0 Permission denied”. SELinux was complaining about dac_override and dac_read_search.

I thought it was a problem with security contexts as /var/lib/one directory is labelled with var_lib_t security context and QEMU would expect a virt_image_t context or svirt_image_t to run the virtual machine (libvirt provides documentation about QEMU and SELinux in this URL http://libvirt.org/drvqemu.html)

I changed the security context for the /var/lib/one/datastores directory:

chcon -R --type=virt_image_t /var/lib/one/datastores

Despite the security context change the error persisted, thankfully I found this message in the OpenNebula mail list:

http://lists.opennebula.org/pipermail/users-opennebula.org/2010-September/012877.html

I finally get rid of the permission denied editing my /etc/libvirt/qemu.conf and restarting the livirtd daemon (service libvirtd restart)

user="oneadmin"
group="oneadmin"
dynamic_ownership = 0

I’m still being able to run OpenNebula and SELinux, let’s see if I can keep SELinux enabled in my following tests.

OpenNebula – No tty present and no askpass program specified error

I’ve been reviewing my installation notes. If you can’t run a VM in OpenNebula and the log shows the following:

post: Command "sudo /usr/bin/ovs-vsctl set Port vnet0" failed.
post: sudo: no tty present and no askpass program specified

Check the following:

  • your oneadmin user has root privileges to run ovs-vsctl and ovs-ofctl commands
  • NOPASSWD is used so no password is asked when running the commands
  • The requiretty option is disabled in your sudoers file

Use visudo command as root to edit the sudoers file. Here is an extract of my file.

# Defaults requiretty

# Allow oneadmin to run some commands
oneadmin ALL = NOPASSWD: /sbin/iptables
oneadmin ALL = NOPASSWD: /sbin/ebtables
oneadmin ALL = NOPASSWD: /usr/local/bin/ovs-vsctl
oneadmin ALL = NOPASSWD: /usr/local/bin/ovs-ofctl

Bye

Unable to add bridge brX port vnetX: Invalid argument or Operation not supported

This week I run one VM in my OpenNebula/KVM host, but as I like to shutdown my physical host every day (I don’t like to waste electricity when I’m not playing with my HP N40L), I encountered a problem when the host was up again.

The VM was in FAILED state and I found the following log when OpenNebula/KVM tried to run the VM:

error: Unable to add bridge br0 port vnet0: Invalid argument

Openvswitch wrote this log in /var/log/messages:

ovs-vsctl: 00002|vsctl|ERR|cannot create a port named vnet0 because a port named vnet0  already exists on bridge br0

It was clear that there was a problem with my openvswitch. I maybe wrong, (please understand that I’m learning how to use all this stuff ) but when OpenNebula oned daemon is stopped when my physical host is going to be halted, the virtual ports are not removed from the bridge so it’s not possible to add them when resuming operations (the virtual port is indeed removed if you first stop the VM).

This discussion helped me to understand the problem. According to that thread, Libvirt >= 0.9.11 seems to deal with abrupt restarts more nicely and it suggests not to use brcompatd mode.

If I remove –brcompat from my initd script, OpenNebula/KVM will show a different message

error: Unable to add bridge br0 port vnet1: Operation not supported

Although I compiled Libvirt 0.10.1, so no bridge compatibility mode should be needed, OpenNebula’s documentation states that “It is also necessary to install the Open vSwitch compatibility layer for Linux bridging“, so no choice for me!, I need to add –brcompat.

I’ve solved this problem using –delete-bridges (read the discussion) in my init.d script, so every bridge is removed from openvswitch’s database and, therefore, any port created by OpenNebula/KVM is also removed. Important: I’ve included the ovs-vsctl commands to add the bridge again so the network interface is ready to be used.

start() {
$exec start --system-id=random --brcompat --delete-bridges
retval=$?
[ $retval -eq 0 ] && touch $lockfile
/usr/local/bin/ovs-vsctl add-br br0
/usr/local/bin/ovs-vsctl add-port br0 eth0
return $retval
}

I’m sure it’s only a problem with my server, but if you happen to have the same problem please leave a comment if you find a better or cleaner solution.

Enjoy!