scp -P 22 -r /home/username/local-directory ip-or-hostname-of-remote-server:/home/username/remote-directory.

scp = Secure Copy.

-r = Tecursive (copy the contents of the directory and the contents of any directories inside that directory).

-P = (specifying the port number).

22 = The port number SSH is running on, on the remote server. (That’s right, some of us who are little security conscious, don’t leave SSH running on port 22).

/home/username/local-directory = The local directory on the ’source’ server, containing the files you want to copy to the remote servers

/home/username/remote-directory = The directory on the ‘destination’ server, where you want to copy the files to.

ip-or-hostname-of-remote-server = The example says it all. Replace this section with the remote IP Address or Hostname of the destination server.

Easy enough? If not, or you would like further examples or assistance, please feel free to ask you questions in the comments.

• IRCBot (ircbot)
• ngIRCd (ngircd)
• Services for IRC (ircservces)
• Shoutcast (sc_serv)
• StreamTranscoder (transcoderv3)
• Openfire

Initially, I searched and searched the internet and found all sorts of solutions dating back to the 1990’s all the way through to 2010. I even managed to cobble something together, but it was pretty terrible and failed sometimes (more often than not actually).

Some readers may have noticed that one of my examples above, already contains an almost perfectly good solution!

Services for IRC (developed primarily by Andrew Church), contains an additional script (once compiled and installed) under the file name of ircservces-chk (located here: /usr/local/sbin/ircservices-chk on most linux distributions). The contents of this file looks like this:

#!/bin/sh
#
# Script to check whether IRC Services is running, and restart it if not.
# Usage: ircservices-chk [-q] [ircservices-options]
# -q: don't write any output
# ircservices-options: options to pass to ircservices executable
# If you change PIDFile in ircservices.conf, also change PIDFILE below.
#
# IRC Services is copyright (c) 1996-2009 Andrew Church.
# E-mail:
# Parts written by Andrew Kempe and others.
# This program is free but copyrighted software; see the file GPL.txt for
# details.

PIDFILE=ircservices.pid

if [ "X$1" = "X-q" ] ; then
exec 1>/dev/null
exec 2>/dev/null
shift
fi

ok=
if [ -f "/usr/local/lib/ircservices/$PIDFILE" ] ; then
pid=`cat "/usr/local/lib/ircservices/$PIDFILE"`
if echo "0$pid" | grep -q '[^0-9]' ; then
rm -f "/usr/local/lib/ircservices/$PIDFILE"
elif kill -0 $pid ; then
ok=1
fi
fi

if [ ! "$ok" ] ; then
"/usr/local/sbin/ircservices" "$@"
fi

This script is almost perfect for my use (it does an exactly perfect job for ircservices), but not quite. This script uses the process id (PID) of ircservices to check if it is running or not. That’s ok, but not all programs output their current process ID to a file based location on the system or in any way that’s useful to the end user. I added a line to the beginning of the script, using the pgrep command to output the PID of my selected process to a file.

pgrep process-name > /home/username/a-directory-of-your-choosing/a-file-name-of-your-choosing.pid


Obviously you would replace process-name with the name of the process you want to monitor and username with your actual username.

You can use the command ps aux to list all the processes currently running on your system and locate the process you want to monitor.

The ‘.pid’ file extension isn’t really necessary, however it might be handy for identifying what the file is, should you come across it later on down the track. Here’s my example for checking that ircbot is running:

#!/bin/sh
#
# Script to check whether IRC Services is running, and restart it if not.
# Usage: ircservices-chk [-q] [ircservices-options]
# -q: don't write any output
# ircservices-options: options to pass to ircservices executable
# If you change PIDFile in ircservices.conf, also change PIDFILE below.
#
# IRC Services is copyright (c) 1996-2009 Andrew Church.
# E-mail:
# Parts written by Andrew Kempe and others.
# This program is free but copyrighted software; see the file GPL.txt for
# details.
pgrep ircbot > /home/username/ircbot/ircbot.pid
PIDFILE=ircbot.pid

if [ "X$1" = "X-q" ] ; then
exec 1>/dev/null
exec 2>/dev/null
shift
fi

ok=
if [ -f "/home/username/ircbot/$PIDFILE" ] ; then
pid=`cat "/home/username/ircbot/$PIDFILE"`
if echo "0$pid" | grep -q '[^0-9]' ; then
rm -f "/home/username/ircbot/$PIDFILE"
elif kill -0 $pid ; then
ok=1
fi
fi

if [ ! "$ok" ] ; then

"/home/username/ircbot/ircbot" "$@"
fi


Here’s my final version.

#!/bin/sh
#
# Script to check whether a process is running, and restart it if not.
# Usage: running [-q]
# -q: don't write any output
# Props to Andrew Church (http://www.ircservices.za.net) for creating
# the original script ircservices-chk of which this script you are using
# now is a slight modification by Quin Rose of Mokona Modoki
# http://www.mokonamodoki.com/

pgrep ircbot > /home/username/ircbot/ircbot.pid

PIDFILE=ircbot.pid

if [ "X$1" = "X-q" ] ; then
exec 1>/dev/null
exec 2>/dev/null
shift
fi

ok=
if [ -f "/home/username/ircbot/$PIDFILE" ] ; then
pid=`cat "/home/username/ircbot/$PIDFILE"`
if echo "0$pid" | grep -q '[^0-9]' ; then
rm -f "/home/username/ircbot/$PIDFILE"
elif kill -0 $pid ; then
ok=1
fi
fi

if [ ! "$ok" ] ; then
"/home/username/ircbot/ircbot" "$@"
fi

To use this script, just copy and past the code above into your favourite editor and be sure to save the script, and make it executable with:  chmod +x filename

Last but not least, you don’t want to have to run this script all the time, and manually by yourself do you? Wondering if you can just get put it in a cron job and let it rip? Well, Yes! You can! Add the following line to cron for automatic (once a minute) process checking goodness:

* * * * * /home/andrew/ircbot/ircbot-chk -q

There are plenty of resources on the web relating to cron, so if you would rather have cron execute the script less often, you’ll need to do a little googling.

Adding the -q sends all output from the script to /dev/null (a black hole of sorts) thus not showing any output on the screen. You can test it with or without the -q.

If you have any questions or would like for information or examples, please do let me know in the comments, and I will be only too happy to be of assistance! This certainly helped me, so I thought I would share, so that it could help you too!

Install CentOS 5.3 32/64 Bit

If you haven’t installed CentOS 5.3 already, you should do so. Kinda hard to use VMware Server 1.0.9 without an operating system. Most people want the host OS to have as little additional crap as possible. In regards to that, during the installation, make a point of not installing any additional packages, or package groups except the ‘Base’ group (oh and leave the base group in it’s default state, don’t go ticking on any extras, you’ll make the installation install more dependancies thus more crap). So in other words, only the ‘Base’ group should be ticked, untick the rest!

Nope, you won’t have any GUI, and even if you did, you still have to do the rest of the configuration at the command line anyway. VMware Server 1.0.9 host with GUI = bad idea, unless of course your host is also your desktop.

Once installed, configure your host as you like it from the ‘firstboot’ screen and than login as root. Here’s a few tips.

• Disable any services you aren’t using.
• Disable SE Linux
• Unless you’re going to configure and use it with VMware Server 1.0.9 machines, disable ip6tables
• Don’t go configuring special firewall rules just yet, leave that until later.

Even though it’s the host, its’ software should still be up to date. Issue the following command and download any updates.

yum update

Updates finished? Awesome! Lets reboot the server and start the next step afresh.

shutdown -r now

Install VMware Server 1.0.9 Required Components.

Plenty of you will argue about what you do and don’t need to complete the install. Well, I’ve completed this configuration of server with VMware Server more times than I care to remember now, and sometimes I needed all of these packages and sometimes I didn’t. No, I didn’t bother to find out why. Do you know why? Great! Put it in the comments!

Login in as root and issue the following commands one after the other. Yes, you can issue them all at once if you’re clever, I like to take my time, in case the worlds explodes.

yum install kernel-devel
yum install kernel-headers
yum install libXtst*
yum install xinetd
yum install gcc*

On a couple of occasions, I needed the following package – It could have been when I was using CentOS 5.3 64Bit

yum install libXdmcp-devel
yum install libXrender*

What does the ‘*’ mean? It means grab any packages that start with ‘anytextbeforethe*’

Installed all the packages? Fantastic! Lets reboot the server and start the next step afresh.

shutdown -r now

Install VMware Server 1.0.9

How you get the installation package of VMware Server 1.0.9 onto your server is up to you. Here are a few tips.

• Download VMware Server 1.0.9 Here or Here
• Make sure you register for a VMware Server serial number or numbers. It’s free.
• You can use WinSCP to transfer VMware Server 1.0.9. to your server (it uses SSH). Get it Here or Here.
• You could use the wget command with the direct link above, directly on your server, like this:
  • wget -c http://download3.vmware.com/software/vmserver/VMware-server-1.0.9-156507.i386.rpm
• Burn it to a CD
• Burn it to a DVD
• Transfer it to a USB Drive

Once you have the VMware Server 1.0.9 installation file on your server, installing is pretty straight forward. If you’ve never installed a RPM file before, pay attention, people go to university for this stuff. Make sure you are logged in as root, and issue the following:

rpm -ivh VMware-server-1.0.9-156507.i386.rpm

Easy, no?

Depending on the power of your server, it may take a few minutes to install. Once installed, we have one last final step. No need to reboot this time!

Configuring VMware Server 1.0.9

Issue the following command. If some or none of the required packages are not installed, this will tell you straight away.

vmware-config.pl

or if you are so inclined:

/usr/bin/vmware-config.pl

Both do the exact same thing. Don’t run both (either by concatenating them both together or one after the other), that would just be silly and make you leave a comment about how you ran both and got an error message.

NB: If you are told that some packages or components are missing, I suggest going back and re-issuing the ‘yum’ commands above in the section ‘Install VMware Server 1.0.9 Required Components‘. Before you issue any commands, press ctrl-c to quit the setup program and return to the command prompt.

If you see something like the following, you are good to go:

Making sure services for VMware Server are stopped.

Stopping VMware services:
   Virtual machine monitor                                 [  OK  ]

You must read and accept the End User License Agreement to continue.
Press enter to display it.

The configuration settings of VMware Server 1.0.9 is now up to you. Here are a few tips:

• Accept the agreement, type Y or Yes and press the enter key.
• The defaults are all fine.
• In most cases, Bridged networking is what you are after, so say ‘No’ to host only and NAT (unless you know what they are and you are going to use them)
• Sometimes the installation would tell me that port 902 is unavailable. This is not true. Override by typing in 902, otherwise you’ll need to remember 904 (or whatever other number you select) and type it in every time when you use the VMware Server 1.0.9 client. Not cool.
• At the very least, choose your own location for the storage of VMware Server 1.0.9 servers. I always put mine in /home/vmware (because I have /home on a separate partition)
• Put your Serial Key in now, rather than later.

Installation and Configuration is now complete! If you need any further help / assistance, please, feel free to leave a comment

My Predicament.
A server (a Dell SC440), with two physical network interfaces. Our office has two ISP connections (DSL broadband). We have the one internal network range (192.168.1.0/24) with two gateways (1.254 and 1.221).

I have installed Promox on the server. I wanted to be able to choose which gateway the guest containers used, instead of them being locked into using the same gateway as the host server. Some of the guest OS containers will host services via the first ISP, and the others will host services via the second ISP. (obviously with firewall rules etc configured in our gateways). So the container gateway entries need to point to their respective ISP/Gateway.

Note: While the security advantage of venet over veth is certainly worthwhile in a hosting environment (and others as well), in my case, we have two hardware firewalls that haven’t let us down yet, and there is little to no concern for the possibility of an internal hacker (there are only three of us!)

Solution 1. Requires the most effort, but gives the most flexibility.

I decided to configure the host with a vmbr0 device that contains a bond0 device, that contains devices eth0 and eth1 (you can look at the video tutorials on pve.proxmox.com for anyone unsure of how to create a bond0) – I configured the bond0 with an IP address that matches our office network (this address doesn’t matter in regards to the containers, just makes the host easy to access if it’s on the same network).

Creating the network bond is meaningless (except for redundancy reasons), so long as you end up with an accessible vmbrX device, that contains either ethX or bondX, you’re good to go. Bonding network devices in linux is close to using the ‘join to network bridge’ feature available in Windows 2000/XP/Vista/7 when you have two similiar Ethernet network devices.

When creating a new container in the web interface, instead of choosing Virtual Network (venet) choose Bridged Ethernet (veth) instead.

It has been pointed out to me, that veth is not as secure as venet (which is true), however veth does give your guest container OS direct access to the network, in a smiliar fashion to the way VMware server can give a guest OS direct access to a physical network using Bridged Ethernet.

Once your guest OS container is up and running, you’ll need to use the “Open VNC Console” link on the container’s General page, in the proxmox web interface, to get console access to the container, so that you can manually configure your network interfaces. Instead of configuring venet0:0 or similiar devices, you’ll be back to configuring eth0 or similiar devices. In CentOS, these turn out to be ifcfg-eth0 and ifcfg-lo. If you are unsure of how to do this manually, I suggest googling for some answers, or in CentOS, you can use a tool (if it’s available in your guest OS template) called system-config-network-tui. It’s available via Yum if you don’t have it.

Easy way to get it
1. Create a container with CentOS
2. Assigned it an IP Address using Virtual Network (venet)
3. Login via the VNC console or SSH and issue: yum install system-config-network-tui
4. Logout
5. Use the Proxmox web interface to shutdown the container
6. Remove the Virtual Network Adapter (venet) by deleting the IP Address and clicking Save.
7. The page will refresh and you can now select vmbr0 from the Bridged Ethernet Devices section. Click Save.
8. Start your container
9. Login via VNC Console and issue: system-config-network-tui
10. You’re on your own from here. Remember, you need to configure eth0 not venet0 and venet0:0 – you may want to remove these. Don’t forget to set your gateway and edit your DNS
11. Restart your network with /etc/init.d/network restart

Solution 2. Requires less effort, doesn’t necassarily give as much flexibility, but increases security.

You can edit your /etc/network/interfaces file on the host (the server with Proxmox installed). It’s actually kinda easy. This option also lets you avoid having to edit the network settings inside your guest container OS. So you can create plenty of containers, without have to edit each one! Neat!

Remember: I have two Gateways. 1.254 and 1.221 and my server has two network interfaces.

I could configure each of the network interfaces with two different networks. For example: NIC1: 192.168.1.0/24 with a gateway of 192.168.1.254 and NIC2: 192.168.4.0/24 with a gateway of 192.168.4.254.

There is no point in configuring both interfaces with the same network, for example: NIC1: 192.168.1.200 with a gateway of 192.168.1.254 and NIC2: 192.168.1.205 with a gateway of 192.168.1.221. The host (and consequently any guest container OS) will always use the gateway configured in eth0). If there is a way around this, I wasn’t able to figure it out.

By configuring each NIC with a separate network (192.168.1.0/24 and 192.168.4.0/24), I can make a guest container OS use the gateway of the 192.168.4.0/24 network, by giving it an IP Address like: 192.168.4.54, or make a guest container OS use the gateway of the 192.168.1.0/24 network, by giving it an IP Address like: 192.168.1.54.

However, we’re not done yet. Here’s how you do it. In the Web Interface, I again configured my network as follows. This could be done in a variety of ways, so long as you end up with a vmbr0.

I created a bond0, that contained eth0 and eth1. I then created a vmbr0 that contained bond0. I set the IP address of vmbr0 to 192.168.1.230 – so I could access it again after reboot. I didn’t configure IP Addresses anywhere else.

After rebooting, I edited my /etc/network/interfaces file

On the host I issused: nano /etc/network/interfaces (I love nano, I know it’s for noobs but I can’t get my head around vi, I’ve used nano for too long!)

At the bottom of my /etc/network/interfaces file I added

auto vmbr0:0
iface vmbr0:0 inet static
address 192.168.4.100
netmask 255.255.255.0
gateway 192.168.4.254

auto vmbr0:1
iface vmbr0:0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.254

DNS can be configured individually for each container using the proxmox web interface, or in my case of using CentOS, by editing the resov.conf file inside my guest container OS. Do what is easiest for you. You can also use system-config-network-tui.

Once I had modified by /etc/network/interfaces file, I saved and than restarted the network service by issuing: /etc/init.d/networking restart

I next created guest OS containers, with IP addresses that matched the network of the gateway that I wanted to use. In this situation, the guest container OS’s can also commuinicate with each other, even though they may be using different networks, thanks to the host. Handy, no?

In the end for me, I am using Solution 1. Mainly because we are not running a hosting company, rather just running services on our network and migrating away from VMware, so configuring network settings manually in this case, isn’t a big issue. In the proxmox web interface, I added the IP Address of each container, into the comments section for future reference.

If I was to use Solution 2, in our case we would have to change the IP Address of not only the gateway, but also many other devices also currently using the 192.168.1.0/24 network. We would inevitibly have to implement a routing solution to allow nodes on each network (1.0 and 4.0), to communicate with devices on either network, as is the case with most devices communicating with each other now.

As I said above, this is not necassarily the best or only solution, it is however what I was able to come up with. Comments, suggestions and improvements are welcome.

If someone can help me get the security of using venet instead of veth (and manually configuring the containers) and be able to get each of my containers to use one gateway or the other, all on the one network, without having to edit the container network settings, well then that would be awesome!