Baikal is a lightweight, free and open-source CalDAV and CardDAV server implementation that allows you to synchronize your address book and appointments with multiple clients such as mobile devices or a desktop application like Thunderbird. It lacks a couple of important features for enterprise use cases, such as address book and calendar sharing between multiple users, but it’s very suitable for a small office or home installations. Since it’s very lightweight and only depending on php and mysql, it’s also quite fast and stable.
Installing kvm on a recent Fedora OS is quite easy. Fedora already ships all the necessary software packages and kernel modules for running a kernel virtualised machine.
Since late 2005 / early 2006 almost every x86 processor is capable of hardware virtualization. To check if your CPU supports Intel’s VT-d or AMD’s Pacifica, which is a requirement for hardware virtualization with kvm, run:
# egrep '(vmx|svm)' --color=always /proc/cpuinfo
To install the necessary software packages, run:
# yum -y install qemu-kvm libvirt virt-install bridge-utils
1. Bridge configuration
There are a couple of ways to give your virtual machines access to your network. For a reference, have a look at the Networking page of the kvm documentation. The easiest way is to add the virtual NICs of your virtual machines as well as the physical NIC on your server to a common bridge.
Let’s assume, you have the following ethernet configuration file for your first ethernet device
# Generated by parse-kickstart UUID=a9e7f9b1-245a-42d6-84b3-865120c16dd6 DNS1=192.168.1.1 BOOTPROTO=none DEVICE=eth0 ONBOOT=yes IPV6INIT=yes HWADDR=00:8C:00:AA:8C:B8 TYPE=Ethernet IPADDR0=192.168.1.254 PREFIX0=24 GATEWAY0=192.168.1.1 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_FAILURE_FATAL=no NAME="System eth0"
Let’s create a new bridge device (
br0) and add our ethernet device (
eth0) to that bridge. First, create a new file called
/etc/sysconfig/network-scripts/ifcfg-br0 with the following content:
DNS1=192.168.1.1 BOOTPROTO=none DEVICE=br0 ONBOOT=yes IPV6INIT=no TYPE=Bridge IPADDR0=192.168.1.254 PREFIX0=24 GATEWAY=192.168.1.1 DEFROUTE=yes IPV4_FAILURE_FATAL=yes NM_CONTROLLED=no
Second, we’ll need to alter the configuration file for the ethernet device to add the device to the bridge
DEVICE=eth0 ONBOOT=yes HWADDR=00:8C:00:AA:8C:B8 BRIDGE=br0 TYPE=Ethernet NM_CONTROLLED=no
To retrieve the MAC address of your ethernet device (
eth0) you can use
ip link show:
# ip link show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 link/ether 00:8c:00:aa:8c:B8 brd ff:ff:ff:ff:ff:ff
Finally, disable the
NetworkManager service, enable the
network service and reboot the machine.
# systemctl disable NetworkManager.service # systemctl enable network.service # reboot
2. Enable libvirt-daemon
The Fedora packages already have a proper systemd init script, which makes enabling and starting the libvirt-daemon rather easy:
# systemctl enable libvirtd.service ln -s '/usr/lib/systemd/system/libvirtd.service' '/etc/systemd/system/multi-user.target.wants/libvirtd.service' # systemctl start libvirtd.service
A handy one-liner to list the crontab entries for every user:
$ for user in $(cut -f1 -d: /etc/passwd); do echo $user; crontab -u $user -l; done
To invoke logrotate manually to debug configuration settings, there is a builtin
# logrotate --debug --verbose /etc/logrotate.conf
To force a log file rotation, regardless of the specified criteria (such as age, minsize, etc.), run:
# logrotate --force --verbose /etc/logrotate.conf
Keep in mind, that you can use individual logrotate configuration files from
/etc/logrotate.d/ but settings are inherited from the global logrotate config
For a comprehensive list of options, have a look at the logrotate manpage.
Setting up an ownCloud instance is rather straight forward. OwnCloud6 rpm packages for recent Fedora versions (20+) already exist and can be easily installed with yum. Unfortunately, ownCloud’s storage mechanism is rather slow compared to other private cloud solution like Seafile or SparkleShare. However the overall speed can be improved greatly by switching from the most obvious and most popular server choice – an apache server – to nginx, for example.
One of the great advantages of using OpenVPN with RSA keys instaed of static keys is the fact that you can easily disable access to the server for a specific client without the need to re-create keys for any other client. This is called revoking of client certificates.
Since every single client’s certificate is verified against a Certificate Revoking List (CRL), disabling a certificate is rather easy. We simply have to create a CRL file and tell OpenVPN to use it. Any match against the CRL will then result in the connection being dropped.
Create a CRL file
The simplest way of dealing with RSA key management in general is probably
easy-rsa. You probably set up your OpenVPN server with the help of easy-rsa in the first place, so creating the CRL file is as simple as
# cd /usr/share/easy-rsa/2.0/ # source ./vars NOTE: If you run ./clean-all, I will be doing a rm -rf on /usr/share/easy-rsa/2.0/keys # ./revoke-full client Using configuration from /usr/share/easy-rsa/2.0/openssl-1.0.0.cnf Revoking Certificate 04. Data Base Updated Using configuration from /usr/share/easy-rsa/2.0/openssl-1.0.0.cnf client.crt: C = US, ST = CA, L = City, O = name, OU = name.example.org, CN = client, name = client, emailAddress = firstname.lastname@example.org error 23 at 0 depth lookup:certificate revoked
As you can see in the last line, the certificate was successfully revoke (hence the verification error 23).
You can also see the revoked status of the client’s certificate in the
keys/index.txt file. An “R” in the first column indicates, that the certificate was revoked.
[...] R 240209140518Z 140211140526Z 04 unknown /C=US/ST=CA/L=City/O=name/OU=name.example.org/CN=client/name=client/emailAddressemail@example.com
To examine the newly created CRL file, use
# openssl crl -in keys/crl.pem -text
Configure OpenVPN to use a CRL
Next, we need to tell OpenVPN to verify incoming connections against against our CRL. Copy the
crl.pem file to the OpenVPN config directory and assure, that’s it’s readable to the user running the OpenVPN service (usually openvpn:openvpn).
# cp -a keys/crl.pem /etc/openvpn/keys/ # chmod 755 /etc/openvpn/keys/
To tell the OpenVPN server to use a CRL, add the following line to your server’s config file:
[...] crl-verify keys/crl.pem
After restarting the OpenVPN server, every connection from a client with a revoked certificate should be denied
# journalctl -f [...] Feb 11 15:27:05 OpenVPN openvpn: 192.168.8.35:51960 CRL CHECK FAILED: C=US, ST=CA, L=City, O=name, OU=name.example.org, CN=client, name=client, emailAddressfirstname.lastname@example.org is REVOKED [...]
Beside the official OpenVPN documentation there’s a vast number of howtos and guides out there, that’ll tell you how to set up an OpenVPN server. Unfortunately, most of these use a tunneling setup including some sort of router and packet filter. If you want to transport non-IP based traffic and can accept the increased broadcast overhead and poor scalability, you need to setup an OpenVPN bridge.
If you run into this error:
# sshuttle -r user@remotehost -v 192.168.0.0/24 Starting sshuttle proxy. Listening on ('127.0.0.1', 12300). firewall manager ready. c : connecting to server... user@remotehost's password: s: latency control setting = True Traceback (most recent call last): File "<string>", line 1, in <module> File "assembler.py", line 26, in <module> File "server.py", line 168, in main File "server.py", line 68, in list_routes File "server.py", line 47, in _list_routes File "ssubprocess.py", line 606, in __init__ File "ssubprocess.py", line 1117, in _execute_child OSError: [Errno 2] No such file or directory c : fatal: server died with error code 1
the culprit is simply the missing netstat program on the target host. sshuttle tries to fork a netstat process without checking if netstat is installed on the target host in the first place.
On a Fedora host netstat comes with the
yum install net-tools