Crypto Currency Mining

Many people are hearing about the boom in Crypto Currencies lately and are joining those that have been mining for a long time. Naturally they have a lot of questions since the concepts of mining are not really put down at a central place easily accessible (or even understandable) to newcomers.

Since I am running my own little pool network (The Pool Collective) based on my own software project called MPOS I am also seeing new people joining every day. Instead of having to answer the same questions again and again I decided to write a small introduction to mining! This will only cover the basics of mining, not the concepts behind crypto coins.

Getting a wallet

Before you start mining make sure you have a wallet installed for the coin you wish to mine. All coins generated in a pool must be transferred to your local wallet eventually (to keep your coins save). So better do this now!

Each coin will offer various versions for different operations systems on their homepage. After downloading and installing it will start to download the Blockchain. This may take a while depending on the coin.

You will find a Receive tab in your wallet. If you click that, you will get your coin address for this coin. You will be able to receive coins at that address.

Joining a pool

Newcomers will likely join a pool they find in some sort of forum post. The basic procedure is always the same

  • find a mining pool of your liking
  • create a new account with a valid mail address
  • add your valid wallet address to your account
  • configure your auto payout threshold
  • create a worker

Create miner

Most pools offer a Getting Started guide that explains the exact steps to setup a miner. Including software downloads, miner settings, hosts and ports. You can pretty much use their information to get your miner started.

Shares, pool hashrate, blocks, payouts

New miners are often wondering

  • why do I have shares but no transactions
  • why are my coins unconfirmed
  • I have shares accepted but no block
  • I don’t see my hashrate increase on the pool

Here a quick overview what these terms mean.


Finding blocks is not an easy task. Since it would take a really long time on some coins, finding a block is broken down into shares. Depending on the server side setting, each share can be a certain difficulty. The more difficult each share is to find by miners, the fewer total shares are required to eventually find a block.

On the server side, each share is checked against the coin daemon (a server side wallet with more features) if it is indeed a valid block solution. Every share computed has the potential to be a block solution. I will not go into details why this is, but rest assured that share estimates for blocks can sometimes be exceeded. In the long run though, shorter round with less shares than required will make up for those taking very long.

Keep in mind: shares are not blocks! Shares are part of a block and will count towards the block payout!

At times, you will see shares being rejected by the pool. This can happen if you try to send an outdated share right after a block was found. Stratum, a protocol used by a miner to request work from a server, is used for share submission and getting new work. It is very solid when it comes to avoiding rejects but they can still happen once in a while.

If you are seeing reject all the time, then something isn’t working right on your end. You may also notice that your hashrate on the pool website is not increasing while your invalid share count keeps climbing up. In that case turn off your miner and check your settings!

Pool Hashrate

Often people running miners for the first time will notice a discrepancy between their hashrate displayed in their miner and what the pool reports. Do not be alarmed unless

  • your miner is not showing shares being accepted (marked as rejected)
  • your miner is showing a lot of hardware errors

Unless one of above are the case, everything is normal! The pool can not see your clients hashrate so it deducts it from the shares you have submitted. Since each share, just like blocks, have a certain variance to them (sometimes you solve one fast, sometimes you solve it slow) a pool will show a very unstable hashrate. This is not a reason to complain to your trusted pool operator! Their pools have no influence on your luck/bad luck and only display what their pool can see based on your shares submitted.


Coins generated by a block will not be available to you right away. They will take some time to be confirmed by the entire network before you are allowed to transfer them out of the pool. Usually coins have a confirmation set to 120. What that actually means: the network (not the pool) has to discover 120 additional blocks on top of the one found by the pool to confirm it.


Sometimes you may notice that a block found by a pool became orphan. I won’t go into details what this means (you can probably google it) in detail but for you, it means your paid out coins will become invalid (unless you run pay per share, see below). This doesn’t happen often though, at least for the bigger coins. As of this writing, not a single block in my chains was marked as orphaned.


Now the most interesting part: When will I see the first coins flowing into my pool account?

This actually depends on the pools payout system. MPOS support three different systems:

  • proportional (Prop)
  • pay per last N shares (PPLNS)
  • pay per share (PPS)

Each system had its pros and cons, mostly related to risk and reward, but in short:

Proportional and PPLNS are round based payouts, hence you will be paid your coins as soon as a round ends with finding a new block in the pool. They will be in unconfirmed state until the block has been confirmed on the network.

PPS is a share based payout, each share will have a certain value which will be paid out right away. You don’t have to wait for a round to end to get your coins. Orphans also won’t matter, the risk is fully taken by pool operators. Your paid out shares are confirmed right away, you don’t wait for a block to be confirmed.

There are not too many PPS pools out there. The system is very risky for a pool operator. Even with taking a pool fee, a long round or orphan block can quickly negate any income made in the past. In a worst case scenario, a pool operator would have to boost the pool with his own coins to recover from a bad round!

Proportional and PPLNS are commonly used by smaller pools. It is a fair system with no risk to the pool operator. Orphans will be passed down to the users, causing them to lose the coins generated by orphan blocks. As mentioned, depending on the coin, this can happen often or almost never.

For details on each of these systems, feel free to do a quick Google search.


As you see, there are a few aspects involved when joining a pool. These steps will usually be very similar, and most terms will apply to all pools. I hope this little guide will clear a few things up! And happy mining to you all.

Book Review: Instant Chef Starter

Instant Chef Starter

So I have finally finished reading the Instant Chef Starter book that was made available to me by Packt Publishing a while ago. It was not a long book by all means but work and real life kept interfering with my time available to actually read the book.

The book is split into various parts:

  • What is Chef?
  • Installation
  • Quick Start
  • Top Features
  • Other Documentation available

If you never worked with Chef before this book will help you to get up to speed as fast as possible.  If hear the words cookbook, recipe, knife and all you think about a good hearty lunch then this book will give those words a whole new meaning!

What is Chef? will cover the basic concepts behind Chef and explain you the relations between cookbooks, recipes and run lists. After reading this first part you should have a pretty good idea what Chef is and what it can do for you.

Installation covers (as you might have guessed) the installation of a Chef Server. This is where I noticed that the book was written a while ago. It uses the common installation methods for various distributions including Ruby Gem. Now with Chef 11 being available, the Omnibus Package is much simpler and way more fool proof than the described installation methods in this chapter. Nevertheless it pretty much summed up the proper way to do it in Chef 10.x which I also used to get a running Chef Server on CentOS 6.

Quick Start will help you with your newly installed Chef server and all the steps involved to add your first node. Once you know how bootstrapping works it will introduce you to cookbooks and how to obtain and upload them to your Chef server. Both the command line and WebUI ways are described in this chapter.

Top Features dives deeper into cookbooks, their contents and various features (like attributes, templates, data bags and resources). It gives you a great idea how to write your own cookbook in less than 30 minutes.

As expected this book did not uncover a whole new set of features I didn’t know about. Obviously the target audience are people that never worked with Chef before and would prefer a book over searching the internet for all the details needed to see the big picture of what Chef is capable of.

So if you are new to Chef then I highly recommend reading this book. It is not very long (70 pages as an eBook), described Chef in good detail and comes with a great examples that you can use a s a base for your own cookbooks in the future.

WIP: Book Review – Instant Chef Starter

Apparently people are reading my blog!

I have been asked to do a short book review:

Instant Chef Starter

Good thing I am really into this Chef stuff so it might be an interesting read. I am glad I had some people to talk to when I started to work with Chef. This book might help others to get started and learn Chef without the hassle to find all the information needed on the Internet.

I will read through it on the weekend (it’s only about 70 pages with a PDF and eBook version available) and will post my opinion sometime after.

PHP Projects moved to GitHub

After some time I finally managed to move my projects over to GitHub. I have been using my own SVN Server in the past but have found GitHub to be much more useful. The project pages have been updated with links to their repositories:

Since I am not actively maintaining these projects anymore, putting them on GitHub will allow others to contribute :-).

Chef Server 11 CentOS 6.3

I have been working with Chef Server 11 for a while now and figured it’s time to share my setup experience with others.


This guide is based on CentOS 6.3 64 bit. Ubuntu Server is also supported but always make sure to grab the 64 bit version for Chef Server. Chef Client supports various distributions both 32 and 64 bit.

Installing CentOS 6.3

When installing CentOS 6.3 make sure to use the minimal installation ISO. It contains all the stuff you need without adding too much overhead to your final installation. In fact there are some packages you can safely remove in the end to further reduce the system size and memory usage. You can find a list of mirrors for this at the CentOS Homepage.

One thing to keep in mind when using VirtualBox: Ensure Enable IO APIC is marked in the System tab. Otherwise the boot procedure of the installation ISO will hang at some point and not proceed. Please give the machine enough RAM! Chef Server is very easy on RAM but some processes are rather memory intensive so 1 GB should be the minimum.

Enable IO APIC in the System Tab to avoid boot issues.

Enable IO APIC in the System Tab to avoid boot issues.

Since we want to be able to connect to the machine as easy as possible via SSH and HTTPS I suggest changing your Network adapter frohm NAT to Bridged Adapter. This will allow your virtual machine to grab an IP address from your regular network instead of running on a NAT interface.

There is nothing special about the installation process. You can keep all the defaults and keep pressing OK until your system asks you to reboot. Once rebooted you can login via console for the first time and setup your network as required.

Network Setup

Usually I would say ‘each to their own’ but I would like to give a little heads up: By default network adapters in CentOS 6 are disabled during boot time. You can enable them by editing /etc/sysconfig/network-scripts/ifcfg-eth0 and setting ONBOOT to yes. Then restart your network to enable these settings: /etc/init.d/network restart

Hostname and FQDN

Chef Server needs a proper FQDN when running hostname -f which usually is not the case once you finish a regular installation. To ensure this works we will change the machines hostname and add it to the /etc/hosts file:

sed -i -e "s/HOSTNAME.*/HOSTNAME=chef-server.local/" /etc/sysconfig/network
echo "$( ifconfig eth0 | awk '/inet addr:/{ sub(/addr:/, ""); print $2}' ) chef-server.local" >> /etc/hosts

Post-installation Steps

Here are some additional steps I did to ensure I have a painless installation later on.

Optional Cleanup

Even when using the minimal installation ISO there are a few packages you can remove in a VirtualBox setup.

yum -y remove audit lldpad portmap

System Update

Also we should ensure the system is up-to-date before we proceed to install Chef Server.

yum -y update

Note: During my upgrade the kernel was updated so I had to reboot to make sure VirtualBox will find the proper development files later in the process.

VirtualBox Guest Additions

Now with our updated system we need to install a few tools that are required by the VirtualBox Guest Additions:

yum -y install gcc cpp make autoconf kernel-devel

Once installed, mount the Guest Additions ISO (Shortcut: Host+D) and install them:

mount /dev/cdrom /mnt
cd /mnt

Depending on your guest system settings and host system hardware this may take a while. Once completed you can restart the machine again to ensure the modules are loaded. Since we are done compiling you can also remove the previously installed software again to save some space:

yum -y remove gcc cpp make autoconf kernel-devel glibc-devel perl* mfpr ppl libgomp cloog-ppl

Now we are ready to install Chef Server!

Chef Server Installation

With their Omnibus Installer it is now very easy to setup a Chef Server on a supported distribution.

Download Chef Server

Please head over to their download page and grab Chef Server 11 for Enterprise Linux 6 x86_64. Latest version as of this writing was Chef Server 11.0.6 which you can grab using curl:

curl -o /root/chef-server-11.0.6-1.el6.x86_64.rpm

Install Chef Server 11

Congratulations! You succesfully downloaded Chef Server 11 and are now ready to kick off the installation. This is rather simple thanks to their RPM package:

yum localinstall chef-server-11.0.6-1.el6.x86_64.rpm

That’s it. After a few seconds Chef Server should be installed and tell you what the next step is.

Chef Server 11 Configuration

This is just as easy as the installation itself. Chef Server 11 comes with a new script, chef-server-ctl, that allows you to do a couple of tasks involving all components of it. As mentioned after a successful installation of the RPM package you now run:

chef-server-ctl reconfigure

This will setup your Chef Server and takes a minute or two.

Note: I was having issues uploading cookbooks after running the auto-configuration script. Apparently Bookshelf will pass on the upload URL to the clients which is using the FQDN of the host. In order to get around this, I replaced a line in the Chef Solo attributes file to use the IP instead, then re-ran the auto-configure script:

sed -i -e "s/node\['fqdn'\]/node['ipaddress']/g" /opt/chef-server/embedded/cookbooks/chef-server/attributes/default.rb
chef-server-ctl reconfigure

User Setup

You can read an older post of mine that describes the process pretty well. The original post covers the Ubuntu way to run a Chef Server but the user setup is essentially the same.


As you can see it is rather easy to run Chef Server in CentOS or RedHat Enterprise Linux. Most of the installation steps outlined in my earlier post are the same but I was working with VirtualBox a lot lately and sharing my experience wouldn’t hurt. If you liked this guide or found some issues with it please feel free to leave a comment in the comment section below.

Chef Solo Qmailtoaster

I have been using Qmailtoaster for a while now and also wrote a chef-qmailtoaster cookbook to make the installation process easier and reproducible. Since I knew that not everyone is running their installation on a Chef Server or Hosted Chef I figured it’s time to look at Chef-Solo. This would allow others to run my cookbook on a standlone server without any account at Hosted Chef or a Chef Server.


If you haven’t heard of Chef yet you should go check it out. There is a nice fast start guide that can help you get setup with Hosted Chef in a matter of minutes.

Here a quote from their website:

“Chef is an open-source automation platform built to address the hardest infrastructure challenges on the planet. Chef gives you the power and flexibility you need to move faster in a complex world – from rapid provisioning and deployment of servers to the automated delivery of applications and services—at any scale.”

I am glad to say this is all true. So far I have been able to overcome all the issues we had and deploying environments has never been so easy.


You will need to pass the following requirements in order to use my Chef Solo way of installing qmailtoaster:

  • only CentOS 6.3+ is currently support
  • ruby, ruby-devel and rubygems needs to be installed
  • Running chef-client installation installed via gem install chef
  • Vanilla Installation ONLY

Please note the last bullet point: I have tested and run this script many times but only on fresh systems! I have no means of testing this on a pre-installed machine that is already running all the tools that are required for Qmailtoaster! So please use this at your own risk!

Once these conditions are met you should have no issues to install Qmailtoaster.

Getting started

As discussed above please install the required packages:

yum install ruby ruby-devel rubygems
gem install chef

That’s all! Now we can go ahead and get started on Chef Solo.

Chef Solo

In order to install qmailtoaster we will need three files:

  • node.json
  • solo.rb
  • cookbook archive


This file defines our server configuration. We only need a few variables to be set in order to get started:

  "run_list": [
  "build_essential": { "compiletime": true },
  "mysql": { "server_root_password": "geacVafCukdiHayhett6KecHo", "server_repl_password": "juAkHajmorjAinwyerkyanIt7", "server_debian_password": "IbPiobijinPavJagQuiofwuv5" }

As you can see we will define some passwords that will be used during the installation process. These passwords will set your MySQL password and other mandatory passwords used by the MySQL Cookbook. Please be aware to store these or you will not be able to access your database!

Another password that will be auto-generated during installation is the vpopmail user accessing the database. This should be no issue since you can always use the root account to access your data directly. If you are desperate though you can find the password in /home/vpopmail/etc/vpopmail.mysql.


This file controls some paths used by Chef Solo. You can also use this file to point towards remote locations for the node.json or the cookbook archive. Most of the time this should work for you though:

file_cache_path "/var/chef-solo"
cookbook_path "/var/chef-solo/cookbooks"
json_attribs "node.json"
recipe_url ""

As you can see I am already pointing this run towards my own chef-solo archive. You can use your own location based on my files if you like.


Now that we have all files in place, lets try to run Chef-Solo!

chef-solo -c solo.rb

Now sit back and relax while it runs and installs your Qmailtoaster! This will take a while due to the rpmbuild process included in the recipes. If you run with a bare solo.rb you can expand the command line to include both the node.js and cookbook archive on command line:

chef-solo -c solo.rb -j node.json -r chef-solo.tar.gz

Please take a look at the official documentation for more details on chef-solo and its options!


Chef-solo offers a great way to not only script the installation process but also add some last minute changes to the final setup (like a non-standard vpopmail database password). I really love how easy it was to convert existing scripts over to  a Chef cookbook while also adding more flexibility to it. I will make sure to use Chef more often now that I understand how Chef Solo works and how easy it is to deploy cookbooks. If you have any questions or suggestions feel free to contact me.

Chef Server 11 Released

Hey everyone,

So on February 4th Opscode released their latest version of Opscode Chef: 11.0.0!  You can read their entire press release here.

Obviously I had to get over there and check it out right away. So I went to their official download page and Chose Chef Server. Apparently they only support pre-packaged versions for Ubuntu and RedHat Enterprise but that’s not an issue. In my first test I wanted to run Chef Server inside a VirtualBox guest. So I went over to the Ubuntu Server Download Page and grabbed Ubuntu 12.04 LTS.


I created a new VirtualBox called Chef Server 11:

  • Linux Ubuntu 64 Bit
  • 512 MB RAM, 1 CPU
  • Dynamic Disk, 40 GB (just in case)
  • APIC Enabled
  • no USB, no Audio

When booting up the first time I selected the Ubuntu Server ISO as boot media and started the installation.

Ubuntu Installation

As you might have guessed the installation of Ubuntu Server 12.04 LTS was rather easy. I pretty much used all the default settings during the installation process and created a new user called chef. That was all required to prepare the system for Chef Server 11.

Chef Server Installation

Now came the hard part. From previous installation I knew this is some tedious work. Either run the Manual installation, Omnibus Installer or Chef-Solo way but I never succeeded with any of those out of the box. So I was ready for a long installation with lots of issues.

Turns out: They greatly improved the installation process! When I started I created a document to ensure I can repeat the process anytime. Since I am lazy I will put these notes here:

  • Download Location:
  • wget
  • sudo dpkg -i chef-server_11.0.4-1.ubuntu.12.04_amd64.deb
  • sudo chef-server-ctl reconfigure

And that was that. It takes quite a while to download, install and configure but these steps were enough to have a fully functions Chef Server installed on Ubuntu.

Amazing, isn’t it? Once completed you can run some commands to verify your installation:

  • /opt/chef-server/bin/chef-server-ctl service-list
  • /opt/chef-server/bin/chef-server-ctl status
  • /opt/chef-server/bin/chef-server-ctl test
Status Check

Status Check with chef-server-ctl

Client Configuration

Since I have been using Knife and command line calls to configure all my previous chef-server clients I ran into an issue: No validation.pem or webui.pem! What now? Luckily I have been using Hosted Chef for a while now. Getting my client up and running meant to go to the WebUI (https://<your-chef-server>/) and logging in with the default credentials displayed on the right side:Default Login

These credentials worked fine and I was prompted to change the admin password. Once done, I created a new User for my workstation, copied the Private Key as usual and dumped it into my knife configuration. To get the validation.pem I had to go to Clients –> chef-validator –> Edit and create a new private key. I copied the resulting output into the validation.pem. Voila!

Some major change that came with Chef Server 11 is the API URL. Instead of running on port 4000 as previous Chef Server everything related to Chef is now managed by Nginx on SSL. So in order to use Knife I had to change the Chef Server Location to https://<your-chef-server> instead of http://<chef-server>:4000. A good change, now API calls are finally encrypted too.


One thing I noticed right away: I am not able to upload any cookbooks with my Chef-Client 10.16.2. Apparently it can’t upload to the new HTTPS location. After creating my client configuration on the chef-server using Chef-Client 11.0.0 I had no more issues uploading them.

Also, as of writing this post, chefspec does not support Chef 11.0 checks yet. This will probably be fixed in the future.

Installing chef-client via gem install is not possible yet. This actually made my rake based tests fail since it tried to install the latest gem of chef. Pinning my Chef client to verion <11.0.0 fixed that issue (Thanks to Mathias who pointed that out to me).


Installing the latest Community version of Chef was incredibly easy. I am happy that Ospcode decided to make the installation more straight forward since many companies will try out the free version to see its potential. I am sure some people might have been scared off by the incredibly difficult installation process before. I have yet to test Chef Server in a large environment to confirm that performance is indeed better than before. As soon as my company allows me to spawn 2000 Nodes in Amazon I shall try it out!

Icinga Performance in Vagrant

Hey again,

As mentioned in my previous post I went ahead and added some live systems into my Vagrant Icinga setup which was provisioned using chef-solo. For details on how to use Vagrant please go to their site and read their getting started guide.

I am using a Vagrant Box running Debian Squeeze 64 with 2048 MB RAM and 2 CPUs.  The host system is my IBM ThinkPad T510, 2.67 GHz with Hyper Threading enabled and 8 GB RAM. The underlying disk is a Samsung 256 GB SSD 830 Series (IMHO a must have when running Vagrant extensively). As you can see, not an overly beefy machine.

To start with, I used a single datacenter and added some simple JSON files to my data bags which are used by Chef-solo to search in. The Icinga Cookbook used these to propagate my Check_MK configurations for hosts, tags and hostgroups. Upon configuration changes it updates the Icinga files by running cmk -II; cmk -O.

So now we have them pop up in our Check_MK Dashboard, a total of 536 hosts are being checked with a total of 13342 services. Our only active checks right now are Check_MK and Check_MK Inventory, all other results are passive check results.

Now I decided to trigger an active check for all my pending Check_MK Service Checks. Surely enough system load went way up (topped at about 45) but after a while the system calmed down again and is now running stable:

CPU Load during initial active check and later during normal operation.

CPU Utilization during initial active check phase and normal operations.

Load was mainly caused by the large amount of processes running to do my initial active checks. Interestingly disk I/O was not a huge issue at all, previous installation on regular hard disks always ended up in becoming unresponsive due to high IO Wait. Please keep in mind that Check_MK/Icinga is using all performance data available to write RRD Files. Apparently this is really not an issue as soon as you are running a decent SSD.

Now with the system running a regular check cycle, load has normalized and all initial RRD files written, I can safely say: This box has no problems at all:

System Summary in top

System overview in atop

Hopefully this is useful to you as it is to me when evaluating your future monitoring solution!

Icinga Cookbook

I might have mentioned it on Twitter a while ago: Bigpoint is using Opscode Chef to deploy our systems and one cookbook I have been working on is Icinga. We use Icinga in combination with Check_MK to automatically provision our distributed monitoring setup throughout our datacenters. After doing some code cleanup and extensive testing (according to our requirements) it has been approved for a public release. Please check our Icinga Github respository for the latest version. Next is the development branch, Master is the stable branch pushed to by our build process after passing all tests.

I have also split off two other cookbooks used in Icinga: pno4nagios and rrdcached. They should run standalone with some adjustments to the appropriate Nagios/Icinga configurations but are really designed to work with the Icinga cookbook.

If you would like to try it out, Vagrant is fully supported (when using the Chef Solo search library). With some effort you can even monitor a live setup from your Vagrant instance provisioned via Chef Solo.

If you are having any issues or would like to improve the cookbook feel free to help us out with Pull requests!


Roundcube Cookbook

As I mentioned in my previous post I have started to work on a qmailtoaster cookbook for Chef. I have now a properly working version for CentOS 6 which installs the entire backend required to run a mailserver. I have also split the web frontend and libraries up into a separate recipe since I never really used it – maybe some others need it so you can still install it.

After getting a working version of qmailtoaster I decided to take a look at my Webmailer in use: Roundcube. I won’t go into details why I use it but I feel it is the best Webmail application out there. Hence it had to make it available through a cookbook to remove the hassle of installing it myself.

Luckily the installation is pretty straight forward. I used a fresh Roundcube install to figure out any dependencies it may require and satisfied those. Once done I used a generated configuration as my base template to build my cookbook. After replacing some obvious configuration variables with node attributes (database, IMAP and SMTP host) the cookbook already worked! Added an attribute to change the installation destination and I was done.

I have tested this cookbook both with a local Qmail installation and my remote live server. Even though running in Vagrant both had excellent response times and accessing my real mail was amazingly fast.

If you wish to participate or just want to try it out yourself you can find my repository on Github.