Ubuntu authentication with Zentyal LDAP

Authenticate user at Ubuntu (15.10) workstation with Zentyal userbase via LDAP

I wanted to authenticate my Ubuntu desktop to the users defined in Zentyal LDAP. Of course, I would still be able to login with a local user and as root.

First: Zentyal

Zentyal versions may differ, and I am using a pretty old version (3.0), but here is what worked for me:

* Go to 'Users and Groups' and create some users. Let's say user1 and user2. Make sure these users don't exist on your Ubuntu desktop.

* Go the the 'LDAP Settings' and take note of the DN's and passwords it provides.

It looks like this:

LDAP information

You will need this info later.

 

Configure Ubuntu to use LDAP for authentication

I followed this link: https://help.ubuntu.com/community/LDAPClientAuthentication

I did these steps:

* sudo apt-get install ldap-auth-client nscd

During install a screen comes up. Fill in the details. If you make a mistake, just finish the installation. Afterwards, you can use

   dpkg-reconfigure ldap-auth-config 

to fill in the correct values. I used the following:

Should debconf manage LDAP configuration? YES

LDAP server Uniform Resource Identifier:  ldap://192.168.0.1.:390  (My Zentyal Server IP and the port is 390 instead of 389 !)

Distinguished name of the search base: dc=example,dc=com (Base DN form Zentyal LDAP settings, see above)

LDAP version to use: 3

Make local root Database admin: YES

Does the LDAP database require login? NO (Default is NO )

LDAP account for root: cn=zentyal,dc=example,dc=com (Root DN from LDAP settings).

LDAP root account password: h8ZCV2J4NhErN234878f/eee (Password from settings)

Local crypt to use when changing passwords: md5 (md5 is the default)

Hostname

Edit /etc/hosts AND /etc/hostname and add 'example.com'.

If your host was 'mydesktop' then change it to mydesktop.example.com in both files.

Check if it was successful by doing:

  dnsdomainname

It should list 'example.com' (that's just an example!).

Reboot just to be sure and check again. It won't work if the dnsdomainname of your desktop doesn't match with Zentyal's settings!

Finalize

auth-client-config -t nss -p lac_ldap

pam-auth-update

 * Don't check the 'automatically create homedirs if you are using NFS!

/etc/init.d/nscd restart

That's all. I didn't do any of the other steps.

Now try

id user1

It should give you uid, gid and groups as defined on the Zentyal Server.

Next, het ALT-CTRL-F2 to open a console terminal and try to login as user1 and user2. It should work, but they don't have a homedir yet.

Vagrant hangs at "Waiting for VM to boot. This can take a few minutes..."

Vagrant

Vagrant is a tool for building and distributing working environments, see http://www.vagrantup.com

It has many advantages, but I had some trouble with it and tried to solve these issues.

Version

First of all, use version 1.2.2 or higher. Older versions had a nasty bug in the 'private_network' option in the Vagrantfile. Took me a loooong time to find that out.

Goal

My goal was to write a Vagrantfile and some extra configuration information, so I could quickly construct a virtual machine with certain properties, that could communicatie over a private network with other virtual machines, that was possibly publicly accessible by a public IP number, that was safe (in regard to the SSH key) and easily reproducable.

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
  config.vm.box = "precise64"
  config.vm.box_url = "http://files.vagrantup.com/precise64.box"
  config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--memory", "1024", "--cpus", "4"]
  end
  config.vm.hostname = 'YOUR.VIRTUAL.HOSTNAME.HERE'
  config.vm.network :private_network, :auto_config => false, :ip => "10.0.0.1"
  config.vm.network :public_network, :bridge => "br0", :auto_config => false
  config.vm.provision :shell, :path => "secure-the-box.sh"
  config.vm.provision :shell, :path => "install-software.sh"
  config.vm.provision :shell, :path => "network-setup.sh"
  config.ssh.timeout = 30
  config.ssh.max_tries = 3
end
require './SafeSSH'
 

Some lines explained

config.vm.network :private_network, :auto_config => false, :ip => "10.0.0.1"

We want to establish a private network. But we don't want to configure it automatically (we will do that later in a script), but we have to specify the ip number or else vagrant will not start. The ip number is totally random and not used at all, see https://github.com/mitchellh/vagrant/issues/1788

config.vm.network :public_network, :bridge => "br0", :auto_config => false

We want a public network so the machine is reachable. Again, we are not auto configuring this interface.

config.vm.provision :shell, :path => "secure-the-box.sh"
config.vm.provision :shell, :path => "install-software.sh"
config.vm.provision :shell, :path => "network-setup.sh"

These three script will be explained later, they do what they say they do...

require './SafeSSH'

This require is needed to read in a file that sets the SSH key (the default one is not safe).

List of files

-rw-r--r-- 1 root root    0 Jun  3 18:25 box_secured_by_shell_provisioner
-rw-r--r-- 1 root root   46 Jun  3 01:01 install-list
-rw-r--r-- 1 root root  341 Jun  3 00:27 install-software.sh
-rw-r--r-- 1 root root  143 Jun  2 22:47 network.conf
-rw-r--r-- 1 root root    0 Jun  3 18:26 network_configured_by_shell_provisioner
-rw-r--r-- 1 root root 1413 Jun  3 01:07 network-setup.sh
-rw-r--r-- 1 root root  100 Jun  3 18:25 SafeSSH.rb
-rw-r--r-- 1 root root 1473 Jun  3 00:23 secure-the-box.sh
-rw-r--r-- 1 root root    0 Jun  3 18:26 software_installed_by_shell_provisioner
-rwxr--r-- 1 root root  153 Jun  3 00:27 vagrant-destroy
-rw-r--r-- 1 root root  816 Jun  3 18:24 Vagrantfile
 

box_secured_by_shell_provisioner

This file is created by the secure-the-box.sh script. It prevents the script from running then next time vagrant up or vagrant reload is run. It is deleted by the vagrant-destroy script.

install-list

Install list contains a list of packages, one per line, that will be installed when vagrant up is run. Example:

apache2
proftpd
joe
mc
#iptraf
#traceroute
 

install-software.sh

#!/bin/bash
if [ ! -f /vagrant/software_installed_by_shell_provisioner ]
 then
  echo 'Installing software...'
  for i in `cat /vagrant/install-list`
  do
    sudo DEBIAN_FRONTEND='noninteractive' apt-get -y install $i
  done
  sudo touch /vagrant/software_installed_by_shell_provisioner
 else
  echo 'Software already installed...'
fi
 

This script simpy installs the packages listed in the install-list. It doesn't run if the file software_installed_by_shell_provisioner is present.

network.conf

#!/bin/bash
HOST_IP="X.X.X.X"
GUEST_IP="Y.Y.Y.144"
PRIVATE_IP="Z.Z.Z.144"
NAMESERVERS="8.8.8.8 8.8.4.4"
 

This is a bash script that is sourced in network-setup.sh. the HOST_IP is the IP of the host where the Virtual Machine runs on.

The GUEST_IP is the PUBLIC IP for the Virtual Machine (and may be very different from the HOST_IP).

The PRIVATE_IP is a private IP address for the different VM's to connect to eachother (i.e. 10.33.0.1, 10.33.0.2 etc).

The NAMESERVERS are a bunch of nameservers that your Virtual Machine is going to use. Set them to the host if your host is a resolving nameserver.

The way the public IP is configured, is described here in detail:

- http://wiki.hetzner.de/index.php/KVM_mit_Nutzung_aller_IPs_-_the_easy_way/en

- http://wiki.hetzner.de/index.php/KVM_mit_Nutzung_aller_IPs_aus_Subnetz/en

The above links are specific for one specific provider, but after some trying, reading and comparing one can figure out how to configure the host. This is quite important. My /etc/network/intefaces on the host looks like this:

auto br0
iface br0 inet static
  address X.X.X.X
  netmask 255.255.255.255
  bridge_ports none
  bridge_stp off
  bridge_fd 0
  bridge_maxwait 0
  pre-up brctl addbr br0
  up route add -host Y.Y.Y.144 dev br0
  up route add -host Y.Y.Y.145 dev br0
  # ...
  up route add -host Y.Y.Y.151 dev br0
 

Please also read this: http://docs.vagrantup.com/v2/networking/public_network.html

network_configured_by_shell_provisioner

This file is created by the network-setup.sh script, and prevents the script from running. It is removed by the vagrant-destroy script.

network-setup.sh

#!/bin/bash
source /vagrant/network.conf
if [ ! -f /vagrant/network_configured_by_shell_provisioner ]
 then
  echo 'Configuring network...'
  sudo cat > /etc/network/interfaces <<NETCONF
 

# The loopback network interface
auto lo
iface lo inet loopback
 

# The primary network interface
# This is 10.0.2.15 by default for Virtualbox.
# It is assigned with DHCP but that also introduces new default routes.
# So it is  declared static here, with the IP of the host as gateway.
# You need to do one vagrant reload after the first vagrant up to activate this. A simple networking restart won't work.
auto eth0
iface eth0 inet static
  address 10.0.2.15
  netmask 255.255.255.0
  gateway $HOST_IP

# this one is for the 'private' or 'hostonly' network.
auto eth1
iface eth1 inet static
  address $PRIVATE_IP
  netmask 255.255.255.0
            
# This your bridged interface. The nameserver is set too...
auto eth2
iface eth2 inet static
  address $GUEST_IP
  netmask 255.255.255.255
  gateway $HOST_IP
  pointopoint $HOST_IP
  dns-nameservers $NAMESERVERS
 
NETCONF

  # don't ask me why but the dhcp client keeps asking for an IP even when disabled in /etc/network/interfaces
  sudo rm -rf /var/lib/dhcp
  sudo apt-get -y --purge remove isc-dhcp-client
  sudo touch /vagrant/network_configured_by_shell_provisioner
  echo "Please run vagrant reload now!"
 else
  echo 'Network already configured...'
fi
route -n
 

What this script does is:

- replace /etc/network/interfaces on the guest with a static version of this configuration file; it totally discards all autoconfigured information.

- remove the dhcp client, because when leaving it in place, even disabled, it adds new routes to the routing table, and that needs to be avoided.

The only problem is that a vagrant reload is needed, and that can't be done from this script. You need to do it manually after the first vagant up.

SafeSSH.rb

Vagrant.configure("2") do |config|
  config.ssh.private_key_path = "/root/.ssh/vagrant/id_rsa"
end

This file needs to be present at all times because it is required in the Vagrantfile; but the first time vagrant up is run, it should be empty. The secure-the-box.sh script writes some configuration directieves to it. The vagrant-destroy script truncates this file and makes it empty.

secure-the-box.sh

#!/bin/bash
# do this before the network is provisoned!

if [ ! -f /vagrant/box_secured_by_shell_provisioner ]
 then
  echo 'Securing the box...'
  sudo mkdir -p /root/.ssh
  sudo echo "ssh-rsa AAAA-YOUR-SSH-PUBLIC-KEY your@email" > /root/.ssh/authorized_keys
  sudo echo "ssh-rsa AAAA-YOUR-HOST-PUBLIC-KEY root@host" > /home/vagrant/.ssh/authorized_keys
  sudo passwd -l vagrant
  sudo passwd -l root
  sudo cat >> /vagrant/SafeSSH.rb <<SEU
Vagrant.configure("2") do |config|
  config.ssh.private_key_path = "/root/.ssh/vagrant/id_rsa"
end
SEU
  sudo touch /vagrant/box_secured_by_shell_provisioner
  echo "Done..."
 else
  echo 'Box already secured...'
fi
 

This script relies on you configuring your ssh-keys properly. vagrant uses a well publicized key-pair, so using the default key is inherently insecure. Since your goal is to have a public facing virtual machine, you could just as well remove all password protection. This is why this script needs to run before the network is configured. Of course you are at liberty to setup the keys in any way you want but in this case, I used my public key to access root @ the virtual machine, and I used the ssh-key of root @ the host to access the vagrant account @ the virtual machine. The latter is important since vagrant up, reload, halt and destroy all attempt to ssh into the virtual machine!

Then the paswords are removed from the root and the vagrant account, so now ONLY ssh-keys can be used to access the virtual machine.

The script doens't run if the file box_secured_by_shell_provisioner is present.

software_installed_by_shell_provisioner

This file is created by the install-software.sh script and removed by the vagant-destroy script.

vagrant-destroy

rm box_secured_by_shell_provisioner
rm network_configured_by_shell_provisioner
rm software_installed_by_shell_provisioner
echo '' > SafeSSH.rb
vagrant destroy
 

When trying to destroy the VM with 'vagrant destroy', the next vagrant up will not work as expected. Most prominently, the Vagrantfile will read SafeSSH.rb and use the wrong ssh keys. This will fail any vagrant up. This script properly destroys the files that are created by the various provisioners. and then destroy the VM, for a sparkling fresh start.

Problem with GRUB in images

One last thing that took an enormous amount of time before I found the solution. The standard images, http://files.vagrantup.com/precise64.box for instance, have an 'option' in GRUB so that it will wait forever for you to press a key when the last shutdown wasn't completed normally. For some reason this (always) happens after the second reload of the VM. So, the very first time, 'vagrant up' creates the machine, then my script asks you to do a 'vagrant reload' which works fiine, the machine works fine, and can run forever :-) But when you try for some reason to do a reload or a halt and then up, the machine will never recover. Vagrant will display the dreaded Waiting for VM to boot. This can take a few minutes message and if you start Googling for that, you will search in the wrong direction. For a better description of the problem and a solution, see https://github.com/mitchellh/vagrant/issues/1792

At the moment, you have to fix this yourself or hope the providers of the box will have it fixed in the next release.

A note on upgrading

After upgrading (apt-get update && apt-get dist-upgrade) three things happenned:

- the modifications in /etc/grub/00header triggered a debconf question, and I choose to keep my own configuration. But in the newer configuration file, there is now a driective that can be used in /etc/default/grub called GRUB_RECORDFAIL_TIMEOUT that can be set, and if it is not set it will default to -1. So in future versions, just set this variable in /etc/default/grub and run update-grub

- the update process wants to update-grub and complains about  a disk that isn't there anymore, and offers three choices. I choose the first one, /dev/sda (VBOX_HARDDISK).

- and after a vagranr reload, the following problem occured:

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -t vboxsf -o uid=`id -u vagrant`,gid=`id -g vagrant` v-root /vagrant

The solution is to rebuild the kernel modules, as mentioned in 
http://docs-v1.vagrantup.com/v1/docs/troubleshooting.html

However, that didn't work for me. To the rescue, the Vbguest plugin. http://kvz.io/blog/2013/01/16/vagrant-tip-keep-virtualbox-guest-additions-in-sync/, https://github.com/dotless-de/vagrant-vbguest

What I had to do to get it working was:

vagrant plugin install vagrant-vbguest

./vagrant-destroy # to totally remove the virtual machine
vagrant up # this will also update the guest additions!
vagrant reload # because my script asks for it...
vagant ssh
sudo joe /etc/grub.d/00header # and change the timeout from -1 to 10
sudo update-grub
sudo apt-get update
sudo apt-get dist-upgrade
# when asked to use new grub 00header, say no
# when asked to install gtub on a disk, choose the first one (the Virtual Box Harddisk)
# exit the machine
vagrant reload

Quite a lot of stuff to get it all working, but it is working!

Conclusion

I hope these musings are useful for someone. I post them here to not forget my own briddling. It took me quite a while to get this going.

Zentyal/Ebox, slowness, and WDxxEARS Advanced Format

• Zentyal (formerly named Ebox) is an Ubuntu based Small business server that is easy to configure and in my opnion a real breakthrough in Ubuntu-based small business servers. Unfortunately, I had a bit of bad luck (or lack of information) when I installed my first two servers for clients on Curaçao. The server was very, very slow, up to the point where a simple ssh login took 2 minutes and in one case the install halted halfway. I spent many hours trying to troubleshoot the problem and meanwhile I had to revert to webmin or some other solution.


• The problems are described in the following posts on the Zimbra forum:
  http://forum.zentyal.org/index.php?topic=3697.0
  http://forum.zentyal.org/index.php?topic=4212.0
  http://forum.zentyal.org/index.php?topic=3968.0
  http://forum.zentyal.org/index.php?topic=3427.0
  http://forum.zentyal.org/index.php?topic=4273.0
  and most notably
  http://forum.zentyal.org/index.php?topic=5724.0


• Unfortunately, the forums didn't help much. After many days of frustration, I decided to buy support, which cost 390 EUR. I've never paid for support before in my life and I hope I don't have to do it again. Although the team at Zentyal did their best to help me, they didn't really succeed. Finally, after swapping out all hardware except the harddisks, I bought a new harddisk, although there where no harddisk errors reported and SMART status was okay.


• Then it hit me like a brick. I typed in the model number of my Western Digital Caviar Green WD10EARS and what do you think - hundreds of posts about how this harddisk uses Advanced Format and how that gives loads of problems. Google for yourself: any WD of the EARS series has this problem. My new disks where of the EADS series and after copying all the data (which took ages) and reinstalling the server, the server was flying! Normal load, normal speed, everything was fine.


• The problem lies in the alignment of sectors on the EARS drive. More information on the Advanced Format can be found here and here.


• After I repartitioned the EARS drives by hand, I installed a new server with these disks, and the server was as fast as it should be. Wrong alignment of the EARS drives really really slows all disk I/O down.


• Newer versions of parted should detect AF automatically and so I hope the Zentyal team will put the newer version of parted into their installer. Also, when giving support, a simple
  
  
  hdparm -i /dev/sd?|grep EARS
  
  
  would make the problem clear right away. A pity that the team at Zentyal didn't know that and I hope this information will be integrated in their knowledgebase.


• All in all, I find Zentyal a great product that really fills a niche in the small business server market. I am happy with the server now that the slowness problems have been solved.

Ebox 1.4 and HP Color LaserJet 2600N

• Follow instructions here: ubuntuforums.org, except the last step.
  
  
  $ wget -O foo2zjs.tar.gz http://foo2zjs.rkkda.com/foo2zjs.tar.gz
  $ tar zxf foo2zjs.tar.gz
  $ cd foo2zjs
  $ make
  $ ./getweb 2600n # Get HP LaserJet 2600n .ICM files
  $ sudo make install
  $ sudo make cups
  
  
  Now go to Ebox -> Printer Sharing -> Add Printer
  And go find the HP -> Color Laserjet 2600N. It will now have a driver (foo2hp). The next page you can select stuff:
  
  "Color Mode" = Color
  "Bits Per Plane" = 2
  "ICM Color Profile" = (something like hpclj2600n-0.icm)