Beginning with Ubuntu 12.10, it is possible to define hooks to be executed at specific points in a container’s lifetime:
• Pre-start hooks are run in the host’s namespace before the container ttys, consoles, or mounts are up.
If any mounts are done in this hook, they should be cleaned up in the post-stop hook.
• Pre-mount hooks are run in the container’s namespaces, but before the root filesystem has been mounted. Mounts done in this hook will be automatically cleaned up when the container shuts down.
• Mount hooks are run after the container filesystems have been mounted, but before the container has called pivot_root to change its root filesystem.
• Start hooks are run immediately before executing the container’s init. Since these are executed after pivoting into the container’s filesystem, the command to be executed must be copied into the container’s filesystem.
• Post-stop hooks are executed after the container has been shut down.
If any hook returns an error, the container’s run will be aborted. Anypost-stop hook will still be executed.
Any output generated by the script will be logged at the debug priority.
Please see the lxc .container.conf(5) manual page for the configuration file format with which to specify hooks. Some sample hooks are shipped with the lxc package to serve as an example of how to write and use such hooks.
Consoles
Containers have a configurable number of consoles. One always exists on the container’s /dev/console. This is shown on the terminal from which you ran lxc−start, unless the -d option is specified. The output on /dev/console can be redirected to a file using the-c console-file option to lxc−start. The number of extra consoles is specified by the lxc . tty variable, and is usually set to 4. Those consoles are shown on /dev/ttyN (for 1 <= N <= 4). To log into console 3 from the host, use:
sudo l x c−c o n s o l e −n c o n t a i n e r −t 3
or if the−t N option is not specified, an unused console will be automatically chosen. To exit the console, use the escape sequence Ctrl−a q. Note that the escape sequence does not work in the console resulting from lxc−start without the−d option.
Each container console is actually a Unix98 pty in the host’s (not the guest’s) pty mount, bind-mounted over the guest’s /dev/ttyN and /dev/console. Therefore, if the guest unmounts those or otherwise tries to access the actual character device 4:N, it will not be serving getty to the LXC consoles. (With the default settings, the container will not be able to access that character device and getty will therefore fail.) This can easily happen when a boot script blindly mounts a new /dev.
Troubleshooting
Logging
If something goes wrong when starting a container, the first step should be to get full logging from LXC:
sudo l x c−s t a r t −n C1 −l t r a c e −o debug . out
This will cause lxc to log at the most verbose level, trace, and to output log information to a file called
‘debug.out’. If the file debug.out already exists, the new log information will be appended.
Monitoring container status
Two commands are available to monitor container state changes. lxc−monitor monitors one or more con-tainers for any state changes. It takes a container name as usual with the -n option, but in this case the container name can be a posix regular expression to allow monitoring desirable sets of containers. lxc−
monitor continues running as it prints container changes. lxc−wait waits for a specific state change and then exits. For instance,
sudo l x c−monitor −n c o n t [0−5]*
would print all state changes to any containers matching the listed regular expression, whereas sudo l x c−w a i t −n c o n t 1 −s ’STOPPED|FROZEN’
will wait until container cont1 enters state STOPPED or state FROZEN and then exit.
Attach
As of Ubuntu 14.04, it is possible to attach to a container’s namespaces. The simplest case is to simply do sudo l x c−a t t a c h −n C1
which will start a shell attached to C1’s namespaces, or, effectively inside the container. The attach func-tionality is very flexible, allowing attaching to a subset of the container’s namespaces and security context.
See the manual page for more information.
Container init verbosity
If LXC completes the container startup, but the container init fails to complete (for instance, no login prompt is shown), it can be useful to request additional verbosity from the init process. For an upstart container, this might be:
sudo l x c−s t a r t −n C1 / s b i n / i n i t l o g l e v e l=debug
You can also start an entirely different program in place of init, for instance sudo l x c−s t a r t −n C1 / b i n / bash
sudo l x c−s t a r t −n C1 / b i n / s l e e p 100
sudo l x c−s t a r t −n C1 / b i n / c a t / p r o c /1/ s t a t u s
LXC API
Most of the LXC functionality can now be accessed through an API exported by liblxc for which bindings are available in several languages, including Python, lua, ruby, and go.
Below is an example using the python bindings (which are available in the python3-lxc package) which creates and starts a container, then waits until it has been shut down:
# sudo python3
Python 3 . 2 . 3 ( d e f a u l t , Aug 28 2 0 1 2 , 0 8 : 2 6 : 0 3 ) [GCC 4 . 7 . 1 20120814 ( p r e r e l e a s e ) ] on l i n u x 2
Type ” h e l p ” , ” c o p y r i g h t ” , ” c r e d i t s ” o r ” l i c e n s e ” f o r more i n f o r m a t i o n .
>>> import l x c
__main__ : 1 : Warning : The python−l x c API i s n ’ t y e t s t a b l e and may change a t any p o i n t i n t h e f u t u r e .
>>> c=l x c . C o n t a i n e r ( ” C1 ” )
>>> c . c r e a t e ( ” ubuntu ” ) True
>>> c . s t a r t ( ) True
>>> c . w a i t ( ”STOPPED” ) True
Security
A namespace maps ids to resources. By not providing a container any id with which to reference a resource, the resource can be protected. This is the basis of some of the security afforded to container users. For instance, IPC namespaces are completely isolated. Other namespaces, however, have various leaks which allow privilege to be inappropriately exerted from a container into another container or to the host.
By default, LXC containers are started under a Apparmor policy to restrict some actions. The details of AppArmor integration with lxc are in section Apparmor. Unprivileged containers go further by mapping root in the container to an unprivileged host UID. This prevents access to /proc and /sys files representing host resources, as well as any other files owned by root on the host.
Exploitable system calls
It is a core container feature that containers share a kernel with the host. Therefore if the kernel contains any exploitable system calls the container can exploit these as well. Once the container controls the kernel it can fully control any resource known to the host.
In general to run a full distribution container a large number of system calls will be needed. However for application containers it may be possible to reduce the number of available system calls to only a few. Even for system containers running a full distribution security gains may be had, for instance by removing the 32-bit compatibility system calls in a 64-bit container. See the lxc.container.conf manual page for details of how to configure a container to use seccomp. By default, no seccomp policy is loaded.
Resources
• The DeveloperWorks article LXC: Linux container tools was an early introduction to the use of con-tainers.
• The Secure Containers Cookbook demonstrated the use of security modules to make containers more secure.
• The upstream LXC project is hosted at linuxcontainers.org.
Databases
Ubuntu provides two popular database servers. They are:
• MySQL
• PostgreSQL
Both are popular choices among developers, with similar feature sets and performance capabilities. Histor-ically, Postgres tended to be a preferred choice for its attention to standards conformance, features, and extensibility, whereas Mysql may be more preferred for higher performance requirements, however over time each has made good strides catching up with the other. Specialized needs may make one a better option for a certain application, but in general both are good, strong options.
They are available in the main repository and equally supported by Ubuntu. This section explains how to install and configure these database servers.
MySQL
MySQL is a fast, multi-threaded, multi-user, and robust SQL database server. It is intended for mission-critical, heavy-load production systems and mass-deployed software.
Installation
To install MySQL, run the following command from a terminal prompt:
sudo apt i n s t a l l mysql−s e r v e r
Once the installation is complete, the MySQL server should be started automatically. You can quickly check its current status via systemd:
sudo s e r v i c e mysql s t a t u s �
mysql . s e r v i c e − MySQL Community S e r v e r
Loaded : l o a d e d ( / l i b / systemd / system / mysql . s e r v i c e ; e n a b l e d ; vendor p r e s e t : e n a b l e d )
A c t i v e : a c t i v e ( r u n ni n g ) s i n c e Tue 2019−10−08 1 4 : 3 7 : 3 8 PDT; 2 weeks 5 days ago
Main PID : 2028 ( mysqld ) Tasks : 28 ( l i m i t : 4 9 1 5 )
CGroup : / system . s l i c e / mysql . s e r v i c e ��
2028 / u s r / s b i n / mysqld −−daemonize −−pid−f i l e =/run / mysqld / mysqld . p i d Oct 08 1 4 : 3 7 : 3 6 db . example . o r g systemd [ 1 ] : S t a r t i n g MySQL Community S e r v e r . . . Oct 08 1 4 : 3 7 : 3 8 db . example . o r g systemd [ 1 ] : S t a r t e d MySQL Community S e r v e r . The network status of the MySQL service can also be checked by running the ss command at the terminal prompt:
sudo s s −tap | g r e p mysql
When you run this command, you should see something similar to the following:
LISTEN 0 151 1 2 7 . 0 . 0 . 1 : mysql 0 . 0 . 0 . 0 : *
u s e r s : ( ( ” mysqld ” , p i d =149190 , f d =29) )
LISTEN 0 70 * : 3 3 0 6 0 * : *
u s e r s : ( ( ” mysqld ” , p i d =149190 , f d =32) )
If the server is not running correctly, you can type the following command to start it:
sudo s e r v i c e mysql r e s t a r t
A good starting point for troubleshooting problems is the systemd journal, which can be accessed at the terminal prompt with this command:
sudo j o u r n a l c t l −u mysql
Configuration
You can edit the files in /etc/mysql/ to configure the basic settings – log file, port number, etc. For example, to configure MySQL to listen for connections from network hosts, in the file /etc/mysql/mysql.conf.d/mysqld .cnf, change thebind-addressdirective to the server’s IP address:
bind−a d d r e s s = 1 9 2 . 1 6 8 . 0 . 5 Note
Replace 192.168.0.5 with the appropriate address, which can be determined via ip address show.
After making a configuration change, the MySQL daemon will need to be restarted:
sudo s y s t e m c t l r e s t a r t mysql . s e r v i c e