Apps

For a long time Apache has been the software choice for admins and developers wishing to setup a web server. It is therefore no surprise, that Apache dominates when it comes to the most deployed web server on the Internet today. Take a look at Netcraft’s survey as of January 2015.

I have used Apache since the early days of the Internet, but lately, I’ve noticed its become very bloated. In fact for any embedded developers out there, Apache is these days frown upon, when it comes to arm based devices such as the Raspberry Pi. Here is where Nginx comes in. It is very light weight and fast, and can easily be installed in your embedded and other web server projects. Try it, and you may find yourself liking it so much, that you’ll switch from running Apache in your enterprise or hosting environment.

Nginx is an open source high performance HTTP and reverse proxy server. It is very scalable and very suitable for production environments that need to serve many requests. Compared to Apache, Nginx handles requests using an asynchronous event-driven approach. Apache uses a process/thread oriented approach which makes it unpredictable when it comes to very high loads.

While installation via packages managers such as yum or apt is possible, I chose to install Nginx on a Raspberry Pi using sources. Going the source-install route has some benefits, one of which is that you get the latest version of Nginx, which usually takes sometime to make its way to distribution package repositories. Lets get started with the install.

Download sources:

cd /tmp

wget -c http://nginx.org/download/nginx-1.7.10.tar.gz


tar zxvf /tmp/nginx-1.7.10.tar.gz -C /usr/src

cd /usr/src/nginx-1.7.10

./configure --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --with-perl_modules_path=/usr/lib/perl5/auto/nginx --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/lock/subsys/nginx --user=nginx --group=nginx --with-http_addition_module --with-http_auth_request_module --with-http_degradation_module --with-http_perl_module --with-http_flv_module --with-http_geoip_module --with-google_perftools_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_image_filter_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_dav_module --with-http_xslt_module --with-file-aio --with-ipv6 --with-mail --with-mail_ssl_module --with-ld-opt="-Wl,-E"

Notice that I added several optional modules, which means any dependencies need to be resolved before you proceed. You can read about built-in and optional modules at: http://wiki.nginx.org/Modules. On Fedora 20 I ran into errors starting nginx, so I added the configure option –with-ld-opt=”-Wl,-E” to resolve it

make && make install

Create the server user and group:

On Red Hat based systems like Fedora, run the following command to add a user and group for the webserver:

useradd -M -r -c "Nginx Web Server" -s /sbin/nologin -d /var/spool/nginx nginx

Setup directory permissions:

Give nginx user the permission to use directories

chown -R nginx:nginx /usr/share/nginx
chown -R nginx:nginx /var/log/nginx

Add the start up script

In order to automatically start nginx at boot time, you will need to setup an init script. Luckily, the folks over at Nginx have put together several star/stop scripts depending on your Linux distribution. You can collect them at: http://wiki.nginx.org/InitScripts

Since Am using Fedora and hence systemd, the following is the start up script:

[Unit]
Description=The nginx HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Install]
WantedBy=multi-user.target

Save this file at: /usr/lib/systemd/system/nginx.service.

Enable it to start automatically at boot.

systemctl enable nginx.service.

Testing:

Start Nginx:

systemctl start nginx.service

check to see if Nginx is listening on port 80

lsof -i :80 (You need the package lsof, if not use netstat)

Open your browser and go to:
http://localhost/

You will be greeted by a welcome HTML page.

That’s it for now. Next time, I will take a look at how to configure Nginx, and even enable PHP, so you can install most Content Management Systems (CMS) like wordpress on your web server easily.

For a long time, the default boot and initialization mechanism in Linux was the System V (SysV) init daemon. Along the way, many Linux distributions have attempted to move away from this primitive form of booting. Why you ask? For one thing, it makes the boot process a lot slower, since processes have to be started one at a time. It is also a nightmare to maintain the scripts that Administrators write to manage these start processes, as each package maintainer or administrator, does ‘their own thing.’

So Ubuntu, one of the most popular Linux distributions moved to upstart in late 2006, but this init daemon they adopted, was not widely embraced. Debian, OpenSuse, Fedora, and Red Hat at some point in the last five years supported upstart. Red Hat Enterprise Linux (RHEL) version 6 and derivatives such as  CentOS  still use upstart. But all of them are ditching upstart for something better, i.e. SystemD. In fact, the Debian technical committee recently voted and they will switch to SystemD in upcoming releases, leaving Ubuntu no choice but to follow.

It now looks like SystemD will be the default initialization and boot method for Linux systems for many years to come. But what does systemD do different?

What is SystemD?

SystemD, is a system and services manager for Linux that was developed by a team from Red Hat, spearheaded by Lennart Poettering, the creator of pulseaudio, and Avahi. SystemD makes Linux systems boot faster since processes are ran in parallel. Once started, processes are monitored, and restarted if they crash. SystemD also reduces the dependency on shell scripts to do much of the work.

Other systemD features, include a cron-like job scheduler, an integrated login manager, which offers ‘multi-seating’ functions. It also has a new an improved logging mechanism called the journal, that will likely replace syslog, the current logging facility on Linux systems.

Below is some technical information to get you as the administrator started with systemD. Please note that there are several manuals and online resources available that will help you understand systemD, I will mention a few at the end of this post.

How to get started with systemD

SystemD is installed by default on recent versions of Fedora, and Arch Linux. For other distributions like Debian and Ubuntu, you might have to wait a bit for systemd to be packaged as the default init system. It is actually recommended that installation is done by the distribution vendors. But if you are the brave type, you can of course install it from source.

Pick up the source tarball and follow the instructions contained in the README file included with the sources.

After installation is completed, you will need to start converting your old startup scripts to systemD. At this time, only SysV init scripts for commonly used services, have been ported to systemD. So you will need to know how to write a service file for rarely used daemons or for that program you are developing. Below is an example of a systemd service file. By the way, these are what those files in “/etc/init.d” used to be.

How to write a systemD service file

Open up your favorite editor such as vim as follows:
vim /tmp/squid.service Am using squid here as an example, so replace it with the name of your service. Enter the following snippet:

[Unit]
Description=Squid caching proxy
After=syslog.target network.target nss-lookup.target

[Service]
Type=forking
EnvironmentFile=/etc/sysconfig/squid
ExecStartPre=/usr/libexec/squid/cache_swap.sh
ExecStart=/usr/sbin/squid $SQUID_OPTS -f $SQUID_CONF
ExecReload=/usr/sbin/squid $SQUID_OPTS -k reconfigure -f $SQUID_CONF
ExecStop=/usr/sbin/squid -k shutdown -f $SQUID_CONF
PIDFile=/var/run/squid.pid

[Install]
WantedBy=multi-user.target

At a minimum, you will need these three sections; unit, service, install.

Unit definitions
Description: A string describing the service and what it does.
After: If service depends on another one, then indicate that it should come after those targets. Notice in my example that one of the pre-requisites for this service is the network service. You will see that often, as most services expect the network to be already running, so always include it.
You can also add ‘Before’ which does the opposite and starts this service before units listed.
Hint: You can read more about unit definitions by calling up the manpage: man systemd.unit

Service definitions
Type: You must always have a type, which can either be forking, simple, oneshot, dbus, or notify. For most daemons, forking should suffice, as it forks the processes by putting them in the background after start.
EnvironmentFile:This is the file which contains the options used by your service daemon. This can be omitted, but can be a life saver occasionally
ExecStartPre: This is the command that is called before the main process – see ExecStart
ExecStart: This is the command that the daemon runs. You can also point to a script on your system e.g. =/bin/sh -c “/usr/sbin/my-cool-script.sh”
ExecStartPost: This is the command that is called after the main process – see ExecStart
ExecReload: This is the command that is called in order to reload the daemon’s configuration file.
ExecStop: This is the command that is used to stop your service.
PIDFile: Enter the file path containing the process ID of your service. SystemD reads this file after startup.
Hint: You can read more about service definitions by calling up the manpage: man systemd.service

Install definitions
This section is optional, but can be used to set the target level
WantedBy: Set a target where this service will be grouped. Like run levels in SysV language.
Hint: You can read more about various special targets by calling up the manpage: man systemd.special

Activating your systemd service

When you are done writing the service file, copy it to: /usr/lib/systemd/system/
cp -v /tmp/squid.service /usr/lib/systemd/system/

You will need reload the systemd daemon:
systemctl --system daemon-reload
In order for the service to start automatically at boot time, enable your systemd service as follows:
systemctl enable squid.service
Now when you want to start, stop, reload or check the status of this service; do the following:

systemctl COMMAND squid.service ; where COMMAND is either {start|stop|reload|status}

This how-to barely scratches the surface. There are lots of neat tricks you can perform with systemD that your old dog SysV and upstart could not. So take the time to learn it.

Resources:
SystemD website: http://www.freedesktop.org/wiki/Software/systemd
Lennart’s Blog: http://0pointer.de/blog(Look for the SystemD series for Administrators)
Mailing List: http://lists.freedesktop.org/archives/systemd-devel
Man pages: systemd- (Use tab completion to see all available man pages)

I recently submitted initial DVB-T scan data for Kampala to the dvb-apps package upstream. If you are testing DVB-T2 in Uganda using Linux, please go ahead and clone the latest git sources at:
http://git.linuxtv.org/dtv-scan-tables.git

Its still early, but at least with the latest sources, you do not have to tinker around in your app.

Also, I’m looking for testers in the region. If you’re already using DVB-T with Linux, please contact me.

I was reading this google+ post by Linux’ very own Linus Torvalds. One of the comments reads “I feel like Mom and Dad are fighting. I love Fedora and I love Linux :)” Clearly, Linux distributions come with their own specific set of packaging rules and guidelines. Sometimes, it does not make sense to everyone. And when that someone else is Linus, people will go ‘bonkers’ to either agree or disagree with him. But why the noise?

To any one who’s not ventured into the murky waters of Linux kernel building and packaging, you may be wondering why a topic like this one solicits such responses even if its not coming from the man who invented Linux. Believe me – it is a big deal.

Due to the rapid development of open-source software, the Linux kernel and packages on the original CD/DVD images tend to become outdated over a short period of time. Sometimes, those packages become insecure and vulnerable. Furthermore, with all the latest and cool hardware devices that vendors are producing every other day, the Linux kernel has to be upgraded so as to be fully usable by those devices.

So in my opinion, Linus Torvalds is half right, since non-techie users need to get Linux working straight out of the box. My feeling though is that the main distros are really not meant for the Linux newbies. That is why re-spins seem to be a lot popular with new Linux users. So if you made it this far and are still reading this, how do you go about creating a re-spin? Here is one way:

Lately, I’ve been spending sometime, creating customized versions of the Fedora Linux images. I use these Fedora re-spins for the embedded products I’ve been working on such as the JambulaPi, TV STB etc. BTW, these re-spins of Fedora are open source and free, so I plan on posting them to a public site in a not too distant future!

A very useful tool for creating custom images for Fedora Linux is called livemedia-creator. Livemedia-creator uses Anaconda, kickstart and Lorax to create bootable media such as live iso’s that use the same install path as a normal system install.

To install it:

sudo yum install lorax

Then, take a look at the readme file located at /usr/share/doc/lorax-*/README.livemedia-creator. There you will find examples on how to set up your very own customized Linux distribution. A kickstart file is highly recommended as you can add other repositories for installing software that is not originally included in the Fedora releases. Also, it lets you do things like adding initial users, etc. Take a look at Kickstarting Fedora Linux installations.

Asterisk is the popular open source telephony platform. With just a few hours to spare, you can turn any spare PC in to a world class PBX system. In part 1, I will list the steps involved in installing asterisk using sources. The steps below can be used with RedHat based systems like Fedora. It shouldn’t be that hard to replicate on other Linux distributions like Ubuntu.

Update your system and reboot if there’s a kernel upgrade:
yum update

For Redhat systems, disable selinux:
sed s/SELINUX=enforcing/SELINUX=disabled/g /etc/selinux/config

Install required dependencies:
yum -y install make wget openssl-devel ncurses-devel newt-devel libxml2-devel kernel-devel gcc gcc-c++ sqlite-devel

Download current asterisk 11 sources:
cd /usr/src
wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gz
wget http://downloads.asterisk.org/pub/telephony/libpri/libpri-1.4-current.tar.gz
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/dahdi-linux-complete-current.tar.gz


Note: Dahdi is only needed if you will be using a telephony card to access the PSTN. Timing provided by dahdi is also no longer needed with the new conferencing capabilities in Asterisk 11

Unpack and install the source packages. Please note that the installation order is very important:

c) tar zxvf asterisk-11-current.tar.gz
cd asterisk*
./configure --libdir={LIBDIR} e.g /usr/lib64 (use uname -a to confirm architecture"
make menuselect (optional)
make && make install
make samples (on fresh install only)
make config


Start services
service dahdi start
service asterisk start


Check to ensure is running:
asterisk -vr

In part 2, I will go over how to configure your asterisk server.

Email is a great tool for communication and that is why even in the age of social networks, it persists. However, if you work in an office environment that requires constant and real-time communication between users, email may not cut it. Sometimes you just want to send a quick message without clogging your users Inboxes. What you need is an instant messaging system.

There are quite a number of open source based IM messaging servers; however, I like and have used jabberd over the years. Jabberd2 is an open source implementation of the jabber/XMPP protocol used by popular IM clients.

Installation of jabberd2 on Linux is fairly easy, although you need to know your way around the command line interface and how to edit configuration files.

To start with, install jabberd2. On Fedora/CentOs/RedHat systems:

yum install jabberd

After installation, you will find all configuration files located under /etc/jabberd

You will need to edit the files sm.xml s2s.xml c2s.xml, router.xml; and templates/roster.xml to suit your environment. Then setup your user accounts in your preferred driver backend. Detailed configuration instructions can be found here.

Now all you need to do is install an IM client on your users PCs. There are several of these for all platforms. On Linux; favorites include pidgin and empathy

One cool thing with jabberd2, is that it is very extensible and you can add chat rooms functionality; a sort of ‘circles’ – old school style