Schlomo Schapiro

Update (2019):  https://github.com/schlomo/rpi-image-creator  is the new home of the code. Recently we got a whole bunch of Raspberry Pi systems at work - the cheapest platform for building Dashboards . Everybody loves those little cute boxes - but nobody wants to deal with the setup and maintenance. The kiosk-browser package is of course also the base of our Pi-based setup. But how does it get onto the Pi? The solution is a Bash script: rpi-image-creator  available on the ImmobilienScout24 GitHub project . It automates the setup of a Pi with Raspbian by downloading a Raspbian image, customizing it a bit and writing it to a SD card. The reason to write my own script where the following features: It creates the file systems on the SD card instead of dumping a raw image onto the SD card. That way the partitions are all aligned properly and have the right size from the beginning. No later resizing needed It removes all the stuff that Raspbian runs at the first boot so that the

While writing some test scripts that use rsh (see below about why) to run commands on a remote test server I noticed that rsh and ssh have a significant difference: ssh reports the remote exit code and rsh does not .  As a result all my tests did not test anything, the error condition was never triggered: My solution is this rsh wrapper: The reason for using rsh instead of ssh is very simple: In a fully automated environment it provides the same level of security as ssh without the added trouble of maintaining it: I need to make sure that ssh continues to work after all the SSH host keys change (e.g. after I reinstall the target). Also, to allow unattended operation I must deploy the SSH private keys so that in the end others could also extract them and use them. In the end I would be using IP/hostname restrictions on the SSH server side to restrict the use of the private key. With rsh I don't need to worry about deploying or maintaining keys and just configure th

Yesterday I was at the Berlin DevOps meetup and we had a very nice fishbowl about Test Driven Infrastructure (TDI). I used my Lightning Talk from the PyCon in Köln as an introduction to the topic, but quickly realized that the term does not fully explain itself. Test Driven Development  in itself is not a new thing, maybe it is not yet common to apply it to platform operations. As an old Ops guy I had a lot to learn when I started to work at ImmobilienScout24 , which is a real software development company. The bottom line is really simple: Untested = Broken My idea of TDI is to apply most of the basic ideas of TDD also to the development process  of the software that runs our platform. Again, the same thing as the developers do with their code already for a long time. Let's just say that we start to test all  code that goes on a server, no matter who wrote it or what it actually does. Some specific examples that we did in the last month: A service that mounts SAN