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 net-tools package:
yum install net-tools
OpenProject is an open source project management software. It’s a web-based system that runs in your browser and is built on Ruby on Rails. What makes it really worth-wile is a wide set of features and plugins and a very active and always helpful community.
To quickly convert a pdf file to dxf, there’s a neat little tool called pstoedit. It’s part of Fedora’s standard repository and can be installed via yum
# yum install pstoedit
To convert a file named Drawing.pdf run:
$ pstoedit -f "dxf: -ctl -mm" Drawing.pdf Drawing%d.dxf
Installing the latest EagleCAD on Fedora 19 is a bit tricky. The Linux version requires libssl and libcrypto (which is thankfully mentioned right on the download page), unfortunately an older version which is no longer shipped by Fedora (Version 1.0.1 of openssl was released in March 2012).
As a (very dirty) workaround, you can just create a symlink to the current version of the shared object:
# ln -s -T /usr/lib/libcrypto.so /usr/lib/libcrypto.so.1.0.0 # ln -s -T /usr/lib/libssl.so /usr/lib/libssl.so.1.0.0
Statically mounting remote filesystems via /etc/fstab can be quite impractical on mobile devices such as notebooks that are frequently used in different network environments where the share is not always available. To take care of this, there’s a great tool called autofs that let’s you mount remote filesystems on demand.
Let’s assume, there’s an NFS server running in our network that exports a certain directory:
$ showmount -e Server Export list for Server: /data Client
To install and enable the autofs daemon, run:
# yum install autofs [...] # systemctl enable autofs.service # systemctl start autofs.service
As soon as you try to access the remote filesystem, it should get automagically mounted:
# ls -lh /net/Server/data/ [...]
Note that the subdirectory for the host isn’t created until you access it. You can also use so-called direct maps, that can’t be changed on the fly but require a HUP signal to refresh.
To use a direct map, edit /etc/auto.master and include the following line:
[...] /- /etc/auto.data [...]
Add /etc/auto.data with the following content:
/data -soft,rw,exec,intr Server:/data
The options should be quite self-explanatory. For a more comprehensive list, have a look at the autofs manpage.
Many applications rely on a fully qualified domain name and won’t work properly or even fail to start without one. For example, even if your hostname is correctly set up, apache won’t start with the default configuration on Fedora 19 if your DNS server cannot resolve the hostname:
AH00557: httpd: apr_sockaddr_info_get() failed for HostName AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
Since Fedora 19, nss-myhostname is no longer a separate package but part of the systemd package. To enable the plugin, open /etc/nsswitch.conf with you favourite editor and add myhostname to the line starting with hosts:
[...] hosts: files dns myhostname [...]