Ubuntu

We have installed LXD and deployed our first container with it. In this recipe, we will learn various LXD commands that manage the container lifecycle.

Getting ready…

Make sure that you have followed the previous recipes and created your first container.

How to do it…

Follow these steps to manage LXD containers:

Before we start with container management, we will need a running container. If you have been following the previous recipes, you should already have a brand new container running on your system. If your container is not already running, you can start it with the lxc start command:

$ lxc start c1

To check the current state of a container, use lxc list, as follows:

$ lxc list c1

This command should list only containers that have c1 in their name.

You can also set the container to start automatically. Set the boot.autostart configuration option to true and your container will start automatically on system boot. Additionally, you can specify a delay before autostart and a priority in the autostart list:

$ lxc config set c1 boot.autostart true

Once your container is running, you can open a bash session inside a container using the lxc exec command:

$ lxc exec c1 -- bash

root@c1:~# hostname

c1

This should give you a root shell inside a container. Note that to use bash, your container image should have a bash shell installed in it. With alpine containers, you need to use sh as the shell as alpine does not contain the bash shell.

LXD provides the option to pause a container when it's not being actively used. A paused container will still hold memory and other resources assigned to it, but not receive any CPU cycles:

$ lxc pause c1

Containers that are paused can be started again with lxc start.

You can also restart a container with the lxc restart command, with the option to perform a stateful or stateless restart:

$ lxc restart --stateless c1

Once you are done working with the container, you can stop it with the lxc stop command. This will release all resources attached to that container:

$ lxc stop c1

At this point, if your container is an ephemeral container, it will be deleted automatically.

If the container is no longer required, you can explicitly delete it with the lxc delete command:

$ lxc delete c1

There's more…

For those who do not like to work with command line tools, you can use a web-based management console known as LXD GUI. This package is still in beta but can be used on your local LXD deployments. It is available on GitHub at https://github.com/dobin/lxd-webgui .

See also

Get more details about LXD at https://www.stgraber.org/2016/03/19/lxd-2-0-your-first-lxd-container-312/

LXC web panel: https://lxc-webpanel.github.io/install.html

In this recipe, we will look at Samba configuration parameters in order to get optimum performance out of your Samba installation.

Getting ready

You will need root access or an account with sudo privileges.

It is assumed that you have installed the Samba server and it is properly working.

How to do it…

Open the Samba configuration file located at /etc/samba/smb.conf:

$ sudo vi /etc/samba/smb.conf

Add or edit the following options under the global section of the configuration file:

[global]

log level = 1

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 SO_KEEPALIVE

read raw = Yes

write raw = Yes

strict locking = No

oplocks = yes

max xmit = 65535

dead time = 15

getwd cache = yes

aio read size = 16384

aio write size = 16384

use sendfile = true

Save the configuration file and restart the Samba service:

$ sudo service smbd restart

How it works…

The Samba server provides various configuration parameters. It uses TCP sockets to connect with clients and for data transfer. You should compare Samba's performance with similar TCP services such as FTP.

The preceding example lists some commonly used configuration options for Samba. Some of these options may work for you and some of them may not. The latest Samba version ships with default values for these options that work fairly well for common network conditions. As always, test these options one at a time or in a group, and benchmark each modification to get optimum performance.

The explanation for the preceding is as follows:

log level: The default log level is set to 0. Samba produces a lot of debugging information and writing all this to disk is a slow operation. Increasing the log level results in increased logs and poor performance. Unless you are debugging the server, it is good to have the log level set to the lowest value.

socket options: These are the TCP/IP stack level options.

read raw and write raw: These options enable Samba to use large read and writes to a network up to 64 KB in a single request. Some older clients may have issues with raw reads and writes. Check your setup before using these options.

dead time and so_keepalive: These options set periodic checks for dead connections and close such connections and free unused memory.

oplocks: This allows clients to cache files locally and results in overall performance improvement. The default setting disables oplocks.

aio read size and aio write size: This Asynchronous IO (AIO) allows Samba to read and write asynchronously when a file's size is bigger than the specified size values.

You can find various other options and respective explanations in the Samba manual pages. Use the following command to open the manual pages on your server:

$ man smbd

In this recipe, we will learn how to import and export bulk data with MySQL. Many times it happens that we receive data in CSV or XML format and we need to add this data to the database server for further processing. You can always use tools such as MySQL workbench and phpMyAdmin, but MySQL provides command-line tools for the bulk processing of data that are more efficient and flexible.

How to do it…

Follow these steps to import and export bulk data:

To export a database from the MySQL server, use the following command:

$ mysqldump -u admin -p mytestdb > db_backup.sql

To export specific tables from a database, use the following command:

$ mysqldump -u admin -p mytestdb table1 table2 > table_backup.sql

To compress exported data, use gzip:

$ mysqldump -u admin -p mytestdb | gzip > db_backup.sql.gz

To export selective data to the CSV format, use the following query. Note that this will create articles.csv on the same server as MySQL and not your local server:

SELECT id, title, contents FROM articles

INTO OUTFILE ‘/tmp/articles.csv’

FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘”’

LINES TERMINATED BY ‘\n’;

To fetch data on your local system, you can use the MySQL client as follows:

Write your query in a file:

$ nano query.sql

select * from articles;

Now pass this query to the mysql client and collect the output in CSV:

$ mysql -h 192.168.2.100 -u admin -p myblog query.sql > output.csv

The resulting file will contain tab separated values.

To import an SQL file to a MySQL database, we need to first create a database:

$ mysqladmin -u admin -p create mytestdb2

Once the database is created, import data with the following command:

$ mysql -u admin -p mytestdb2 db_backup.sql

To import a CSV file in a MySQL table, you can use the Load Data query. The following is the sample CSV file:

Now use the following query from the MySQL console to import data from CSV:

LOAD DATA INFILE ‘c:/tmp/articles.csv’

INTO TABLE articles

FIELDS TERMINATED BY ‘,’ ENCLOSED BY ‘”’

LINES TERMINATED BY \n IGNORE 1 ROWS;

See also

MySQL select-into syntax at https://dev.mysql.com/doc/refman/5.6/en/select-into.html

MySQL load data infile syntax at https://dev.mysql.com/doc/refman/5.6/en/load-data.html

Importing from and exporting to XML files at https://dev.mysql.com/doc/refman/5.6/en/load-xml.html

Until now, in this article we have learned about various performance monitoring tools and commands. This recipe covers a well-known performance benchmarking tool: Sysbench. The purpose of performance benchmarking is to get a sense of system configuration and the resulting performance. Sysbench is generally used to evaluate the performance of heavy load systems. If you read the Sysbench introduction, it says that Sysbench is a benchmarking tool to evaluate a system running database under intensive load. It is also being used as a tool to evaluate the performance of multiple cloud service providers.

The current version of Sysbench supports various benchmark tests including CPU, memory, IO system, and OLTP systems. We will primarily focus on CPU, memory, and IO benchmarks.

Getting ready

Before using Sysbench, we will need to install it. Sysbench is available in the Ubuntu package repository with a little older (0.4.12) version. We will use the latest version (0.5) from Percona Systems, available in their repo.

To install Sysbench from the Percona repo, we need to add the repo to our installation sources. Following are the entries for Ubuntu 14.04 (trusty). Create a new file under /etc/apt/source.list.d and add the following lines to it:

$ sudo vi /etc/apt/sources.list.d/percona.list

deb http://repo.percona.com/apt trusty main

deb-src http://repo.percona.com/apt trusty main

Next, add the PGP key for the preceding repo:

$ sudo apt-key adv --keyserver keys.gnupg.net --recv-keys 1C4CBDCDCD2EFD2A

Now we are ready to install the latest version of Sysbench from the Percona repo. Remember to update the apt cache before installation:

$ sudo apt-get update

$ sudo apt-get install sysbench

Once installed, you can check the installed version with the --version flag to sysbench:

$ sysbench --version

sysbench 0.5

How to do it…

Now that we have Sysbench installed, let's start with performance testing our system:

Sysbench provides a prime number generation test for CPU. You can set the number of primes to be generated with the option --cpu-max-prime. Also set the limit on threads with the --num-threads option. Set the number of threads equal to the amount of CPU cores available:

$ sysbench --test=cpu --num-threads=4 \

--cpu-max-prime=20000 run

Next, we will run a test for main memory. The memory tests provides multiple options, such as block-size, total data transfer, type of memory operations, and access modes. Use the following command to run memory tests:

$ sysbench --test=memory --memory-block-size=1M \

--num-threads=2 \

--memory-total-size=100G --memory-oper=read run

Following is part of the output from the memory test:

If you have enabled huge page support, set the memory test support allocation from the huge page pool with the parameter, --memory-hugetlb. By default, it's set to off.

Next comes the storage performance test. This test also provides you with a number of options to test disk read write speeds. Depending on your requirements, you can set parameters like block-size, random or sequential read writes, synchronous or asynchronous IO operations, and many more.

For the fileio test we need a few sample files to test with. Use the sysbench prepare command to create test files. Make sure to set a total file size greater than the size of memory to avoid caching effects. I am using a small 1GBnode with 20G disk space, so I am using 15 files of 1G each:

$ sysbench --test=fileio --file-total-size=15G \

--file-num=15 prepare

Once the test preparation is complete, you can run the fileio test with different options, depending on what you want to test. The following command will perform random write operations for 60 seconds:

$ sysbench --test=fileio --file-total-size=15G \

--file-test-mode=rndwr --max-time=60 \

--file-block-size=4K --file-num=15 --num-threads=1 run

To perform random read operations, change --file-test-mode to rndrd, or to perform sequential read operations, use seqrd. You can also combine read write operations with rndrw or seqrewr. Check the help menu for more options.

When you are done with the fileio test, execute the cleanup command to delete all sample files:

$ sysbench --test=fileio cleanup

Once you have gathered various performance details, you can try updating various performance tuning parameters to boost performance. Make sure you repeat related tests after each change in parameter. Comparing results from multiple tests will help you to choose the required combination for best performance and a stable system.

There's more…

Sysbench also supports testing MySQL performance with various tests. In the same way as the fileio test, Sysbench takes care of setting a test environment by creating tables with data. When using Sysbench from the Percona repo, all OLTP test scripts are located at /usr/share/doc/sysbench/tests/db/. You will need to specify the full path when using these scripts. For example:

$ sysbench --test=oltp

The preceding command will change to the following:

$ sysbench --test=/usr/share/doc/sysbench/tests/db/ol1tp.lua

Graphing tools

Sysbench output can be hard to analyze and compare, especially with multiple runs. This is where graphs come in handy. You can try to set up your own graphing mechanism, or simply use prebuilt scripts to create graphs for you. A quick Google search gave me two good, looking options:

A Python script to extract data from Sysbench logs: https://github.com/tsuna/sysbench-tools

A shell script to extract Sysbench data to a CSV file, which can be converted to graphs: http://openlife.cc/blogs/2011/august/one-liner-condensing-sysbench-output-csv-file

More options

There are various other performance testing frameworks available. Phoronix Test Suite, Unixbench, and Perfkit by Google are some popular names. Phoronix Test Suite focuses on hardware performance and provides a wide range of performance analysis options, whereas Unixbench provides an option to test various Linux systems. Google open-sourced their performance toolkit with a benchmarker and explorer to evaluate various cloud systems.

See also

Get more details on benchmarking with Sysbench at https://wiki.mikejung.biz/Benchmarking

Sysbench documentation at http://imysql.com/wp-content/uploads/2014/10/sysbench-manual.pdf

A sample script to run batch run multiple Sysbench tests at https://gist.github.com/chetan/712484

Sysbench GitHub repo at https://github.com/akopytov/sysbench

Linux performance analysis in 60 seconds. A good read for what to check when you are debugging a performance issue at http://techblog.netflix.com/2015/11/linux-performance-analysis-in-60s.html

In this recipe, we will learn how to enable HTTPs communication on the Nginx server.

Getting ready

You will need access to a root account or an account with sudo privileges.

How to do it…

Follow these steps to set HTTPs on Nginx:

Obtain a certificate and the related keys from a certification authority or create a self-signed certificate. To create a self-signed certificate, refer to the Securing web traffic with HTTPS recipe in this article.

Create a directory to hold all certificate and keys:

$ sudo mkdir -p /etc/nginx/ssl/example.com

Move the certificate and keys to the preceding directory. Choose any secure method, such as SCP, SFTP, or any other.

Create a virtual host entry or edit it if you already have one:

$ sudo nano /etc/nginx/sites-available/example.com

Match your virtual host configuration with the following:

server {

listen 80;

server_name example.com www.example.com;

return 301 https://$host$request_uri;

}

server {

listen 443 ssl;

server_name example.com www.example.com;

root /var/www/example.com/public_html;

index index.php index.html index.htm;

ssl on;

ssl_certificate /etc/nginx/ssl/example.com/server.crt;

ssl_certificate_key /etc/nginx/ssl/example.com/server.key;

# if you have received ca-certs.pem from Certification Authority

#ssl_trusted_certificate /etc/nginx/ssl/example.com/ca- certs.pem;

ssl_session_cache shared:SSL:10m;

ssl_session_timeout 5m;

keepalive_timeout 70;

ssl_ciphers "HIGH:!aNULL:!MD5 or HIGH:!aNULL:!MD5:!3DES";

ssl_prefer_server_ciphers on;

ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

add_header Strict-Transport-Security "max-age=31536000";

location / {

try_files $uri $uri/ /index.php;

}

location ~ \.php$ {

include fastcgi_params;

fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;

}

}

Enable this configuration by creating a symbolic link to it under sites-enabled:

$ sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/example.com

Check the configuration for syntax errors:

$ sudo nginx -t

Reload Nginx for the changes to take effect:

$ sudo service nginx reload

Open your browser and access the site with domain or IP with HTTPS.

How it works…

When you know some basic configuration parameters, Nginx is quite simple to set up. Here, we have taken a few SSL settings from the default configuration file and added a simple redirection rule to redirect non-HTTPs traffic on port 80 to port 443. The first server block takes care of the redirection.

In addition to specifying the server certificate and keys, we have enabled session resumption by setting the cache to be shared across the Nginx process. We also have a timeout value of 5 minutes.

All other settings are common to the Nginx setup. We have allowed the virtual host to match with example.com, as well as www.example.com. We have set the index to search index.php, followed by index.html and others. With location directives, we have set Nginx to search for files and directories before forwarding the request to a PHP processor. Note that if you create a self-signed certificate, you will notice your browser complaining about invalid certification authority.

See also

Nginx HTTPs guide at http://nginx.org/en/docs/http/configuring_https_servers.html

Up to now in this article, we have worked with the Git command line interface (CLI). It is a very flexible and powerful interface. This recipe covers the installation of a web interface for Git repositories. We will install GitLab, an open source self-hosted Git server. Through GitLab, you can do most administrative tasks, such as creating new repositories, managing access rights, and monitoring history. You can easily browse your files or code and quickly make small edits. GitLab is also adding support for collaboration tools.

Getting ready

You will need access to a root account or an account with sudo privileges

Make sure you check out the minimum requirements for installation. You can use a single core 1 GB server for an installation with less than 100 users. An server with 2 cores and 2 GB RAM is recommended.

Also check the available disk space. The installer itself takes around 400 MB of disk space.

How to do it…

We will use the recommended Omnibus Package Installer. It provides a .deb package for Debian/Ubuntu systems. Additionally, the omnibus installation takes care of housekeeping tasks such as restarting the worker process to maintain memory use. If you choose to follow the manual installation process, you can get the detailed installation guide from the GitLab documentation:

First, we will need to download the installer package. Download the latest installer package from the GitLab download page at https://packages.gitlab.com/gitlab/gitlab-ce :

$ wget https://packages.gitlab.com/gitlab/gitlab-ce/packages/ubuntu/xenial/gitl...

Once download completes, install GitLab using the dpkg command, as follows:

$ sudo dpkg -i gitlab-ce_8.7.1-ce.1_amd64.deb

After installation, use the following command to configure GitLab:

$ sudo gitlab-ctl reconfigure

Optionally, check the system status with the gitlab-ctl status command. It should return a list of processes and their respective PIDs, as follows:

ubuntu@ubuntu:~$ sudo gitlab-ctl status

[sudo] password for ubuntu:

run: gitlab-workhorse: (pid 806) 57803s; run: log: (pid 805) 57803s

run: logrotate: (pid 31438) 202s; run: log: (pid 810) 57803s

run: nginx: (pid 813) 57803s; run: log: (pid 812) 57803s

run: postgresql: (pid 817) 57803s; run: log: (pid 811) 57803s

Then, open your browser and point it to your server IP or hostname. You will be asked to set a new password for the administrator account. Once you set a new password, use root as the username and your password to login.

How it works…

GitLab is a Ruby-based web application that provides centralized hosting for your Git repositories. We have installed an open source community edition of GitLab using their Omnibus installer. It is an integrated installer package that combines all dependencies and default settings. The installer combines Nginx, Redis, Sidekiq, Unicorn, and PostgreSQL. Unfortunately, the community edition with the Omnibus installer does not support switching to the MySQL database server. To use MySQL, you need to follow the manual installation process and compile GitLab from source, along with other various dependencies.

The configuration file is located at /etc/gitlab/gitlab.rb. It is quite a lengthy file and contains numerous parameters, separated by each component. Some important settings to look at include external_url, where you can set your domain name, database settings, if you are planning to use external PostgreSQL setup, and email server settings, to set up your outgoing email server. If you choose to modify any settings, you will need to reconfigure the installation using the gitlab-ctl reconfigure command. You can get a list of enabled configurations using the gitlab-ctl show-config command.

The GitLab Omnibus package ships with some extra components: GitLab CI, a continuous integration service, and GitLab mattermost, an integrated installation of mattermost that provides an internal communication functionality with a chat server and file sharing. GitLab CI is enabled by default and can be accessed at http://ci.your-gitlab-domain.com. You can enable mattermost from the configuration file and then access it at http://mattermost.your-gitlab-domain.com.

There's more…

Git provides an inbuilt web interface to browse your repositories. All you need is a repository, web server, and the following command:

$ git instaweb --httpd apache2 # defaults to lighttpd

You can access the page at http://server-ip:1234

Check the GitWeb documentation for more details at https://git-scm.com/docs/gitweb .

See also

Check out the requirements for GitLab installation: https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/requirements.md .

Network Time Protocol (NTP) is a TCP/IP protocol for synchronizing time over a network. Although Ubuntu has a built-in clock that is helpful for keeping track of local events, it may create issues when the server is connected over a network and provides time-critical services to the clients. This problem can be solved with the help of NTP time synchronization. NTP works by synchronizing time across all servers on the Internet.

NTP uses hierarchies of servers with top-level servers synchronizing time with atomic clocks. This hierarchy levels are known as stratum, and the level can range between 1 and 15, both inclusive. The highest stratum level is 1 and is determined by the accuracy of the clock the server synchronizes with. If a server synchronizes with other NTP server with stratum level 3, then the stratum level for this server is automatically set to 4.

Another time synchronization tool provided by Ubuntu is ntpdate, which comes preinstalled with Ubuntu. It executes once at boot time and synchronizes the local time with Ubuntu's NTP servers. The problem with ntpdate is that it matches server time with central time without considering the big drifts in local time, whereas the NTP daemon ntpd continuously adjusts the server time to match it with the reference clock. As mentioned in the ntpdate manual pages (man ntpdate), you can use ntpdate multiple times throughout a day to keep time drifts low and get more accurate results, but it does not match the accuracy and reliability provided by ntpd.

In this recipe, we will set up a standalone time server for an internal network. Our time server will synchronize its time with public time servers and provide a time service to internal NTP clients.

How to do it…

Following are the steps to install and configure NTP daemon:

First, synchronize the server's time with any Internet time server using the ntpdate command:

$ ntpdate -s ntp.ubuntu.com

To install ntpd, enter the following command in the terminal:

$ sudo apt-get install ntp

Edit the /etc/ntp.conf NTP configuration file to add/remove external NTP servers:

$ sudo nano /etc/ntp.conf

Set a fallback NTP server:

server ntp.ubuntu.com

Block any external access to the server, comment the first restrict line, and add the following command:

restrict default noquery notrust nomodify

Allow the clients on local network to use the NTP service:

restrict 192.168.1.0 mask 255.255.255.0

Save changes with Ctrl + O and exit nano with Ctrl + X.

Reload the NTP daemon with the following command:

$ sudo service ntp restart

How it works…

Sometimes, the NTP daemon refuses to work if the time difference between local time and central time is too big. To avoid this problem, we have synchronized the local time and central time before installing ntpd. As ntpd and ntpdate both use the same UDP port, 123, the ntpdate command will not work when the ntpd service is in use.

After installing the NTP server, you may want to set time servers to be used. The default configuration file contains time servers provided by Ubuntu. You can use the same default servers or simply comment the lines by adding # at the start of each line and add the servers of your choice. You can dig into http://www.pool.ntp.org to find time servers for your specific region. It is a good idea to provide multiple reference servers, as NTP can provide more accurate results after querying each of them.

Additionally, we have set a fallback server that can be used in case of network outage or any other problems when our server cannot communicate with external reference servers. You can also use a system clock as a fallback, which can be accessed at 127.127.1.0. Simply replace the fallback server with the following line to use a system clock as a fallback:

server 127.127.0.1

Lastly, we have set access control parameters to protect our server from external access. The default configuration is to allow anyone to use the time service from this server. By changing the first restrict line, we blocked all external access to the server. The configuration already contains the exception to local NTP service indicated by the following:

restrict 127.0.0.1

We created another exception by adding a separate line to allow access to the clients on local network (remember to replace the IP range with your network details):

restrict 192.168.1.0 mask 255.255.255.0

There's more…

A central DHCP server can be configured to provide NTP settings to all DHCP clients. For this to work, your clients should also be configured to query NTP details from DHCP. A DHCP client configuration on Ubuntu already contains the query for network time servers.

Add the following line to your DHCP configuration to provide NTP details to the clients:

subnet 192.168.1.0 netmask 255.255.255.0 {

...

option ntp-servers your_ntp_host;

}

On the clientside, make sure that your dhclient.conf contains ntp-servers in its default request:

request subnet-mask, broadcast-address, time-offset, routers,

...

rfc3442-classless-static-routes, ntp-servers,

See also

Check the default /etc/ntp.conf configuration file. It contains a short explanation for each setting.

Check the manual pages for ntpd with man ntpd.

A streaming client needs to get the details of the media available on the streaming server. The client needs to authenticate with server access the catalog and list of songs and even request offline access to store media locally. With Ampache, we can use its REST and XML APIs. Through these APIs, clients can communicate with Ampache. You can even write your own client tool using any of the supported APIs.

This recipe covers the setup process for streaming content to remote devices. As of writing this, Ampache allows all users to use all available APIs. We will learn how to modify this setting and configure it to limit access based on user accounts.

Getting ready

Open Ampache in your browser and log in with admin credentials.

How to do it…

We will create a separate user account for remote streaming. From the Ampache homepage, click on the admin icon in the top-left corner and then click on the Add User link from the User Tools section. An add user menu will be shown that looks like this:

Fill in the Username, E-mail, and Password fields for the new user account and set User Access to User.

Click the Add User button to create this user and then click Continue.

We will use this new user account to log in from the remote client.

Next, we need to configure access rights and allow this user to use APIs to stream music.

Click on the admin icon and then click on the Add ACL link under the Access Control section.

Set the name for this access control list.

Set level to Read/Write.

Set the user to the user account created in the previous step.

Set ACL type to Stream Access.

Set the start and end IP addresses to 0.0.0.0 and 255.255.255.255 respectively.

Click Create ACL to save the settings.

Click on the Add ACL link again and repeat the preceding settings, except, for ACL Type that choose API/RPC.

Now you can use Ampache streaming from your mobile client. When asked for your username and password, use our new user account, and for the streaming server URL, use your Ampache FQDN followed by /ampache, for example:

http://myampachehost.com/ampache

If your client needs an API key, you can generate one from the User Tools section.

Click on the Browse Users link and then select the user account in question. Click the edit icon to update user details and then click on the generate API key icon.

Finally, click the Update User button to save your changes.

How it works…

By default, the Ampache server creates an Access Control List that allows all access to all users. It is a good idea to create a separate user and grant only the required permissions. Here, we have created a new user account with access to the REST API and to stream content. This will allow better control over users and content, as well as allow us to set various user-specific default settings, such as default bitrate and encoding formats.

While installing Ubuntu, we add a primary user account on the server; if you are using the cloud image, it comes preinstalled with the default user. This single user is enough to get all tasks done in Ubuntu. There are times when you need to create more restrictive user accounts. This recipe shows how to add a new user to the Ubuntu server.

Getting ready

You will need super user or root privileges to add a new user to the Ubuntu server.

How to do it…

Follow these steps to create the new user account:

1. To add a new user in Ubuntu, enter following command in your shell:

   $ sudo adduser bob

2. Enter your password to complete the command with sudo privileges:
3. Now enter a password for the new user:
4. Confirm the password for the new user:
5. Enter the full name and other information about the new user; you can skip this part by pressing the Enter key.
6. Enter Y to confirm that information is correct:.

This should have added new user to the system. You can confirm this by viewing the file /etc/passwd:

How it works…

In Linux systems, the adduser command is higher level command to quickly add a new user to the system. Since adduser requires root privileges, we need to use sudo along with the command, adduser completes following operations:

1. Adds a new user.
2. Adds a new default group with the same name as the user.
3. Chooses UID (user ID) and GID (group ID) conforming to the Debian policy.
4. Creates a home directory with skeletal configuration (template) from /etc/skel.
5. Creates a password for the new user.
6. Runs the user script, if any.

If you want to skip the password prompt and finger information while adding the new user, use the following command:

$ sudo adduser --disabled-password --gecos "" username

Alternatively, you can use the useradd command as follows:

$ sudo useradd -s -m -d -g UserName

Where:

• -s specifies default login shell for the user
• -d sets the home directory for the user
• -m creates a home directory if one does not already exist
• -g specifies the default group name for the user

Creating a user with the command useradd does not set password for the user account. You can set or change the user password with the following command:

$sudo passwd bob

This will change the password for the user account bob.

There's more…

With adduser, you can do five different tasks:

• Add a normal user
• Add a system user with system option
• Add user group with the--group option and without the--system option
• Add a system group when called with the --system option
• Add an existing user to existing group when called with two non-option arguments

Check out the manual page man adduser to get more details.

You can also configure various default settings for the adduser command. A configuration file /etc/adduser.conf can be used to set the default values to be used by the adduser, addgroup, and deluser commands. A key value pair of configuration can set various default values, including the home directory location, directory structure skel to be used, default groups for new users, and so on. Check the manual page for more details on adduser.conf with following command:

$ man adduser.conf

See also

• Check out the command useradd, a low level command to add new user to system
• Check out the command usermod, a command to modify a user account
• See why every user has his own group at http://unix.stackexchange.com/questions/153390/why-does-every-user-have-his-own-group

In this recipe, we will create our first container with LXD.

Getting ready

You will need access to the root account or an account with sudo privileges.

How to do it…

LXD works on the concept of remote servers and images served by those remote servers. Starting a new container with LXD is as simple as downloading a container image and starting a container out of it, all with a single command. Follow these steps:

To start your first container, use the lxc launch command, as follows:

$ lxc launch ubuntu:14.04/amd64 c1

LXC will download the required image (14.04/amd64) and start the container.

You should see the progress like this:

As you can see in the screenshot, lxc launch downloads the required image, creates a new container, and then starts it as well. You can see your new container in a list of containers with the lxc list command, as follows:

$ lxc list

Optionally, you can get more details about the containers with the lxc info command:

$ lxc info c1

Now that your container is running, you can start working with it. With the lxc exec command, you can execute commands inside a container. Use the following command to obtain the details of Ubuntu running inside a container:

$ lxc exec c1 -- lsb_release -a

You can also open a bash shell inside a container, as follows:

$ lxc exec c1 -- bash

How it works…

Creating images is a time-consuming task. With LXD, the team has solved this problem by downloading the prebuilt images from trusted remote servers. Unlike LXC, where images are built locally, LXD downloads them from the remote servers and keep a local cache of these images for later use. The default installation contains three remote servers:

Ubuntu: This contains all Ubuntu releases

Ubuntu-daily: This contains all Ubuntu daily builds

images: This contains all other Linux distributions

You can get a list of available remote servers with this command:

$ lxc remote list

Similarly, to get a list of available images on a specific remote server, use the following command:

$ lxc image list ubuntu:

In the previous example, we used 64-bit Ubuntu 14.04 from one of the preconfigured remote servers (ubuntu:). When we start a specific container, LXD checks the local cache for the availability of the respective image; if it's not available locally, the required images gets fetched from the remote server and cached locally for later use. These images are kept in sync with remote updates. They also expire if not used for a specific time period, and expired images are automatically removed by LXD. By default, the expiration period is set to 10 days.

The lxc launch command creates a new container and then starts it as well. If you want to just create a container without starting it, you can do that with the lxc init command, as follows:

$ lxc init ubuntu:xenial c2

All containers (or their rootfs) are stored under the /var/lib/lxd/containers directory, and images are stored under the /var/lib/lxd/images directory.

While starting a container, you can specify the set of configuration parameters using the --config flag. LXD also supports configuration profiles. Profiles are a set of configuration parameters that can be applied to a group of containers. Additionally, a container can have multiple profiles. LXD ships with two preconfigured profiles: default and docker.

To get a list of profiles, use the lxc profile list command, and to get the contents of a profile, use the lxc profile show
command.

Sometimes, you may need to start a container to experiment with something—execute a few random commands and then undo all the changes. LXD allows us to create such throwaway or ephemeral containers with the -e flag. By default, all LXD containers are permanent containers. You can start an ephemeral container using the --ephemeral or -e flag. When stopped, an ephemeral container will be deleted automatically.

With LXD, you can start and manage containers on remote servers as well. For this, the LXD daemon needs to be exposed to the network. This can be done at the time of initializing LXD or with the following commands:

$ lxc config set core.https_address "[::]"

$ lxc config set core.trust_password some-password

Next, make sure that you can access the remote server and add it as a remote for LXD with the lxc remote add command:

$ lxc remote add remote01 192.168.0.11 # lxc remote add name server_ip

Now, you can launch containers on the remote server, as follows:

$ lxc launch ubuntu:xenial remote01:c1

There's more…

Unlike LXC, LXD container images do not support password-based SSH logins. The container still has the SSH daemon running, but login is restricted to a public key. You need to add a key to the container before you can log in with SSH. LXD supports file management with the lxc file command; use it as follows to set your public key inside an Ubuntu container:

$ lxc file push ~/.ssh/id_rsa.pub \

c1/home/ubuntu/.ssh/authorized_keys \

--mode=0600 --uid=1000

Once the public key is set, you can use SSH to connect to the container, as follows:

$ ssh ubuntu@container_IP

Alternatively, you can directly open a root session inside a container and get a bash shell with lxc exec, as follows:

$ lxc exec c1 -- bash

See also

The LXD getting started guide: https://linuxcontainers.org/lxd/getting-started-cli/

The Ubuntu Server guide for LXC: https://help.ubuntu.com/lts/serverguide/lxd.html

Container images are created using tools such as debootstrap, which you can read more about at https://wiki.debian.org/Debootstrap

Creating LXC templates from scratch: http://wiki.pcprobleemloos.nl/using_lxc_linux_containers_on_debian_squeeze/creating_a_lxc_virtual_machine_template