Editing VPS Management (section)

== Misc Linux Items ==

We are overselling hard drive space ... when you configure a linux system with a certain amount of disk space (the default is 4gigs) you do not actually use up 4gigs of space on the system.  The diskspace setting for a user is simply a cap, and they only use up as much space on the actual disk drive as they are actually using.

When you create a new linux system, even though there are some 300 RPMs or so installed, if you run `df -k` you will see that the entire 4gig partition is empty - no space is being used.  This is because the files in their system are "magic symlinks" to the template for their OS that is in /vz/template - however, any changes to any of those files will "disconnect" them and they will immediately begin using space in their system.  Further, any new files uploaded (even if those new files overwrite existing files) will take up space on the partition.

=== Cant change file /etc/sysconfig/network ===
if you see this:

<pre>[root@virt8 root]# vzctl stop 160 ; vzctl start 160
VE is not running
Starting VE ...
VE is unmounted
VE is mounted
Adding IP address(es): 69.55.226.83 69.55.226.84
bash ERROR: Can't change file /etc/sysconfig/network
Deleting IP address(es): 69.55.226.83 69.55.226.84
VE is unmounted
[root@virt8 root]#</pre>

it probably means they no longer have /bin/bash - copy one in for them
 
ALSO: another possibility is that they have removed the `ed` RPM from their system - it needs to be reinstalled into their system.  But since their system is down, this is tricky ...

VE startup scripts used by 'vzctl' want package 'ed' to be available inside VE. So if package 'ed' will be enabled in OS template config and OS template itself VE #827 is based on - this error should be fixed.

yes, it is possible to add RPM to VE while it not running.
Try to do following:

<pre># cd /vz/template/<OS_template_with_ed_package>/
# vzctl mount 827
# rpm -Uvh --root /vz/root/827 --veid 827 ed-0.2-25.i386.vz.rpm</pre>

Usually theres an error, but its ok

Note: replace 'ed-0.2-25.i386.vz.rpm' in last command with actual
version of 'ed' package you have.

----
=== What template is user using ===
So how do I know what template the user has ?  cat their conf file and it is listed in there.  For example, if the conf file has:

<pre>[root@virt12 sbin]# vc 1103
…snip…
OSTEMPLATE="debian-3.0/20030822"
TEMPLATES="mod_perl-deb30/20030707 mod_ssl-deb30/20030703 mysql-deb30/20030707 proftpd-deb30/20030703 webmin-deb30/20030823 "
…</pre>

then they are on debian 3.0, all of their system RPMs are in /vz/template/debian-3.0, and they are using version 20030822 of that debian 3.0 template. Also, they’ve also got additional packages installed (mod_perl, mod_ssl, etc).  Those are also found under /vz/template

----
=== Edits needed to run java ===

Edits needed to run java:

When we first created the VEs, the default setting for privvmpages was 93000:94000 ... which was high enough that most people never had problems ... however, you can;t run java or jdk or tomcat or anything java related with that setting.  We have found that by setting privvmpages to 610000:615000 that java runs just fine.  That is now the default setting. It is exceedingly rare that anyone needs it higher than that, although we have seen it once or twice.

Any problems with java at all - the first thing you need to do is see if the failcnt has raised for privvmpages.

<pre># vzctl start 160
Starting VE ...
vzquota : (error) Quota on syscall for 160: Device or resource busy
Running vzquota on failed for VE 160 [3]</pre>

This is because my pwd is _in_ their private directory - you can't start it until you move out

People seem to have trouble with php if they are clueless newbies.  Here are two common problems/solutions:

no... but i figured it out myself. problem was the php.ini file that came
vanilla with the account was not configured to work with apache (the
ENGINE directive was set to off).

everything else seems fine now.

----

the problem was in the php.ini file.  I noticed that is wasnt showing
the code when it was in an html file so I looked at the php.ini file
and had to change it so it recognized <? tags aswell as <?php tags.

Also, make sure added to httpd.conf
    AddType application/x-httpd-php .php

----
=== Set time zone ===

You can set the time zone:

You can change the timezone by doing this:

 ln -sf /usr/share/zoneinfo/<zone> /etc/localtime

where <zone> is the zone you want in the /usr/share/zoneinfo/ directory.

----
=== Failing shm_open calls ===

Failing shm_open calls:

first, please check if /dev/shm is mounted inside VE.
'cat /proc/mounts' command should show something like this:
 tmpfs /dev/shm tmpfs rw 0 0

If /dev/shm is not mounted you have 2 ways to solve issue:
1. execute following command inside VE (doesn't require VE reboot):
 mount -t tmpfs none /dev/shm
2. add following string to /etc/fstab inside VE and reboot it:
 tmpfs         /dev/shm        tmpfs           defaults        0 0

----

You can have a mounted but not running ve
Just:
 vzctl mount <veid>

----
=== Debian can't get on the network ===
When a debian sys can’t get on the network, and you try:

<pre>vzctl set 1046 --ipadd 69.55.227.117
Adding IP address(es): 69.55.227.117
Failed to bring up lo.
Failed to bring up venet0.</pre>

They probably removed iproute package, which must be the one from swsoft. To restore:
<pre># dpkg -i --veid=1046 --admindir=/vz1/private/1046/root/var/lib/dpkg --instdir=/vz1/private/1046/root/ /vz/template/debian-3.0/iproute_20010824-8_i386.vz.deb
(Reading database ... 16007 files and directories currently installed.)
Preparing to replace iproute 20010824-8 (using .../iproute_20010824-8_i386.vz.deb) ...
Unpacking replacement iproute ...
Setting up iproute (20010824-8) ...</pre>

Then restart their ve

=== CentOS can't get on the network ===

When CentOS system was running, but can't get on the network, they probably updated iproute via yum.

Copy an older version of the iproute rpm to their VPS.

<pre>cp -p /root/iproute/iproute-2.6.32-23.el6.<i686>.rpm /vz2/private/<1527>/fs/root</pre>

Enter their ve, install rpm, restart network, and prevent yum from updating iproute.

<pre>
ve <1527>
rpm -i --force iproute-2.6.32-23.el6.<i686>.rpm
rpm -q iproute
rpm -e <new iproute rpm>
service network restart
echo "exclude=iproute" >>/etc/yum/ip-exclude
echo "include=/etc/yum/ip-exclude" >>/etc/yum.conf
</pre>




----

in a ve i do:

<pre>cd /
du -h .</pre>

and get: 483M    .

i do:

<pre>bash-2.05a# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/vzfs             4.0G  2.3G  1.7G  56% /</pre>

how can this be?

Is it possible that quota file was corrupted somehow? Please try to:   
<pre>vzctl stop <VEID>
vzquota drop <VEID>
vzquota init <VEID>
vzctl start <VEID></pre>

----

How to stop vz from starting after reboot:

 VIRTUOZZO=no 
in 
 /etc/sysconfig/vz

To start: 
 service vz start
(after setting VIRTUOZZO=yes in /etc/sysconfig/vz)

service vz restart will do some kind of 'soft reboot' -- restart all
VPSes and reload modules without rebooting the node

if you need to shut down all VPSes really really fast, run killall -9 init

----

Postfix tip:

You may want to tweak settings: default_process_limit=10

----

* uptime/load that vz users see isn’t what we see- it's their own load
* Vz overwrites resolve.conf on every boot to what’s in ve config file. Also overwrites hostname
* Quotas in vz: set Gid_limit in vz config file and restart ve. Errors leading up to this will be out of files but no inode or space issues. set to 2000 in conf, and restart vz