Fedora people provide everything to build a RPM package of the latest Spotify client.

sudo yum install rpm-build rpmdevtools yum-utils
rpmdev-setuptree
cd $HOME/rpmbuild/SPECS
wget http://leamas.fedorapeople.org/spotify/0.9.0/spotify-client.spec
cd $HOME/rpmbuild/SOURCES
spectool -g ../SPECS/spotify-client.spec
cd -
sudo yum-builddep spotify-client.spec
QA_RPATHS=$[2|8] rpmbuild -bb spotify-client.spec
rpm -Uvh $HOME/rpmbuild/RPMS/x86_64/spotify-client-0.9.0.133.gd18ed58.259-2.fc18.x86_64.rpm

Synology NAS devices offer a built-in service to backup all configuration, applications and shared folders to a remote rsync server. Below is a short howto describing the steps required to setup the remote rsync services on a CentOS 6 server.

Install rsync and xinetd.

yum install rsync xinetd

Create configuration file.

# /etc/rsyncd.conf
gid = nobody
uid = nobody
read only = no
use chroot = yes 
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
secrets file = /etc/rsyncd.secrets
hosts allow = 192.168.1.0/24

[synology]
comment = Backup of Synology
path = /data/synology
auth users = synology

Create password file.

# /etc/rsyncd.secrets 
synology:plaintextpassword

Restrict its file permissions.

chmod 600 /etc/rsyncd.secrets

Enable rsync service in xinetd by setting disabled = no in /etc/xinetd.d/rsync and restart xinetd.

Open rsync port in iptables and make the change permanent.

iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 873 -j ACCEPT
service iptables save

Finally, fix selinux config and context of the destination directory.

setsebool -P allow_rsync_anon_write=1
chcon -t public_content_rw_t /data/synology

The Synology NAS should be able to establish a connection to the remote rsync server and do backups.

It is the fourth time that I post a Hello world in this blog. I did this whenever I changed the underlying blogging software. It started with Movable Type, a bit later I added a microblog in the same software. After years I merged both into Wordpress and with this post I am going to relaunch it using Octopress.

package main

import "fmt"

func main() {
    fmt.Println("Hello, world")
}

SFTP is a subsystem of SSH and quiet easy to set up. It has some limitations compared with FTP and it is not to be confused with FTPS (FTP over SSL/TLS). The requirement is just to provide a way to transfer files from and to a server with secure authentication and connection. We also want to the user access be limited to the homedir using SSH ChrootDirectory directive and enforce SFTP protocol (user should not be able to use SSH instead).

All changes that need to be applied on a SSH enabled host are that you have to add /usr/lib/openssh/sftp-server to /etc/shells and replace the Subsystem sftp line in /etc/ssh/sshd_config as below:

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

Since we want to chroot the user to her homedir and do not want her to see names of other users, we have to create a little mess of subdirectories and chroot here. SSH requires chroot to be one level above homedir.

We need two users per share. One should have read-write permissions (push), the other should have read-only access (pull). The addsftpuser script below creates the users and outputs a part of SSH config that defines some rules for the new users. Those lines should be added to /etc/ssh/sshd_config and SSH should be restarted to load the new config.

#!/bin/bash

set -e

if [ $# -ne 2 ]
then
  echo "Usage: $(basename $0) username environment"
  exit 1
fi

USER=$1_push_$2
USERRO=$1_pull_$2
read -p "Password push-user: " PASS
read -p "Password pull-user: " PASSRO

groupadd ${USER}
GROUP=$(getent group $USER | cut -d: -f3)

mkdir -p /home/sftp/$USER
useradd -d /home/sftp/$USER/$USER -m -s /usr/lib/openssh/sftp-server
-g $GROUP -p $(openssl passwd -1 $PASS) ${USER}
useradd -d /home/sftp/$USER/$USER    -s /usr/lib/openssh/sftp-server
-g $GROUP -p $(openssl passwd -1 $PASSRO) ${USERRO}

cat <<END

To make the user able to connect via SFTP, you MUST add these lines to
your /etc/ssh/sshd_config and restart sshd afterwards:

Match User $USER
    ChrootDirectory /home/sftp/$USER
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

Match User ${USERRO}
    ChrootDirectory /home/sftp/$USER
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

END

How do I count all the files recursively through directories

Until last week I thought it would be necessary to configure Tomcat and its webapps as a big monolithic system. What a great mistake! I have learned that there is a much easier way to run webapps in Tomcat. Actually each webapps becomes its own application server, executed with a dedicated user. I will demonstrate this way by showing how to install Jenkins.

First install Java JDK and Tomcat into /opt. In this case, I have just unpacked the tarballs there and created symlinks to have an easy way to upgrade to newer versions.

root@debian:/opt# ls -l
total 8
drwxr-xr-x 9 root root [...] apache-tomcat-6.0.35
lrwxrwxrwx 1 root root [...] java7 -> jdk1.7.0_03
drwxr-xr-x 8 root root [...] jdk1.7.0_03
lrwxrwxrwx 1 root root [...] tomcat6 -> apache-tomcat-6.0.35

Add a new user for Jenkins and create the base skeleton of Tomcat directories in its homedir /home/jenkins. Copy the conf directory from your Tomcat installation. The other directories are empty. Download the Jenkins WAR file and save it in the webapps directory.

root@debian:/home/jenkins# ls -l
total 28
drwxr-xr-x 2 jenkins nogroup [...] conf
drwxr-xr-x 6 jenkins nogroup [...] data
drwxr-xr-x 2 jenkins nogroup [...] logs
drwxr-xr-x 3 jenkins nogroup [...] temp
drwxr-xr-x 3 jenkins nogroup [...] webapps
drwxr-xr-x 3 jenkins nogroup [...] work

Create /home/jenkins/.profile to define the application server environment variables.

# Applicationserver enviroment
export JENKINS_HOME=/home/jenkins/data
export JENKINS_BASEDIR=${HOME}
export CATALINA_HOME=/opt/tomcat6
export CATALINA_BASE=${HOME}
export JAVA_HOME=/opt/java7
export CATALINA_PID=${JENKINS_BASEDIR}/jenkins.pid
export CATALINA_OPTS="-Xms2048m -Xmx2048m -Djava.awt.headless=true"
export PATH=${CATALINA_HOME}/bin:${JAVA_HOME}/bin:${PATH}

Last step is to put an init script for Jenkins into /etc/init.d/jenkins.

#!/bin/bash
#
# Startup / shutdown script for the jenkins server.
#
### BEGIN INIT INFO
# Provides:             jenkins
# Required-Start:       $network $local_fs
# Required-Stop:
# Should-Start:         $named
# Should-Stop:
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    Jenkins
# Description:          Jenkins Continuous Integration server
### END INIT INFO

SCRIPT_USER=jenkins
LOCKFILE=/var/lock/jenkins
export TOMCAT_HOME=/opt/tomcat6
[ -f $TOMCAT_HOME/bin/catalina.sh ] || exit 0
case "$1" in
  start)
        # Start daemon.
        echo -n "Starting Jenkins: "
        su -l $SCRIPT_USER -c "$TOMCAT_HOME/bin/catalina.sh start"
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && touch $LOCKFILE
        ;;
  stop)
        # Stop daemons.
        echo -n "Shutting down Jenkins: "
        su -l $SCRIPT_USER -c "$TOMCAT_HOME/bin/catalina.sh stop"
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && rm -f $LOCKFILE
        ;;
  restart)
        $0 stop
        $0 start
        ;;
  condrestart)
       [ -e $LOCKFILE ] && $0 restart
       ;;
  status)
        status jenkins
        ;;
  *)
        echo "Usage: $0 {start|stop|restart|status}"
        exit 1
esac
exit 0

Now you can start Jenkins as a seperate service. Repeat the steps from above for each webapp that you need.

This setup makes it possible to start or stop each webapp independent from the others. It also allows you to run webapps with different Java or Tomcat versions or easily change the underlying Java and Tomcat versions (just refer to them in .profile).

In most environments, people want to access their Subversion repositories over a HTTPS connection. This requires a webserver like Apache, which provides WebDAV and SVN modules. I just switched over to nginx and do not want to install Apache just for SVN only. So I started to search for an alternative method which should be easy and secure.

I found svn ssh. I knew SVN over SSH already but I remembered that there were some problems with file permissions and I did not really liked the idea of having Unix accounts for each SVN user on the system. What I realized then was that there is a pretty nice workaround perfect solution.

First of all, let us create a new SVN user. Only this user will access the repositories.

adduser --home /var/svn --shell /bin/bash --disabled-password svn

Next step is to create a new repository and import the basic directory structure.

for dir in trunk branches tags; do mkdir -p /tmp/project1/$dir; done
mkdir /var/svn/repos
svnadmin create /var/svn/repos/project1
svn import /tmp/project1 file:///var/svn/repos/project1 -m "Initial import"

All the magic is done in the SVN user’s SSH authorized_keys file.

command="/usr/bin/svnserve -t -r /var/svn/repos --tunnel-user=user1",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding ssh-rsa AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== user1@example.com
command="/usr/bin/svnserve -t -r /var/svn/repos --tunnel-user=user2",no-port-forwarding,no-pty,no-agent-forwarding,no-X11-forwarding ssh-rsa AAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB== user2@example.com

You can limit user access per SSH public key. In this case we force the user to execute svnserve, we can limit to repository and we can set a username with --tunnel-user which is used for commits. Additionally, we can disallow all non-SVN stuff to prevent login to shell or port-forwarding etc.

That’s it. Check out your repository and start working with it.

svn co svn ssh://svn@example.com/project1/trunk project1

It seems like there is a hardware problem at least on some motherboards of DELL XPS 8300. It appears to be an initialization issue of the network chipset (Broadcom NetLink BCM57788 Gigabit) when you turn on the computer at low temperatures. When OS starts, the NIC is not detected and therefore not usable. As soon as the PC warms up (usually after some minutes), you can restart and the problem is gone until next cold restart.

Seriously, those PCs needs preheating like an old diesel engine. Since there is no choke, you can try with a hair dryer instead. Let’s see how DELL support handles this…

wget --quiet -O- https://www.pingdom.com/rss/probe_servers.xml | perl -nle 'print $1 if /IP: (([01]?dd?|2[0-4]d|25[0-5]).([01]?dd?|2[0-4]d|25[0-5]).([01]?dd?|2[0-4]d|25[0-5]).([01]?dd?|2[0-4]d|25[0-5]));/'

The friendly guys from Linux Mint wrote some Gnome Shell extentions which make Gnome 3 feel more like Gnome 2. The good thing is that you can benefit from that even if you are using a different distribution. First of all, we will install the Linux Mint Shell Extensions for Gnome 3 (MGSE).

$ git clone https://github.com/linuxmint/MGSE.git
$ cd MGSE/
$ ./test

To make the Gnome Shell load the new extentions, reload Gnome Shell by hitting ALT-F2 and executing r.

Use gnome-tweak-tool to activate the extentions you want.