Apr 11

In my previous post I told you about some guides for installing vanilla Gentoo containers in a OpenVZ virtualization system. This time I’ll try to collect those things missing in template.

Preparation

If you have created a Gentoo template yourself, you probably have an existing tree in /vz/private/777 and may skip this preparation. If you were starting with the template provided in linked post you’ll need to extract that now so it’s available for extension.

Untar the template file into the folder named before

# mkdir -p /vz/private/777
# tar xzf /vz/template/cache/gentoo.tar.gz -C /vz/private/777

Things to Do Before Instantiating Your Template

Setting Time Zone

Select your timezone from /usr/share/zoneinfo and copy the related file into /etc/localtime. As a resident of Germany I choose Europe/Berlin.

# cp /vz/private/777/usr/share/zoneinfo/Europe/Berlin /vz/private/777/etc/localtime

Setting Name Servers

Unless you intend to use DHCP in instances of your Gentoo template to setup network and DNS system you should copy record on nameservers used by your host (CT0). This is best practice since they are made available to your server probably providing least response times.

# cp -L /etc/resolv.conf /vz/private/777/etc

Prepare Localization

Adding variable LINGUAS to make.conf is somewhat essential as it affects the way software is compiled in Gentoo. If you forget to add it later, some software might lack support for your language unless it is being recompiled.

# echo 'LINGUAS="de"' >> /vz/private/777/etc/make.conf

Since there is a lot more to be done for localizing Gentoo you should read available tutorials on that. Most other option have little impact on software compilation and thus might be set in guest instances later …

Enter Template Container

Upcoming steps are in context of your template container. Thus you need to start and enter it:

# cd /
# vzctl set 777 --ipadd aaa.bbb.ccc.ddd --save

The initial cd is required to prevent failures on container startup.

The second command above is assigning static IP address for the guest’s NIC. You might omit it unless you plan to emerge software in your template container. Saving this configuration doesn’t affect your template or any instances of it created later. Of course you must replace the sequence aaa.bbb.ccc.ddd by a static IP address routed to your host server. It must not be the one assigned to your host system’s NIC.

After starting your guest it’s being entered finally:

# vzctl start 777
# vzctl enter 777

Select Profile

First of all select your favourite profile. Available profiles are listed using:

# eselect profile list

Then select one and replace “<no>” in the following command by the number found to the left of your selection

# eselect profile set <no>

Enable sshd

For remote logins sshd must be started on system boot.

# rc-update add sshd default

Important! Don’t start the sshd in template container now as it would create a pair of server keys shared by all instances created from this template resulting in a very weak set of servers.

Enable nscd

To reduce network load you should always have a name service cache daemon.

Of course there are other opportunities like having a DNS proxy/cache daemon on host to be shared by all running containers. In such cases you won’t need another nscd instance per guest and thus should omit this step.

# rc-update add nscd default

Install System Logger and Cron Daemon

The vanilla Gentoo includes neither syslog nor cron daemon. This is obviously due to offering different variants of either system. For syslog replacement I prefer metalog for its highly flexible configuration. For cron I’m used to choose vixie-cron without any expressable reason.

# emerge -av vixie-cron metalog
# rc-update add metalog default
# rc-update add vixie-cron default

Fix Loss of Connections and Disable Root Logins in SSH

By default sshd tends to drop idle connections. If you are going to invoke processes that take some time to complete without producing any output then sshd might happen to quietly drop your connection. There is an option available on sshd server to prevent that. In file /etc/ssh/sshd_config look for a line reading

#ClientAliveInterval 0

and change it to

ClientAliveInterval 60

Next disable root logins in same file by looking for a line reading

#PermitRootLogin yes

and changing it to

PermitRootLogin no

For increased security you should never permit root to log in directly. May brute force attackers have a tough time of it with guessing the password.

Note! If something is wrong or different with your setup this step might lock you out of your remote guest server, later. However, that doesn’t matter as it applies to connecting to it over SSH, only. It doesn’t affect entering the guest using vzctl from a connection to the host server.

Install Further Software

Though you might install even more software in your template using emerge you should obey rule to keep it as small and simple as possible.

Deploy your template

Leave the template container now by pressing Ctrl+D.

Stop the guest now:

# vzctl stop 777

Recompile the archive actually serving as template:

# cd /vz/private/777
# tar --numeric-owner -czf /vz/template/cache/gentoo.tar.gz *

Things to Do to Instantiate Your Template

With your template put into right location creating another virtual server instance is as simple as this:

# vzctl --create <newctid> --config gentoo --ipadd aaa.bbb.ccc.ddd --hostname newhostname

This is copying your template archive into /vz/private/<newctid>. “<newctid>” is a VM number not in use recently and will be used instead of 777 to select your freshly created VM in succeeding calls to vzctl. The argument to parameter –config is “gentoo” since that’s the name of template archive created before.

Things to Do After Instantiating Your Template

Whenever you create an instance using this template some further steps are required in any case.

Since you are working on an instance of your template, the container ID has changed from 777 to some different integer value. Replace occurrences of “<ctid>” by that new ID in upcoming command invocations.

Start Guest

# vzctl start <ctid>

Update Memory Configuration

Compiling upgrades and new software from source in Gentoo is consumes a lot of memory. Therefore it’s obviously required to update current amount of provided memory. However configuring memory is anything but straight-forward in OpenVZ. See the Wiki and Google for available tutorials on how memory management is configured in OpenVZ.

Please don’t copy the following setup without understanding what it’s doing to your (virtual and physical) servers.

In this example we permit 2 GiByte of RAM with peaks at 2.5 GiByte, thus adjusting barrier and limit of privvmpages beancounter:

# vzctl set <ctid> --privvmpages 524288:640000 --save

Assuming a memory page size of 4096 Bytes it’s resulting in 524288 * 4096 =2147483648 Bytes = 2GiBytes and 640000 * 4096 = 2.5GiBytes.

Update Disk Quota

The virtual server’s filesystem is basically limited in size by a quota. For Gentoo that quota mustn’t be too little and thus you’ll need to increase it.

# vzctl set <ctid> --diskspace 10G:12G --save

This is going to update your new VM’s filesystem limit in size by means of used bytes. But it doesn’t affect another limit regarding maximum number of inodes. Assuming a minimum size of 4096 bytes per inode your VM might contain small files, only. With a default limit on inodes of 200000 this results in about 780 MB usable space in filesystem. Thus you should update the related option as well. The simplified formula for deriving number of inodes from set limit in size (in GiByte) is 256*1024*<set limit>, thus for 10G it is 256 * 1024 * 10 = 2621440:

# vzctl set <ctid> --diskinodes 2621440:3145728 --save

Note! Updating disk quotas and inodes requires restarting your updated VM. Thus, as it’s running while adjusting these options you need to stop/start it once:

# vzctl stop <ctid> && vzctl start <ctid>

Set a Root Password

The Proposed Way

Invoke the following command to assign an individual root password to your created guest:

# vzctl set <ctid> --userpasswd 'root:secret'

with the word “secret” replaced by a password of your choice. The surrounding single quotes are used to support special characters such as $ and | in your password.

Entering this command with the password included as argument there is a small security vulnerability as this command might be visible in process accounting as well as in bash history of your host’s root user account. While the first is temporary the second is kept in a file on your host. After invoking the command you should either remove the file .bash_history in your home directory or try these steps

  1. press cursor up key once to return to the command in history
  2. press backspace to drop most (not all) entered characters
  3. press cursor down key once again returning to empty command line
  4. enter some harmless command like ls to have history written back to file for sure
  5. check history again for not including entered password anymore

The Preferred Way

For preventing the security issues of proposed way above there is another approach by entering VM and changing the password from inside:

# vzctl enter <ctid>
$ passwd
$ logout

Enter Guest

Entering guest VM this way is providing similar context to logging into it over SSH or similar. Due to operating at root level inside VM you shouldn’t use it in production setup, but for maintenance in case of SSH being unavailable.

# vzctl enter <ctid>

Create Unprivileged User

Since logging in as root has been disabled there must be one unprivileged user for basically logging in. Additionally it should be enabled to become root using su or sudo. Thus create an unprivileged user and let it join group “wheel”. To hush even more any leftover fears you shouldn’t have login names like bob or alice but names consisting of letters and digits.

# useradd -m -G wheel unus1w
# passwd unus1w

As usual, provide that user’s password twice.

This is the time for double-checking your sudo configuration. Ensure members of group wheel are enabled to become superuser (root):

# visudo

There must be a line matching the following one (ensure there isn’t any hash sign at the beginning of that line!):

%wheel ALL=(ALL) ALL

Updating Software

The template has been created some time in the past and as software is evolving each and every day you should update the system’s software now:

# emerge --sync
# emerge -NuDav world

This will try your patience depending on your servers’ resources as it might take hours to update your system, but after that you’re done.

unus1w

Comments are closed.

preload preload preload