Just open the cron file for the user who in whose name the command is supposed to run.

crontab -e

Add the following line to the open cron file and obviously replace YOUR COMMAND with whatever should be run on start-up.

@reboot YOUR COMMAND

Save the changes and now on every boot your command is executed once. Simple as that!

This post originated from the Linux Showroom feed. Please check out Linux Showroom for more posts.

Execute command on every boot

That´s what just has happened to me. Why is Memcache not cacheing I asked myself. Well, the default and highly recommend slabs size is 1 MB. Anything above just is not cached. Setting that limit higher with -I Xm (X being an integer) results in a warning which sounds really bad:

Starting memcached WARNING: Setting item max size above 1MB is not recommended!
Raising this limit increases the minimum memory requirements and will decrease your memory efficiency.

Hmm, not so good. Luckily I was able to downsize that particular item so that memcache stores it again.

I am still wondering if serving content from harddisk instead of RAM via memcached could be a good idea. I gotta try it one of these days. What do you think?

This post originated from the Linux Showroom feed. Please check out Linux Showroom for more posts.

Memcache is not cacheing

Start off by logging IP addresses for a while.

1

varnishlog -c -i RxHeader -I X-Forwarded-For > varnish.log

After you have collected enough information use the following line to find out which IP caused the most hits on your varnish.

1

cat varnish.log | cut -d ' ' -f 12 | sort | uniq -c | sort -n

Query the ripe database to find information on the IP addresses.

This post originated from the Linux Showroom feed. Please check out Linux Showroom for more posts.

Use varnishlog to find hosts which cause most hits

# last

Calling last on your commandline gives you a list of logins. You will see who is still logged in and who was logged in before from what adress.

You can shorten the list of results with last -n XX. XX being the number of results you want to have displayed, e.g. last -n 5 for 5 lines.

# last reboot

Calling last reboot lists the reboots since the log file which tracks all logins was created.

The manual page for last – man last – will show you more parameters.

This post originated from the Linux Showroom feed. Please check out Linux Showroom for more posts.

Useful shell commands: last

I share the website’s HTML, images and other resources through the NFS server to all five servers. All servers work as webservers with nginx and PHP-fpm. Each server also runs one more specific service: database master, solr master, cron jobs / crawler processes, Varnish / HAproxy.

The two directly connected servers share the static website resources over drbd. Pacemaker, heartbeat and openais secure the high availability of my NFS4 server. Setting this up took quiet a bit of fiddeling as there are how-tos for so many different (and outdated) versions are floating around the internet.

This post originated from the Linux Showroom feed. Please check out Linux Showroom for more posts.

High available NFS4 server with drbd 0.8, pacemaker 1.0, heartbeat, openais on OpenSUSE 11.1

You can get up-to-date packages of nginx through OpenSuSE’s build service. I have not yet found a RPM package of php-fpm though. Therefore I compile it myself. This works well and I have the advantage that I can customize by PHP package.

But there is also one disadvantage. There is no system runlevel script available this way. So you cannot make use of the rc stuff on OpenSuSE and start PHP at boot time. As I have quiet a few machines to administer I decided to write my own runlevel script to start php-fpm.

Looking closer into the stuff that is already delivered with the php-fpm package is a powerful start script. I took it as the basis of my script. I had to modify it only in a few places. Big thanks to the author(s)!

It will take a few easy steps to get php-fpm running after booting.

1. Download my modified php-fpm script to your server’s runlevel directory (/etc/rc.d).
2. Rename the file by removing the file extension (.txt)
3. Give your superuser (root) rights to execute it.
4. Open the file php-fpm in your favorite editor (Vim, emacs, joe, …).
5. Modify the three lines (php_fpm_BIN=, php_fpm_CONF=, php_fpm_PID=) on top to match your installation directory of php-fpm.
6. Save and close the file.
7. Start yast with yast runlevel and switch to expert mode with Alt+x
8. Activate php-fpm for runlevels 3 and 5 (or whatever suits you). Save your changes with Alt+o. That’s it!

Now your php-fpm installation starts on boot. If you ever have to reboot your machine you do not have to think about starting php-fpm manually as the system does it for you.

Let me know if this was helpful for you, if it works and if you have any questions!

This post originated from the Linux Showroom feed. Please check out Linux Showroom for more posts.

php-fpm runlevel start script for OpenSuSE 11.1

zypper refresh
zypper dist-upgrade

I did excatly that. It did refresh a few packages but as I guessed immediately not enough. I tried over. It did not help. Here is the solution. Delete all subdirectories in /var/cache/zypper and execute the commands above again.

This post originated from the Linux Showroom feed. Please check out Linux Showroom for more posts.

System upgrade openSUSE 11.0 to openSUSE 11.1 with zypper

I was thinking of deploying jabber services for podcast.de for a while now but couldn’t decide which server to take. I checked the ejabberd website. The software looks promising. So I give it a try.

smart install ejabberd

Could not find any results. So I check OpenSuSE software search. Luckily it lists a source which I add to my smart sources.

smart channel --edit

[Cyberorg]
type = rpm-md
name = Cyberorg
baseurl = http://download.opensuse.org/repositories/home:/cyberorg:/sugar/openSUSE_11.0/

On to install the ejabberd package:

smart install ejabberd

I get a report that I am still missing a package for erlang as ejabberd is written in erlang. I use the OpenSuSE software search again which lists the following source:

[NicoK]
type = rpm-md
name = NicoK
baseurl = http://download.opensuse.org/repositories/home:/NicoK/openSUSE_11.0/

Now I can install ejabberd: ejabberd-2.0.0-2.11@x86_64
I also need one more package: erlang-R12B4-18.11@x86_64

The beauty of installing pre-compiled RPMs on OpenSuSE. You almost always get a rc-file along with the RPM (for server software that is).

rce -> Tab -> rcejabberd

There it is. Great! Now I want to change the default configuration. I would expect a config file to sit in /etc/sysconfig but ejabberd brings its own directory under /etc/ejabberd where two config files reside: ejabberd.cfg and ejabberdctl.cfg.

I read before that ejabberd.cfg is the heart of ejabberd. So I edit this for local usage only ATM.

{hosts, [{ip, {127, 0, 0, 1}}]}.

I give it a try:

rcejabberd start
Starting ejabberd    done

Looks like it started. Too bad checking http://127.0.0.1:5280/admin does not work. I check for an error in the log dir /var/log/ejabberd/ just to find out no files have been created. ps aux shows me some erlang stuff is running: /usr/lib64/erlang/erts-5.6.4/bin/epmd -daemon but no jabber process(es) which I would suspect.

I am increasing the loglevel to debug (5):

{loglevel, 5}.

No change. I remove -detached in the run script and try again. This time I get debug messages on the shell:

rcejabberd start
Starting ejabberd Erlang (BEAM) emulator version 5.6.4 [source] [64-bit] [smp:2] [async-threads:0] [hipe] [kernel-poll:false]
{"init terminating in do_boot",{undef,[{ejabberd,start,[]},{init,start_it,1},{init,start_em,1}]}}
Crash dump was written to: erl_crash.dump init terminating in do_boot()    failed

At this point I have to give up the experiment as I have no time to fiddle around with erlang problems.

This post originated from the Linux Showroom feed. Please check out Linux Showroom for more posts.

ejabberd on GNU/Linux OpenSuSE 11.0

I was never really satisfied with the speed of our system under load. I tried and tried. I optimized a lot of stuff in the backend and with the database. Most of the time I found a switch to make the system just a bit faster. Read Retrospective on three years of Seagull development if you are interested in the whole story.

In the last couple of weeks I ran out of ideas on where to improve next (without the need of rewriting too much code). I remembered using Squid years ago. I had a look at the newest version (3.0) and my interest in Squid stopped pretty soon after reading through the documentation. It was just not the software I needed.

I dived into spreading the load to multiple backends using HAproxy which by the way has a super active community. Check the mailinglist. The maintainer Willy is doing a great job. Learning about HAproxy I stumbled across the webserver nginx (pronounced engine x) numerous times. Learning about nginx I stumbled across the reverse proxy Varnish which is the proxy solution I hoped Squid would be. Furtherdown the line I ran into PHP-FPM – the PHP FastCGI Process Manager – which should not stay unmentioned.

So I read lots of blog posts, mails from mailinglists, documentation, articles, visited several forums and also learned many new things in a few wikis. So after getting the idea I had my stack together: Varnish -> HAproxy -> nginx -> PHP -> MySQL

Time to test it out! Varnish comes in a relatively uptodate package for my favorite distribution OpenSuSE (currently running 10.3 on 6 systems). HAproxy is available in a fresh version. nginx is theoretically available. I cannot install it though because of a package management conflict. So I downloaded the source for the newest stable version (0.6.3 as time of writing) and compiled it.

wget http://sysoev.ru/nginx/nginx-0.6.32.tar.gz
tar xzvf nginx-0.6.32.tar.gz
cd nginx-0.6.32
./configure --prefix=/opt/software/nginx-0.6.32 --user=nginx --group=nginx --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module
make && make install

I did not need to install any extra packages. Frankly spoken I do have all the packages for compilation of C/C++ installed.

cd /opt/software
ln -s /opt/software/nginx-0.6.32 nginx

I always set a symlink to the currently used package. That way it is easy to replace the package when new versions come out. I can compile and install the new version and just switch the symlink.

Next thing I had to compile was a patched PHP version. So download the sources at php.net and the patches at the PHP-FPM site.

Unpack the PHP source:

tar xjvf php-5.2.6.tar.bz2

Patch the source:

gzip -cd php-5.2.6-fpm-0.5.8.diff.gz | patch -d php-5.2.6 -p1

Configure PHP (adjust your settings accordingly):

LDFLAGS="-L/usr/lib64" ./configure --with-curl --disable-debug --enable-libxml --enable-session --with-pcre-regex --enable-xml --with-bz2 --with-zlib --enable-exif --enable-inline-optimization --enable-soap --enable-sockets --with-xmlrpc --without-pear --with-libdir=lib64 --with-mysql --with-mysqli --enable-mbstring --with-mcrypt --with-mhash --with-mime-magic --with-jpeg-dir=/usr/lib64 --with-png-dir=/usr/lib64 --with-gd --enable-gd-native-ttf --with-ttf --with-freetype-dir --enable-ftp --enable-zend-multibyte --with-openssl --enable-force-cgi-redirect --with-pcre-regex --without-sqlite --without-mm --enable-fastcgi --enable-bcmath --enable-fpm --quiet --prefix=/opt/software/php5.2.6-fpm

Compile and install:

make & make install

Adjust the PHP-FPM settings to fit your needs. You can find more info on this and related subjects in the PHP-FPM documentation.

vim /opt/software/php/etc/php-fpm.conf

Start PHP-FPM:

/opt/software/php/bin/php-cgi --fpm

Have a look in the log files:

/opt/software/php/logs/php-fpm.log

Now you can connect through your webserver to fast-cgi processes. I use nginx as webserver (see above). Advantages and disadvantes of fast-cgi vs. mod-based approaches et al have been covered elsewhere. For me this makes perfectly sense and works extremly well.

After playing around with Varnish for a while I decided I do not need HAProxy ATM. Varnish can do all the decisions I need to make based on HTTP headers. I configured Varnish’s config file (here: vcl.conf) by reading lots of examples on the net and trial and error.

If I find more time and anyone is interested I post more details on the configuration of nginx and Varnish. But for now I want to publish this post as it has been sitting here for a while already.

PS: If people say content is king they are absolutely right. But never forget in the internet speed is Kaiser!

This post originated from the Linux Showroom feed. Please check out Linux Showroom for more posts.

Apache and lighttpd replaced by nginx for PHP application