afonso/core-extra
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

added uname -r check; don't run GUI as root

Browse source
This commit is contained in:
ahrenholz 2010-07-01 14:56:37 +00:00
parent be3c51196c
commit 88afe85dd1
1 changed files with 7 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

9
wiki/Namespaces.wiki
View file

@ -12,7 +12,12 @@ You do not need to patch your kernel in order to use network namespaces. Modern
The development snapshot of CORE supports network namespaces for virtualization and does not require OpenVZ. The next 4.0 release of CORE (July 2010) will feature this support. Until that release is completed you can try the development snapshot: The development snapshot of CORE supports network namespaces for virtualization and does not require OpenVZ. The next 4.0 release of CORE (July 2010) will feature this support. Until that release is completed you can try the development snapshot:
# install Ubuntu 10.04 or 9.10, or Fedora 13 or 12 (namespace support is built-in!) # install Ubuntu 10.04 or 9.10, or Fedora 13 or 12 (namespace support is built-in!) If you already have Linux installed you can check your kernel version to see if it supports network namespace virtualization:
{{{
# Linux kernel version: is this number >= 2.6.27?
$ uname -r
2.6.32-22-generic
}}}
# make sure your system is up to date (fresher kernels are generally better): # make sure your system is up to date (fresher kernels are generally better):
{{{ {{{
# for Ubuntu: you can also use synaptic or # for Ubuntu: you can also use synaptic or
@ -53,7 +58,7 @@ yum install autoconf automake bash bridge-utils ebtables \
sudo make install sudo make install
}}} }}}
# after installing, start the CORE services: `sudo /etc/init.d/core start` # after installing, start the CORE services: `sudo /etc/init.d/core start`
# run the CORE GUI: `sudo core` # run the CORE GUI: `core`
The containers created will access the common host filesystem, except that some directories are private on a per-container basis; these typically contain per-node configuration files, pids, etc. Notice in the quagga configuration above that the directories /usr/local/etc/quagga and /var/run/quagga hold the private state information for quagga. Other applications may need their own private directories, so you will need to manually edit some configuration scripts to enable this. The below tips were suggested on the mailing list: The containers created will access the common host filesystem, except that some directories are private on a per-container basis; these typically contain per-node configuration files, pids, etc. Notice in the quagga configuration above that the directories /usr/local/etc/quagga and /var/run/quagga hold the private state information for quagga. Other applications may need their own private directories, so you will need to manually edit some configuration scripts to enable this. The below tips were suggested on the mailing list: