Running PulseAudio as system service

      2 Comments on Running PulseAudio as system service

Running PulseAudio in system mode is usually a bad idea. There are use cases however, where PulseAudio’s system mode is a great tool, e.g. for building a PulseAudio streaming target to stream audio from multiple clients to speakers.

First, install PulseAudio, avahi (a free implementation of zeroconf) to publish the service throughout the network and the corresponding PulseAudio module:

# yum install pulseaudio pulseaudio-module-zeroconf avahi

Since the use cases of PulseAudio in system mode are limited, distributions usually do not ship a systemd unit for it.

Description=PulseAudio Daemon


ExecStart=/usr/bin/pulseaudio --system --realtime --disallow-exit --no-cpu-limit 

For a list of available options, have a loot at the pulse-daemon manpage.

In Fedora, sound devices (/dev/snd/*) are usually owned by root:audio and since the pulse user who will run PulseAudio daemon later is not part of the audio group per default, it cannot access sound devices. Adding the pulse user to the audio group is simple though

# ls -lah /dev/snd/
total 0
drwxr-xr-x  3 root root      180 Nov 18 09:45 .
drwxr-xr-x 19 root root     3.2K Nov 18 09:45 ..
drwxr-xr-x  2 root root       60 Nov 18 09:45 by-path
crw-rw----  1 root audio 116,  2 Nov 18 09:45 controlC0
crw-rw----  1 root audio 116,  4 Nov 18 11:33 pcmC0D0c
crw-rw----  1 root audio 116,  3 Nov 18 11:29 pcmC0D0p
crw-rw----  1 root audio 116,  5 Nov 18 09:45 pcmC0D1c
crw-rw----  1 root audio 116,  1 Nov 18 09:45 seq
crw-rw----  1 root audio 116, 33 Nov 18 09:45 timer
# usermod -a -G audio pulse

To make PulseAudio available over the network, you have to add a bit of configuration to /etc/pulse/

### Enable positioned event sounds
load-module module-position-event-sounds

load-module module-native-protocol-tcp auth-anonymous=1
load-module module-zeroconf-publish

For a list of available module options, consult the PulseAudio module dokumentation, especially module-native-protocol-tcp.
auth-anonymous in particular might be a questionable idea in larger environments. An IP based access control list (auth-ip-acl) or a cookie containing some random data that serves as a shared secret between server and clients (auth-cookie) could be a more feasible approach.

Next, enable and start the PulseAudio server as well as the avahi daemon

# systemctl enable pulseaudio.service 
ln -s '/etc/systemd/system/pulseaudio.service' '/etc/systemd/system/'
# systemctl start pulseaudio.service
# systemctl start avahi-daemon.service

You should be able to see a new service being published through avahi on the client:

[user@PulseClient ~]$ avahi-browse -a
+ enp0s25 IPv4 PulseAudio [46:46:46:46:46:46]                 Workstation          local
+ enp0s25 IPv4 pulse@PulseAudio                               PulseAudio Sound Server local
+ enp0s25 IPv4 pulse@PulseAudio: Built-in Audio Analog Stereo PulseAudio Sound Sink local
+ enp0s25 IPv4 pulse@PulseAudio: Built-in Audio Analog Stereo PulseAudio Sound Source local

You could then go ahead and use paprefs on your client to make remote PulseAudio sound devices available locally:

Use paprefs to make remote sound devices available locally.

Use paprefs to make remote sound devices available locally.

Finally, you might want to enable additional audio channels or change the channel mapping on the server:

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
default-sample-channels = 4
; default-channel-map = front-left,front-right

Don’t forget to restart the PulseAudio server afterwards!


No default route with Fedora’s legacy network service

There’s a bug in Fedora 20 and RHEL 7, where the legacy network service does not set the default route properly. This is due to the fact, that the network service does not evaluate the GATEWAY0 directive in /etc/sysconfig/network-scripts/ifcfg-ethX that is used by NetworkManager.
To set the default route with the legacy network service, simply change GATEWAY0 to GATEWAY:

NAME="System eth0"

Of course, you have to set DEFROUTE=yes, too. Note that this is going to be fixed in Fedora 21.

Configuring LACP between OpenIndiana and a Dell Force10 switch

Link aggregation is a method of bundling interfaces together to act as one for increased bandwith and/or failover. One of most used protocols, next to a couple of proprietary ones, for controlling such a channel bond is LACP, the Link Aggregation Control Protocol.

1. Configuring LACP on Dell S4810

Let’s assume, we want to bond two 10G Ethernet ports together, namely TenGigabitEthernet 0/32 and TenGigabitEthernet 0/33

S4810(conf)#interface range tengigabitethernet 0/32 , tengigabitethernet 0/33
S4810(conf-if-range-te-0/32,te-0/33)#port-channel-protocol LACP                                       
S4810(conf-if-range-te-0/32,te-0/33-lacp)#  port-channel 9 mode active                                     
S4810(conf-if-range-te-0/32,te-0/33-lacp)#show conf
interface TenGigabitEthernet 0/32
 description po9 uplink to Server47
 no ip address
 flowcontrol rx on tx off 
 port-channel-protocol LACP 
  port-channel 9 mode active 
 no shutdown
interface TenGigabitEthernet 0/33
 description po9 uplink to Server47
 no ip address
 flowcontrol rx on tx off 
 port-channel-protocol LACP 
  port-channel 9 mode active 
 no shutdown

Next, the port-channel interface needs to be configured as layer 2 port and activated afterwards:

S4810(conf)#interface port-channel 9
S4810(conf-if-po-9)#description Uplink to Server47
S4810(conf-if-po-9)#no shutdown 
S4810(conf-if-po-9)#show config 
interface Port-channel 9
 description Uplink to Server47
 no ip address
 no shutdown

It’s always good practice to also change the description. Depending on your configuration, you might want to change the vlan settings for this newly created port-channel as well:

S4810(conf)#interface vlan 11
S4810(conf-if-vl-11)#untagged port-channel 9
S4810(conf-if-vl-11)#show config            
interface Vlan 11
 description VLAN11-LAN
 ip address
 tagged TenGigabitEthernet 0/8-13
 tagged Port-channel 1-5,11,13-14
 untagged TenGigabitEthernet 0/14,19-20,23,38,46
 untagged Port-channel 9
 ip helper-address
 no shutdown

Of course, depending on the actual network topology, your mileage might vary here.

Note that the port-channel will stay in a ‘down’ state until it can exchange LACPDUs with the remote end:

S4810(conf)#do show interfaces port-channel 9 brief
Codes: L - LACP Port-channel

    LAG  Mode  Status       Uptime      Ports          
L   9    L2L3  down         00:00:00    

2. Configuring LACP on OpenIndiana

First, disable the NWAM (Network Auto Magic) service:

# svcadm disable svc:/network/physical:nwam
# svcadm enable svc:/network/physical:default

To list the available physical ports, use dladm

root@Server47:~# dladm show-phys
LINK         MEDIA                STATE      SPEED  DUPLEX    DEVICE
myri10ge1    Ethernet             down       10000  full      myri10ge1
myri10ge0    Ethernet             down       10000  full      myri10ge0
bnx2         Ethernet             down       0      unknown   bnx2
bnx0         Ethernet             up         1000   full      bnx0
bnx1         Ethernet             down       0      unknown   bnx1
bnx3         Ethernet             down       0      unknown   bnx3

To create an aggregate device with two links (myri10ge0 and myri10ge1) in LACP mode (-L active) with and L2 failover policy (Determines the outgoing link by hashing the MAC (L2) header of each packet), run:

dladm create-aggr -l myri10ge0 -l myri10ge1 -L active -P L2 aggr1

You can use dladm show-aggr to see the current state:

root@Server47:~# dladm show-aggr
aggr1           L2       auto                 active        short       -----

Next, create an interface aggr1:

root@Server47:~# ipadm create-if aggr1
root@Server47:~# ipadm show-if
lo0        ok       -m-v------46 ---
bnx0       ok       bm--------46 -46
aggr1      down     bm--------46 -46

You should now see that the LACP link is established on the layer 2 switch:

S4810(conf)#do show interfaces port-channel 9 brief
Codes: L - LACP Port-channel

    LAG  Mode  Status       Uptime      Ports          
L   9    L2L3  up           00:00:00    Te 0/32    (Up)
                                        Te 0/33    (Up)

The last thing left to do is to create an IP address on top of the aggr1 interface:

root@Server47:~# ipadm create-addr -T static -a aggr1/v4

Again, depending on your topology, you might want to add/edit you default route to go over the aggragate interface.

Setting up an authenticating proxy server with squid3 and pam_auth

While the squid proxy server has quite a few different flavours of authentication available, one of the most basic ones, pam_auth, is also one of the most useful ones to get you started quickly. pam_auth let’s anyone who has a local account access the squid proxy. In large environments you probably want to use ldap authentication eventually, but pam_auth is great for testing purposes.

Let’s install squid3 first:

# yum install squid

A minimal squid configuration file for an authenticating proxy is not too different from the default configuration file that comes with the squid rpm package. The changed parts are hightlighted

# Recommended minimum configuration:
acl manager proto cache_object
acl localhost src ::1
acl to_localhost dst ::1

auth_param basic program /usr/lib64/squid/pam_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src     # RFC1918 possible internal network

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl password proxy_auth REQUIRED

# Recommended minimum Access Permission configuration:
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
http_access deny to_localhost


# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
http_access deny !localnet
http_access allow localhost
http_access allow password

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128

# We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256

# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid

# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern .               0       20%     4320


Since the documentation on squid is quite comprehensive, there’s no need to go into detail. You can also look up individual configuration directives Configuration Reference Manual.

Configuration of the squid PAM authentication helper pam_auth is quite simple. It just needs a PAM service to be configured /etc/pam.d/

auth            include         password-auth
account         include         password-auth

pam_auth also need the correct permissions to access the user password database, which basically requires it to run as root (path is /usr/lib64/squid/pam_auth on CentOS 6 and /usr/lib64/squid/basic_pam_auth on recent versions of Fedora)

chmod u+s /usr/lib64/squid/basic_pam_auth

Please note, that it’s not recommended to use pam_auth for authenticating to a local unix shadow password database. You should at the very least make sure, that it’s in a directory, regular users can’t access.

That’s it. Now enable and start the squid proxy server:

# systemctl enable squid.service 
ln -s '/usr/lib/systemd/system/squid.service' '/etc/systemd/system/'
# systemctl start squid.service

The proxy is then reachable at

See also pam_auth manpage

Baikal: A lightweight CalDAV/CardDAV server

      No Comments on Baikal: A lightweight CalDAV/CardDAV server

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.

Continue reading

Installing kvm on Fedora 20

      No Comments on Installing kvm on Fedora 20

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.

0. Prerequisites

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
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:


Second, we’ll need to alter the configuration file for the ethernet device to add the device to the bridge


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/'
# systemctl start libvirtd.service

You can now go ahead and connect to the libvirt-daemon with a GUI, like virt-manager or install a virtual machine with virt-install.

Invoking logrotate manually

      No Comments on Invoking logrotate manually

To invoke logrotate manually to debug configuration settings, there is a builtin debug flag:

# 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 /etc/logrotate.conf.

For a comprehensive list of options, have a look at the logrotate manpage.

Instaling ownCloud with nginx and php-fpm

      3 Comments on Instaling ownCloud with nginx and php-fpm

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.

Continue reading

Revoking an OpenVPN certificate

      5 Comments on Revoking an OpenVPN certificate

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 =, CN = client, name = client, emailAddress =
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/

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[493]: CRL CHECK FAILED: C=US, ST=CA, L=City, O=name,, CN=client, name=client, is REVOKED

See also OpenVPN 2.3 manpage