Upgrading Graylog2 from 0.9.5p2 to 0.9.6 with data migration

graylog2 logoThe Graylog2 “party-gorilla” team around Lennart Koopmann just released the final version of graylog2 0.9.6. It includes major changes and new features, such as:

  • ElasticSearch as new message store
  • new analytics shell, a terminal like browser gui for running queries
  • faster long term graphs
  • internal message queing systems to absorb and resist load spikes
  • new stream rules and filters
  • a lot of small improvements and bugfixes

The following migration guide describes the manual upgrade process on debian in detail:

Download new 0.9.6 release, for example into /opt and unpack it
https://github.com/downloads/Graylog2/graylog2-server/graylog2-server-0.9.6.tar.gz
tar xzfv graylog2-server-0.9.6.tar.gz

Download elasticsearch, most recent version from here and unpack it, for example:
wget https://github.com/downloads/elasticsearch/elasticsearch/elasticsearch-0.18.6.tar.gz
tar xzfv elasticsearch-0.18.6.tar.gz

configure basic elasticsearch values, see elasticsearch configuration for details, for example:
network.host: 192.168.164.100
path:
logs: /var/log/elasticsearch
data: /var/data/elasticsearch
cluster:
name: graylog2

Download elasticsearch-servicewrapper (tanuki-wrapper) into your elasticserach/bin installation directory and unpack it there
wget https://github.com/elasticsearch/elasticsearch-servicewrapper/zipball/master
mv master elasticsearch-servicewrapper.zip && unzip elasticsearch-servicewrapper.zip
mv elasticsearch-elasticsearch-servicewrapper-*/* . && rm -rf elasticsearch-elasticsearch-servicewrapper-*

Start elasticsearch instance bia servicewrapper in /bin/service
./elasticsearch start
Starting ElasticSearch...
Waiting for ElasticSearch.......
running: PID:14816

Check if your elasticsearch instance started successfully. The logfile (defaut here in /var/log/elasticsearch/graylog2.log) should show something like this:
[2011-12-23 22:21:03,711][INFO ][node ] [Celestial Madonna] {0.18.6}[14818]: initializing ...
[2011-12-23 22:21:03,716][INFO ][plugins ] [Celestial Madonna] loaded [], sites []
[2011-12-23 22:21:05,299][INFO ][node ] [Celestial Madonna] {0.18.6}[14818]: initialized
[2011-12-23 22:21:05,299][INFO ][node ] [Celestial Madonna] {0.18.6}[14818]: starting ...
[2011-12-23 22:21:05,352][INFO ][transport ] [Celestial Madonna] bound_address {inet[/192.168.164.100:9300]}, publish_address {inet[/192.168.164.100:9300]}
[2011-12-23 22:21:08,385][INFO ][cluster.service ] [Celestial Madonna] new_master [Celestial Madonna][WiNh0iYwQyeipER3PuXZSg][inet[/192.168.164.100:9300]], reason: zen-disco-join (elected_as_master)
[2011-12-23 22:21:08,408][INFO ][discovery ] [Celestial Madonna] graylog2/WiNh0iYwQyeipER3PuXZSg
[2011-12-23 22:21:08,415][INFO ][http ] [Celestial Madonna] bound_address {inet[/192.168.164.100:9200]}, publish_address {inet[/192.168.164.100:9200]}
[2011-12-23 22:21:08,416][INFO ][node ] [Celestial Madonna] {0.18.6}[14818]: started
[2011-12-23 22:21:08,419][INFO ][gateway ] [Celestial Madonna] recovered [0] indices into cluster_state

Get the MongoDB to ElasticSearch migrator script from joschi
git clone https://github.com/joschi/graylog2-mongo-es-migrator.git

you need at least to adapt to config/migrator.yml with your mongodb username, password and host, usage:
After you've downloaded the script you should edit the configuration file in config/migrator.yml. If the ElasticSearch and MongoDB servers are running on the same system (on localhost) and MongoDB doesn't need authentication you can keep the file as is.

Get required dependencies with Bundler:
bundle install

prepare a new graylog2.conf in /tmp/graylog2.conf with new settings (or just copy the new config and adapt your settings). The new default configuration settings are:
elasticsearch_url = http://localhost:9200/
elasticsearch_index_name = graylog2
force_syslog_rdns = false
mq_batch_size = 4000
mq_poll_freq = 1
mq_max_size = 0

be brave and do a “hole-in-one” migration from the migrator directory (the following line works depending from where your graylog2 servers resides):
ps aux | grep graylog2-server.jar | awk {'print $2'} | xargs kill; ruby migrator.rb;cp /tmp/graylog2.conf /etc/graylog2.conf/; cd ../graylog2-server-0.9.6/bin/;./graylog2ctl start

Get the new web interface from github
git clone https://github.com/Graylog2/graylog2-web-interface.git

get required dependencies for the graylog2 web-interface
cd graylog2-web-interface; bundle install

Configure new web-interface (copy old configs, adapt new parameters, create new indexer.yml file with correct elasticsearch settings), be sure to check
indexer.yml
mongoid.yml
general.yml
email.yml

Start the bundled server or adapt your apache/passenger settings

Login to your web-interface, check if latest events are dropping in.

Write a “thank you party-gorilla” tweet to the @graylog2 twitter account

Related Posts:

OpenX Performance optimization with Amazon S3 and CloudFront as CDN

On one of my current projects called diginights.com we are heavily using the popular and free Ad server solution OpenX for banner delivery. To optimize its performance and spread the http connections over multiple domains to boost the page speed we decided to outsource the ad images to a Content Delivery Network (CDN). We chose the Amazon Web Services for a first test due to the easy installation and configuration of their cloud services.
The two services to enable in your Amazon Web Management Console are Amazon S3 (storage solution) and CloudFront (CDN distribution). We sync the images between our root servers and Amazon S3 with the help of the fuse integrated and free filesystem s3fs (FuseOverAmazon).

First of all you need to get an Amazon S3 account on http://aws.amazon.com/s3/ and set up a new S3 Bucket (beware that every bucket name needs to be unique) in a region that fits your needs, create a CloudFront Distribution for the Bucket and wait until its enabled. The images below should be enough to help you with setting up AWS:

Please note the *.cloudfront.net. You’ll need it later for OpenX configuration. You could also set up a CNAME in your DNS system, configure this CNAME in the CloudFront Console and deliver the ad images via this CNAME from OpenX.

Installation of s3fs on our Debian Linux servers is fairly easy:

  1. Grab the recent version of s3fs from its download page and extract it somewhere (eg. /usr/src)
  2. Install installation prequisites via

    apt-get install build-essential libfuse-dev fuse-utils libcurl4-openssl-dev libxml2-dev mime-support

  3. Compile and install s3fs
    • cd s3fs-1.16/
    • ./configure –prefix=/usr
    • make
    • make install (as root)

  4. Put your security credentials either in /root/.passwd-s3fs or the system-wide file /etc/passwd-s3fs. Please take care of the file permissions. The syntax in the file is simple accessKeyId:secretAccessKey ( or bucketName:accessKeyId:secretAccessKey for multiple buckets)
  5. Enable fuse module, if it isn’t already in use:

    modprobe fuse

  6. You should then be able to mount your bucket to your local filesystem:

    s3fs bucketName mountpoint

  7. Put a similar entry in the fstab of your servers:

    s3fs#bucketName /space/amazons3 fuse default_acl=public-read,allow_other 0 0

    public-read is necessary to make sure that copied files are available online for every user.

  8. That’s it for the s3fs part. Now you have to reconfigure your OpenX Installation
  9. Change the Local Directory under Global Settings -> Banner Storage Settings to the directory where your S3 mountpoint is located.
  10. Change the Image Store URL for HTTP & HTTPS under Global Settings -> Banner Delivery Settings to your *.cloudfront.net Domain (Or your own CNAME URL).
  11. Save the settings, sit back and relax! But don’t forget to check your AWS account balance ;)

Related Posts:

Probleme bei Dovecot Migration mit Sieve Plugin

Nach Installation der neusten Dovecot Version (1.2.4-2 via debian-testing) kommt es bei Verwendung des alten CMUSieve Plugins zu folgendem Problem im Mail.log:

Fatal: Plugin cmusieve not found from directory /usr/lib/dovecot/modules/lda

Nachrichten werden dann nicht mehr zugestellt.

Warum tuts auf einmal nicht mehr? CMUSieve ist eigentlich deprecated und man möchte das für Dovecot 1.2 geschriebene Dovecot Sieve plugin verwende.
Dazu muss man folgenden Eintrag ändern.

protocol lda {
mail_plugin_dir = /usr/lib/dovecot/modules/lda
mail_plugins = sieve
sieve_extensions = +imapflags
log_path = /var/log/dovecot/deliver.log
info_log_path = /var/log/dovecot/deliver-info.log

In der “mail_plugins” Zeile ersetzt man also einfach “cmusieve” durch “sieve”.
Folgende Änderungen muss man noch beachten:

# The imapflags extension is now called imap4flags. The CMUSieve implementation is based on an old draft specification that is not completely compatible. Particularly, the mark and unmark commands were removed from the new specification. For backwards compatibility, support for the old imapflags extension can be enabled using the sieve_extensions setting (as explained above). This is disabled by default.

# The notify extension is now called enotify. Sieve scripts need to be adjusted to incorporate this change: unlike imapflags, no backwards compatibility is provided currently.

Hier muss man also noch ein wenig aufpassen und ggf. seine Sieve Tools, wie beispielsweise den pysieved auf die aktuellste Version aktualisieren.

Related Posts:

Seriennummer von AIX und HP Maschinen/Linux remote auslesen

Immer wieder hilfreich ist, wenn man Seriennummern von AIX Maschinen und HP Servern, die unter Linux lauffen, remote auslesen kann.
Dieser Post dient als kleine Erinnerung:

Auslesen unter AIX:

lsconf | grep -i serial

Auslesen unter SLES10 / HP Server:

dmidecode | grep -i serial

Related Posts:

Google gewährt Einblick in Container Rechenzentrum

Auf dem Google Data Center Efficiency Summit in Mountain View hat Google erstmals offiziell bestätigt, dass ihr RZ Design auf RZ Containern basiert. Ein Google Mitarbeiter (Jimmy Clidaras) erklärte mit Hilfe einer Präsentation die Besonderheiten und Möglichkeiten dieser seit 2005 im Einsatz befindlichen Architektur. Jeder der bis zu 12 Meter langen Container enthält dabei bis zu 1160 Server und verbraucht bis zu 250KW Strom. Der gezeigte Container Hangar enthält 45 Container, zum Teil sogar auf einem 2. Stock!
Über die Präsentation gibt es ein über 5 minütiges Video auf youtube, weitere Videos der Konferenz sollen noch folgen:

Auch schon offiziell ist die Bauweise der Google Webserver, welche mich doch stark an die RootServer bei 1&1 erinnern:

Bei Datacenterknowledge.com gibts einige interessante Berichte über IT Architektur bei google:
Google’s Custom Webserver revealed
Google unveils container Data Center
Efficient UPS Aids Google’s Extreme PUE
Inside A Google Data Center

(via datacenterknowledge.com)

Related Posts:

RAID Monitoring mit Nagios

Vor kurzem schrieb ich über einen Festplatten Ausfall in einem Software Raid.
Dieser Ausfall wurde einem Nagios Überwachungssystem gemeldet, mit welchem wir unsere Server überwachen. Als RAID Systeme kommen “normale” Linux Software Raids mit md devices und ein Server mit einem 3ware Hardware Raid (3ware Inc 8000-series) zum Einsatz.

Für das 3Ware Raid verwenden wir das check_3ware_raid von nagiosexchange.org. Dafür muss wie im Artikel beschrieben noch sudoers um “nagios ALL=(ALL) NOPASSWD: /path/to/check_3ware_raid” erweitert werden. Der Check selbst wird dann beispielsweise im nrpe Client über ein Wrapper Skript ausgeführt, welches ein “sudo /path/to/check_3ware_raid” ausführt.
Zur Ausführung benötigt man noch das 3ware Command Line Interface (CLI). Für Debian bekommt man das einfach über debian-unoffical mirror, der noch zu den apt-Sourcen hinzugefügt werden muss:

# For getting 3dm2-package for 3ware
deb http://ftp.debian-unofficial.org/debian sid main contrib non-free restricted

Nach einem

apt-get update && apt-get install 3ware-3dm2-binary 3ware-cli-binary

befinden sich die benötigten Binaries auf eurem Server und die Funktion lässt sich mit dem Aufruf von

tw_cli /c0 show

Unit UnitType Status %Cmpl Stripe Size(GB) Cache AVerify IgnECC
——————————————————————————
u0 RAID-1 OK – – 698.637 ON – -

Port Status Unit Size Blocks Serial
—————————————————————
p0 OK u0 698.63 GB 1465149168 5QD2DXQ8
p1 OK u0 698.63 GB 1465149168 5QD0XX6A

testen.

Software Raids werden mit dem einfachen check_md_raid überwacht. Dazu wird der Check einfach als command oder im nrpe Client hinzugefügt und ausgeführt. Allerdings schreit er schon mit Critical, wenn nur ein Device Critical ist, und dies kann man auch nicht konfigurieren oder auf bestimmte md devices eingrenzen.

Related Posts:

Neues phpMyAdmin erschienen

Seit 22. August ist das neue phpMyAdmin in der Version 2.11.0 nun endlich stable.

Schön an dieser Version ist, das es nicht wie sonst immer ein paar Sicherheitsfixes gibt, sondern endlich triggers, procedures und functions unterstützt werden. Diese können nun angezeigt und editiert werden. Sehr Schön ;)

Näheres dazu sowie den Download gibts auf der official Site.

Related Posts: