Red5, OpenLaszlo, ColdFusion, OpenVZ, Joomla

From within a 'broken' CT enter:

mknod -m 666 /dev/random c 1 8
mknod -m 444 /dev/urandom c 1 9


If this doesn't work....Jimmy Tang listed the minimal set of devices nodes:

mknod -m 600 /dev/console c 5 1
mknod -m 666 /dev/tty c 5 0
mknod -m 666 /dev/full c 1 7
mknod -m 600 /dev/initctl p
mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/ptmx c 5 2
mkdir /dev/pts
mknod -m 666 /dev/random c 1 8
mknod -m 444 /dev/urandom c 1 9
mknod -m 666 /dev/zero c 1 5


Reference:
http://www.tchpc.tcd.ie/~jtang/blog/posts/Creating_the_minimum_needed_device_nodes_for_openvz/

On a CentOS 5 HN (hardware node) it seems that the server machine itself crashes after making changes in iptables (e.g. with system-config-securitylevel-tui)! The whole machine hangs and becomes unresponsive.
Luckily this doesn't occur when you make changes in iptables from within a VE (virtual environment).



In order to avoid this problem you'll have to stop your OpenVZ services temporarily, make your firewall changes and restart OpenVZ.


# /etc/init.d/vz stop
# system-config-securitylevel-tui
# /etc/init.d/vz start


This problem didn't occur in older kernels but definitely in vzkernel-2.6.18-53.el5.028stab051.1

You can read a threat about this here: http://forum.openvz.org/index.php?t=msg&goto=21273

SSH returns: "Server refused to allocate pty" upon login.
OR:
"enter into VE 101 failed
Unable to open pty: No such file or directory"


This solution is for CentOS VE's.


At the HN (hardware node) enter (replace 101 with your VE-id / CT-id):

# vzctl exec 101 /sbin/MAKEDEV tty
# vzctl exec 101 /sbin/MAKEDEV pty

Then enter the VE/CT:

# vzctl enter 101


And make sure the udev rpm is gone:
# rpm -e --nodeps udev
...else the problem comes back after a VE reboot.

If the problem persists after reboot, repeat the steps above and create the following file within the VE/CT:

/etc/udev/makedev.d/51-udev.nodes

...with these contents:

# These device have to be created manually
tty0
tty1
tty2
tty3
ttyp0
ttyp1
ttyp2
ttyp3
ptyp0
ptyp1
ptyp2
ptyp3


references:

http://forum.openvz.org/index.php?t=msg&goto=14953
http://wiki.openvz.org/Container_enter_failed

Add the following line to file /root/.bashrc

HISTFILE=/root/.bash_history

Now, .bash_history will be created and filled!

It's a while ago since I've written my last serious article but this one is really worth reading.
The last few months I'm testing the possibilities to make Linux hosting more flexible and less independent on hardware.
As an "Open source CentOS Linux enthusiast" I found OpenVZ. I cite: "OpenVZ is an Operating System-level server virtualization solution, built on Linux. OpenVZ creates isolated, secure virtual environments — VEs (otherwise known as virtual private servers, or VPSs) on a single physical server enabling better server utilization and ensuring that applications do not conflict."

After some tests I managed to get it running properly. Some VE configuration changes are necessary to let a virtual server work with Java JRE in a good manner.

Anyway, there's a tool called "vzdump" (http://wiki.openvz.org/Backup_of_a_running_VE_with_vzdump) to make backups of VEs.

There are 3 backup modes availabe: 1) bad (e.g. vzctl stop 101; vzdump 101; vzctl start 101) 2) better (e.g. vzdump --suspend 101) 3) best (e.g. vzdump --dumpdir /home --snapshot 101)

1 - bad:
==========
Only useful if you first STOP your VE in order to make a backup. Making an online backup without suspending the VE may lead to inconsistent data)

2- better: ========== Sufficient in most cases. Makes an online backup with only a few seconds downtime of the VE. The vzdump tool takes care of stopping and resuming the VE. All services (e.g. Apache) are restored automatically.

3- best:
==========
Makes an backup without any downtime of the VE.




After pulling my hairs out, reading forums and trying all kinds of possibilities I've finally found the solution. In fact, it's quite easy but the lack of documentation makes it hard.

All you need to do is setup a Linux box like this:
- Use LVM2 'volume group' (called 'sysvg') with these 'logical volumes':
* "/", type ext3, size 8 GB for example;
* "/vz", type ext3, size 8 GB for example;
* "/var/freespace", no filesystem required, size at least 512MB;
* "swap", type swap, size 2 times internal memory;

After the Linux installation has finished remove the logical volume freespace by entering the commands: # umount /var/freespace # lvremove /dev/sysvg/freespace

Now the the command 'vzdump --dumpdir /home --snapshot 101' (or likewise) should work!



Let me explain what happens.
Vzdump makes a temporarily logical volume with type "snapshot" of 512MB and mounts it on "/vzsnap". (That's why you need at least 512MB free space in the volume group.)
This snapshot is taken from the logical volume mounted on '/vz'. And that's why all OpenVZ stuff (e.g. /vz and subdirs) needs to be in that '/vz'-logical-volume.
Okay, after vzdump has taken the snapshot of '/vz' all it has to do is travel down to the data of the selected VE and put in a "tar"-file. After this is done, the file will be moved to its final destination (dumpdir) and the temporarily "/vzsnap" will be deleted.



Good luck and let me know if this article is useful for you!



Tip:
You should have at least 512MB free space available in the volume group.
To check this, use vgdisplay and look for "Free PE / Size".