Ubuntu

Group is a way to organize and administer user accounts in Linux. Groups are used to collectively assign rights and permissions to multiple user accounts.

Getting ready

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

How to do it...

Follow these steps to create a group:

1. Enter the following command to add a new group:
   $ sudo addgroup guest
2. Enter your password to complete addgroup with root privileges.

How it works…

Here, we are simply adding a new group guest to the server. As addgroup needs root privileges, we need to use sudo along with the command. After creating a new group, addgroup displays the GID of the new group.

There's more…

Similar to adduser, you can use addgroup in different modes:

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

Check out the manual page for the addgroup(man addgroup) to get more details.

Check out groupadd, a low level utility to add new group to the server

In this recipe, we will learn about some advanced options provided by LXD.

How to do it…

Follow these steps to deal with LXD containers:

Sometimes, you may need to clone a container and have it running as a separate system. LXD provides a copy command to create such clones:

$ lxc copy c1 c2 # lxc copy source destination

You can also create a temporary copy with the --ephemeral flag and it will be deleted after one use.

Similarly, you can create a container, configure it as per you requirements, have it stored as an image, and use it to create more containers. The lxc publish command allows you to export existing containers as a new image. The resulting image will contain all modifications from the original container:

$ lxc publish c1 --alias nginx # after installing nginx

The container to be published should be in the stopped state. Alternatively, you can use the --force flag to publish a running container, which will internally stop the container before exporting.

You can also move the entire container from one system to another. The move command helps you with moving containers across hosts. If you move a container on the same host, the original container will be renamed. Note that the container to be renamed must not be running:

$ lxc move c1 c2 # container c1 will be renamed to c2

Finally, we have the snapshot and restore functionality. You can create snapshots of the container or, in simple terms, take a backup of its current state. The snapshot can be a stateful snapshot that stores the container's memory state. Use the following command to create a snapshot of your container:

$ lxc snapshot c1 snap1 # lxc snapshot container cnapshot

The lxc list command will show you the number of snapshots for a given container. To get the details of every snapshot, check the container information with the lxc info command:

$ lxc info c1

...

Snapshots:

c1/shap1 (taken at 2016/05/22 10:34 UTC) (stateless)

Once you have the snapshots created, you can restore it to go back to a point or create new containers out of your snapshots and have both states maintained. To restore your snapshot, use lxc restore, as follows:

$ lxc restore c1 snap1 # lxc restore container snapshot

To create a new container out of your snapshot, use lxc copy, as follows:

$ lxc copy c1/snap1 c4 # lxc copy container/snapshot new_container

When you no longer need a snapshot, delete it with lxc delete, as follows:

$ lxc delete c1/snap1 # lxc delete container/snapshot

How it works…

Most of these commands work with the rootfs or root filesystem of containers. The rootfs is stored under the /var/lib/lxd/containers directory. Copying creates a copy of the rootfs while deleting removes the rootfs for a given container. These commands benefit with the use of the ZFS file system. Features such as copy-on-write speed up the copy and snapshot operations while reducing the total disk space use.

In this recipe, we will look at the various tools available for troubleshooting Samba shares.

How to do it…

Samba troubleshooting can be separated in to three parts: network connectivity, Samba process issues, and Samba configuration issues. We will go through each of them step by step. As a first step for troubleshooting, let's start with network testing.

Checking network connectivity

Follow these steps to check network connectivity:

Send ping requests to the Samba server to check network connectivity:

$ ping samba-server-ip

Check name resolution. Ping the Samba server by its name. Windows uses netbios for name resolution:

$ ping samba-server-name

Check the Samba configuration for network restrictions. Temporarily open Samba to all hosts.

Use tcpdump to check Samba network communication. Start tcpdump as follows and let it run for some time while accessing the Samba server from clients. All packets will be logged in a file named tcpdump in the current directory:

$ sudo tcpdump -p -s 0 -w tcpdumps port 445 or port 139

If you know the client IP address, you can filter tcpdumps with the following command:

$ sudo tcpdump -s 0 -w tcpdumps host client_IP

Connect to the Samba process with telnet:

$ echo "hello" | telnet localhost 139

Check whether your Samba server uses a firewall. If so, check the allowed ports on your firewall. If the firewall is on, make sure you have allowed the Samba ports as follows:

Try connecting to FTP or a similar TCP service on the Samba server. This may identify the problems with the TCP stack.

Use nmblookup to test netbios name resolution for Windows systems.

Checking the Samba service

Follow these steps to check Samba service:

Check whether the Samba service has started properly:

$ sudo service samba status

Use netstat to check the Samba daemon is listening on the network:

$ sudo netstat -plutn

Use ps to check the Samba processes. Look for the process name, smbd, in the output of the following command:

$ ps aux

Use strace to view the Samba process logs. This will list all filesystem activities by smbd process:

$ strace smbd

Checking Samba logs

Follow these steps to check Samba logs:

Check Samba log files for any warning or errors.

Increase the log level to get more debugging information:

[global]

log level = 3

Enable logging for a specific client with client-specific configuration. First, set the following options under smb.conf to enable client-specific configuration:

[global]

log level = 0

log file = /var/log/samba/log.%m

include = /etc/samba/smb.conf.%m

Now create a new configuration file for a specific client:

$ sudo vi /etc/samba/smb.conf.client1

[global]

log level = 3

Similarly, you can create separate logs for each Samba user:

[global]

log level = 0

log file = /var/log/samba/log.%u

include = /etc/samba/smb.conf.%u

Checking Samba configuration

Follow these steps to check Samba configuration:

Check the registered users and accounts in the Samba server user database with the pdbedit command:

$ sudo pdbedit -L

Check the shares with the smbtree command:

Use the testparm command to find any errors in the Samba configuration:

$ testparm

Check for allowed users and group names. Make sure that group names start with the @ symbol.

Back up your configuration files and then use minimal configuration to test Samba:

[global]

workgroup = WORKGROUP

security = user

browsable = yes

[temp]

path = /tmp

public = yes

Test your configuration with smbcclient. It should list all Samba shares:

$ smbclient -L localhost -U%

See also

Samba docs troubleshooting at https://www.samba.org/samba/docs/using_samba/ch12.html

In this recipe, we will learn how to add new users to the MySQL database server. MySQL provides very flexible and granular user management options. We can create users with full access to an entire database or limit a user to simply read the data from a single database. Again, we will be using queries to create users and grant them access rights. You are free to use any tool of your choice.

Getting ready

You will need a MySQL user account with administrative privileges. You can use the MySQL root account.

How to do it…

Follow these steps to add users to MySQL database server and assign access rights:

Open the MySQL shell with the following command. Enter the password for the admin account when prompted:

$ mysql -u root -p

From the MySQL shell, use the following command to add a new user to MySQL:

mysql> create user ‘dbuser’@’localhost’ identified by ‘password’;

You can check the user account with the following command:

mysql> select user, host, password from mysql.user where user = ‘dbuser’;

Next, add some privileges to this user account:

mysql> grant all privileges on *.* to ‘dbuser’@’localhost’ with grant option;

Verify the privileges for the account as follows:

mysql> show grants for ‘dbuser’@’localhost’

Finally, exit the MySQL shell and try to log in with the new user account. You should log in successfully:

mysql> exit

$ mysql -u dbuser -p

How it works…

MySQL uses the same database structure to store user account information. It contains a hidden database named MySQL that contains all MySQL settings along with user accounts. The statements create user and grant work as a wrapper around common insert statements and make it easy to add new users to the system.

In the preceding example, we created a new user with the name dbuser. This user is allowed to log in only from localhost and requires a password to log in to the MySQL server. You can skip the identified by ‘password’ part to create a user without a password, but of course, it’s not recommended.

To allow a user to log in from any system, you need to set the host part to a %, as follows:

mysql> create user ‘dbuser’@’%’ identified by ‘password’;

You can also limit access from a specific host by specifying its FQDN or IP address:

mysql> create user ‘dbuser’@’host1.example.com’ identified by ‘password’;

Or

mysql> create user ‘dbuser’@’10.0.2.51’ identified by ‘password’;

Note that if you have an anonymous user account on MySQL, then a user created with username’@’% will not be able to log in through localhost. You will need to add a separate entry with username’@’localhost.

Next, we give some privileges to this user account using a grant statement. The preceding example gives all privileges on all databases to the user account dbuser. To limit the database, change the database part to dbname.*:

mysql> grant all privileges on dbname.* to ‘dbuser’@’localhost’ with grant option;

To limit privileges to certain tasks, mention specific privileges in a grant statement:

mysql> grant select, insert, update, delete, create

-> on dbname.* to ‘dbuser’@’localhost’;

The preceding statement will grant select, insert, update, delete, and create privileges on any table under the dbname database.

There’s more…

Similar to preceding add user example, other user management tasks can be performed with SQL queries as follows:

Removing user accounts

You can easily remove a user account with the drop statement, as follows:

mysql> drop user ‘dbuser’@’localhost’;

Setting resource limits

MySQL allows setting limits on individual accounts:

mysql> grant all on dbname.* to ‘dbuser’@’localhost’

-> with max_queries_per_hour 20

-> max_updates_per_hour 10

-> max_connections_per_hour 5

-> max_user_connections 2;

See also

MySQL user account management at https://dev.mysql.com/doc/refman/5.6/en/user-account-management.html

In this article, we will cover the following recipes:

• Installing OpenLDAP
• Installing phpLDAPadmin
• Ubuntu server logins with LDAP
• Authenticating Ejabberd users with LDAP

In this recipe, we will learn some performance tuning configurations that may help to squeeze out the last bit of performance from the available hardware. Before diving into performance tuning, we need to evaluate our servers and set a benchmark which can be used to measure improvements after any changes. We will be using a well known HTTP benchmarking tool, Apache Bench (ab). Various other benchmarking tools are available and each one has its own feature set. You can choose the one that best suits your needs.

Getting ready

You will need two systems: one with the web server software installed and another to run Apache Bench. You will need root access or access to an account with similar privileges.

You will also need to modify a few network parameters to handle a large network load. You will also need to set a higher open files limit, in limits.conf, on both systems. Check the Tuning TCP Stack recipe in article 2, Networking.

How to do it…

Install the Apache Bench tool. This is available with the package apache2-utils:

$ sudo apt-get install apache2-utils

If you need to, you can check all the available options of the ab tool as follows:

$ ab -h

Now we are ready to generate network load. Execute the following command to start ab:

$ ab -n 10000 -c 200 -t 2 -k "http://192.168.56.103/index.php"

It will take some time to complete the command depending on the parameters. You should see similar results to the following (partial) output:

Additionally, you may want to benchmark your server for CPU, memory, and IO performance. Check the Setting performance benchmarks recipe in article 13, Performance Monitoring.

Now that we have a benchmark for server performance with stock installation, we can proceed with performance optimization. The following are some settings that are generally recommended for performance tuning:

Apache related settings:

Remove/disable any unused modules

Enable mod_gzip/mod_deflate

Turn HostnameLookups off

Use IP address in configuration files

Use persistence connection by enabling keepalive, then set keepalive timeout

Limit the uses of AllowOverride or completely disable it with AllowOverride none

Disable ExtendedStatus; this is useful while testing but not in production

Nginx related settings:

Set worker_processes to the count of your CPU cores or simply set it to auto

Set the number of worker_connections to test multiple values to find the best match for your servers

Set the keepalive_requests and keepalive_timeout values; these reduce the overhead of creating new connections

Enable idle connections with upstream servers by setting the keepalive value

Enable log buffering with buffer and flush parameters to access_log; this will reduce IO requests while logging

Reduce the log-level - you can set it to warn the user or display an error while in production

Set the sendfile directive to use an efficient sendfile() call from the operating system

Enable caching and compression

Make sure that you track the performance changes after each set of modifications; this way you will have exact knowledge regarding what worked and what not

You should also tune the TCP stack. The details of the TCP stack settings are covered in article 2, Networking.

There's more…

Various other tools are available for benchmarking different features of the web server. The following are some well known tools, as well as a few latest additions:

Httperf: A web server benchmarking tool with some advanced options

Perfkit: a cloud benchmark tool by Google

Wrk: https://github.com/wg/wrk

H2load: HTTP2 load testing tool at https://nghttp2.org/documentation/h2load-howto.html

See also

Apache performance tuning guide at https://httpd.apache.org/docs/2.4/misc/perf-tuning.html

Nginx performance tuning guide at https://www.nginx.com/blog/tuning-nginx/

We have set up our own Git hosting server with GitLab, but it still contains a single admin user account. You can start using the setup and create a new repository with an admin account, but it is a good idea to set up a separate non-root account. In this recipe, we will cover the user management and access control features of the GitLab server.

Getting ready

Make sure you have followed the previous recipe and installed the GitLab server.

Login to GitLab with your root or admin account.

You will need to configure the email server before creating a user account. You can use an external email service, such as sendgrid or mailgun. Update your GitLab email server configuration and reconfigure the server for the changes to take effect.

How to do it…

The default landing page for GitLab is a projects page. The same page is listed even when you log in as root. To create a new user, we need to access the admin area:

To open the admin console, click on the admin area icon located at the top-right corner of the screen. Alternatively, you can add /admin to the base URL and access the admin area.

The admin dashboard will greet you with details about your installation and the features and components list. The left-hand menu will list all available options.

Click on the Users menu to get user account-related options.

Next, click on the big green New User button to open a new user form.

Now fill in the required details such as name, username, and email. The form should looks something like this:

You cannot set a password for a new user account on the create user form. The reset password link will be mailed to the user at a given email ID. A new user can set his password through that link:

Under the Access section, you can mark this user as admin and set a limit on projects created by him:

Next, under the profile section, you can add some more details for this user account.

Now, click on the Create User button at the bottom-left of the form. This will save the given details and trigger a password reset email. A screen will change to the User Details page where you can see the account details, groups, and projects of a given user, as well as other details. From the same page, you can block or remove the user account.

The new user account is ready to be used. Open the login page in a new window or private browser and use the email or username and newly set password to log in.

When an application becomes popular, it sends an increased number of requests to the application server. A single application server may not be able to handle the entire load alone. We can always scale up the underlying hardware, that is, add more memory and more powerful CUPs to increase the server capacity; but these improvements do not always scale linearly. To solve this problem, multiple replicas of the application server are created and the load is distributed among these replicas. Load balancing can be implemented at OSI Layer 4, that is, at TCP or UDP protocol levels, or at Layer 7, that is, application level with HTTP, SMTP, and DNS protocols.

In this recipe, we will install a popular load balancing or load distributing service, HAProxy. HAProxy receives all the requests from clients and directs them to the actual application server for processing. Application server directly returns the final results to the client. We will be setting HAProxy to load balance TCP connections.

Getting ready

You will need two or more application servers and one server for HAProxy:

You will need the root access on the server where you want to install HAProxy

It is assumed that your application servers are properly installed and working

How to do it…

Follow these steps to discus load balancing with HAProxy:

Install HAProxy:

$ sudo apt-get update

$ sudo apt-get install haproxy

Enable the HAProxy init script to automatically start HAProxy on system boot. Open /etc/default/haproxy and set ENABLE to 1:

Now, edit the HAProxy /etc/haproxy/haproxy.cfg configuration file. You may want to create a copy of this file before editing:

$ cd /etc/haproxy

$ sudo cp haproxy.cfg haproxy.cfg.copy

$ sudo nano haproxy.cfg

Find the defaults section and change the mode and option parameters to match the following:

mode tcp

option tcplog

Next, define frontend, which will receive all requests:

frontend www

bind 57.105.2.204:80 # haproxy public IP

default_backend as-backend # backend used

Define backend application servers:

backend as-backend

balance leastconn

mode tcp

server as1 10.0.2.71:80 check # application srv 1

server as2 10.0.2.72:80 check # application srv 2

Save and quit the HAProxy configuration file.

We need to set rsyslog to accept HAProxy logs. Open the rsyslog.conf file, /etc/rsyslog.conf, and uncomment following parameters:

$ModLoad imudp

$UDPServerRun 514

Next, create a new file under /etc/rsyslog.d to specify the HAProxy log location:

$ sudo nano /etc/rsyslog.d/haproxy.conf

Add the following line to the newly created file:

local2.* /var/log/haproxy.log

Save the changes and exit the new file.

Restart the rsyslog service:

$ sudo service rsyslog restart

Restart HAProxy:

$ sudo service haproxy restart

Now, you should be able to access your backend with the HAProxy IP address.

How it works…

Here, we have configured HAProxy as a frontend for a cluster of application servers. Under the frontend section, we have configured HAProxy to listen on the public IP of the HAProxy server. We also specified a backend for this frontend. Under the backend section, we have set a private IP address of the application servers. HAProxy will communicate with the application servers through a private network interface. This will help to keep the internal network latency to a minimum.

HAProxy supports various load balancing algorithms. Some of them are as follows:

Round-robin distributes the load in a round robin fashion. This is the default algorithm used.

leastconn selects the backend server with fewest connections.

source uses the hash of the client's IP address and maps it to the backend. This ensures that requests from a single user are served by the same backend server.

We have selected the leastconn algorithm, which is mentioned under the backend section with the balance leastconn line. The selection of a load balancing algorithm will depend on the type of application and length of connections.

Lastly, we configured rsyslog to accept logs over UDP. HAProxy does not provide separate logging system and passes logs to the system log daemon, rsyslog, over the UDP stream.

There's more …

Depending on your Ubuntu version, you may not get the latest version of HAProxy from the default apt repository. Use the following repository to install the latest release:

$ sudo apt-get install software-properties-common

$ sudo add-apt-repository ppa:vbernat/haproxy-1.6 # replace 1.6 with required version

$ sudo apt-get update && apt-get install haproxy

See also

An introduction to load balancing the HAProxy concepts at https://www.digitalocean.com/community/tutorials/an-introduction-to-haproxy-and-load-balancing-concepts

We have set up the Ampache server and configured it for streaming. In this recipe, we will learn how to set up an Android client to play content from our Ampache server.

Getting ready

You will need an Android or iOS phone or tablet. We will focus on the configuration of an Android client, but the same configuration should work with an iOS device, and even desktop clients such as VLC.

How to do it…

Follow these steps to stream music with Ampache:

First, install Just Player on your Android device. It is an Ampache client and uses XML APIs to stream content from Ampache. It is available from the Play Store.

Once installed, open the settings of Just Player and search for Ampache under cloud player.

We need to add our Ampache server details here. Enter the server URL as the domain name or IP address of your Ampache server and append /ampache at the end, for example:

http://myampacheserver.com/ampache

Next, enter the username and password in their respective fields. You can use the user account created in the last recipe.

Click Check to confirm the settings and then save.

Now you should be able to access your Ampache songs on your Android device or phone.

In this recipe, you will see how to create multiple user accounts in batch mode without using any external tool.

Getting ready

You will need a user account with root or root privileges.

How to do it...

Follow these steps to create a user account in batch mode:

1. Create a new text file users.txt with the following command:
   $ touch users.txt
2. Change file permissions with the following command:
   $ chmod 600 users.txt
3. Open users.txt with GNU nano and add user account details:
   $ nano users.txt
4. Press Ctrl + O to save the changes.
5. Press Ctrl + X to exit GNU nano.
6. Enter $ sudo newusers users.txt to import all users listed in users.txt file.
7. Check /etc/passwd to confirm that users are created:

How it works…

We created a database of user details listed in same format as the passwd file. The default format for each row is as follows:

username:passwd:uid:gid:full name:home_dir:shell

Where:

• username: This is the login name of the user. If a user exists, information for user will be changed; otherwise, a new user will be created.
• password: This is the password of the user.
• uid: This is the uid of the user. If empty, a new uid will be assigned to this user.
• gid: This is the gid for the default group of user. If empty, a new group will be created with the same name as the username.
• full name: This information will be copied to the gecos field.
• home_dir: This defines the home directory of the user. If empty, a new home directory will be created with ownership set to new or existing user.
• shell: This is the default login shell for the user.

The new user command reads each row and updates the user information if the user already exists, or it creates a new user.

We made the users.txt file accessible to owner only. This is to protect this file, as it contains the user's login name and password in unencrypted format.