Search Results: "Stig Sandbeck Mathisen"

23 February 2017

Stig Sandbeck Mathisen: Change all the passwords (again)

Looks like it is time to change all the passwords again. There s a tiny little flaw in a CDN used everywhere, it seems. Here s a quick hack for users of the pass password manager to qickly find the domains affected. It is not perfect, but it is fast. :)
# Stig Sandbeck Mathisen <>
# Checks the content of "pass" against the list of sites using cloudflare.
# Expect false positives, and possibly false negatives.
# TODO: remove the left part of each hostname from pass, to check domains.
set -euo pipefail
tempdir=$(mktemp -d)
trap 'echo >&2 "removing $ tempdir " ; rm -rf "$tempdir"' EXIT
git clone "$tempdir"
grep -F -x -f \
  <(pass git ls-files    sed -e s,/,\ ,g -e s/.gpg//   xargs -n 1   sort -u) \
  "$ tempdir /sorted_unique_cf.txt" \
    sort -u
Update: The previous example used parallel. Actually, I didn t need that. Turns out, using grep correctly is much faster than using grep the wrong way. Lession: Read the manual. :)

8 December 2016

Stig Sandbeck Mathisen: MIME types and applications

On a Linux system with desktop-file-utils installed, the default application for opening a file with a file manager, from a web browser, or using xdg-open on the command line is not static. The last installed or upgraded application becomes the default. For example: After installing gimp, that application will be used to open any of the many types of files it supports. This lasts until another application which can open those mime types is installed or upgraded. If I later install or upgrade mupdf , that application will be used for PDF, until, etcetera. There are several bug reports filed for this confusing behaviour: Debian: Ubuntu: Firefox:


/usr/bin/update-desktop-database is a command in the package desktop-file-utils This command is run in the package postinst script, and triggers on writes to /usr/share/applications where .desktop files are written.

/usr/share/applications This directory contains a list of applications (files ending with .desktop). These desktop files include mime types they are able to work with. The mupdf.desktop example shows it is able to work with (among other) application/pdf
[Desktop Entry]
GenericName=PDF file viewer
Comment=PDF file viewer
Exec=mupdf %f
[Desktop Action View]
Exec=mupdf %f
The gimp.desktop application entry shows it is more capable:
[Desktop Entry]
Name=GNU Image Manipulation Program
# [...]
However, I m quite sure I do not want gimp to be the default viewer for all those file types.

/usr/share/applications/mimeinfo.cache This is a list of MIME types, with a list of applications able to open them. The first entry in the list is the default application. You may also have one of these in ~/.local/share/applications for applications installed in the user s home directory. Examples: With gimp.desktop first, xdg-open test.pdf will use gimp
[MIME Cache]
# [...]
After uninstalling and reinstalling mupdf, mupdf.desktop is first in the list, and xdg-open test.pdf will use mupdf
[MIME Cache]
# [...]
The order of .desktop files in mimeinfo.cache is the reverse of the order they are added to that directory. The last installed utility is first in that list.

Application Trace This was fun to dig into. I ve just gotten some training which included a a better look at auditd. Auditd is a nice hammer, and this problem was a good nail. I ran the command under autrace , and then looked for the order of reads from each run. When mupdf is installed last, mupdf.desktop is read last, and placed first in the list of applications:
root@laptop:~# autrace /usr/bin/update-desktop-database
Waiting to execute: /usr/bin/update-desktop-database
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 13507'
root@laptop:~# ausearch -p 13507   aureport --file   egrep 'gimp mupdf'
389. 12/09/2016 17:35:37 /usr/share/applications/gimp.desktop 4 yes /usr/bin/update-desktop-database 1000 8002
390. 12/09/2016 17:35:37 /usr/share/applications/gimp.desktop 2 yes /usr/bin/update-desktop-database 1000 8003
391. 12/09/2016 17:35:37 /usr/share/applications/mupdf.desktop 4 yes /usr/bin/update-desktop-database 1000 8010
392. 12/09/2016 17:35:37 /usr/share/applications/mupdf.desktop 2 yes /usr/bin/update-desktop-database 1000 8011
root@laptop:~# grep application/pdf /usr/share/applications/mimeinfo.cache
Reinstalling gimp puts that first in the entry for application/pdf
root@laptop:~# apt install --reinstall gimp
Preparing to unpack .../gimp_2.8.18-1_amd64.deb ...
Unpacking gimp (2.8.18-1) over (2.8.18-1) ...
Processing triggers for mime-support (3.60) ...
Processing triggers for desktop-file-utils (0.23-1) ...
Setting up gimp (2.8.18-1) ...
Processing triggers for gnome-menus (3.13.3-8) ...
root@laptop:~# autrace /usr/bin/update-desktop-database
Waiting to execute: /usr/bin/update-desktop-database
Cleaning up...
Trace complete. You can locate the records with 'ausearch -i -p 15043'
root@laptop:~# ausearch -p 15043   aureport --file   egrep 'gimp mupdf'
389. 12/09/2016 17:39:53 /usr/share/applications/mupdf.desktop 4 yes /usr/bin/update-desktop-database 1000 9550
390. 12/09/2016 17:39:53 /usr/share/applications/mupdf.desktop 2 yes /usr/bin/update-desktop-database 1000 9551
391. 12/09/2016 17:39:53 /usr/share/applications/gimp.desktop 4 yes /usr/bin/update-desktop-database 1000 9556
392. 12/09/2016 17:39:53 /usr/share/applications/gimp.desktop 2 yes /usr/bin/update-desktop-database 1000 9557
root@laptop:~# grep application/pdf /usr/share/applications/mimeinfo.cache

Configuration The solution to this is to add configuration so it will use something else than the default. The xdg-mime command is your tool. The various desktop environments often do this for you. However, if you have a lightweight work environment, you may need to do this yourself for the MIME types you care about.
ssm@laptop ~ :) % xdg-mime query default application/pdf
ssm@laptop ~ :) % xdg-mime default mupdf.desktop application/pdf
ssm@laptop ~ :) % xdg-mime query default application/pdf
This updates ~/.local/share/applications/mimeapps.list , and you should now have set your preferred PDF reader.

19 October 2016

Reproducible builds folks: Reproducible Builds: week 77 in Stretch cycle

What happened in the Reproducible Builds effort between Sunday October 9 and Saturday October 15 2016: Media coverage Documentation update After discussions with HW42, Steven Chamberlain, Vagrant Cascadian, Daniel Shahaf, Christopher Berg, Daniel Kahn Gillmor and others, Ximin Luo has started writing up more concrete and detailed design plans for setting SOURCE_ROOT_DIR for reproducible debugging symbols, buildinfo security semantics and buildinfo security infrastructure. Toolchain development and fixes Dmitry Shachnev noted that our patch for #831779 has been temporarily rejected by docutils upstream; we are trying to persuade them again. Tony Mancill uploaded javatools/0.59 to unstable containing original patch by Chris Lamb. This fixed an issue where documentation Recommends: substvars would not be reproducible. Ximin Luo filed bug 77985 to GCC as a pre-requisite for future patches to make debugging symbols reproducible. Packages reviewed and fixed, and bugs filed The following updated packages have become reproducible - in our current test setup - after being fixed: The following updated packages appear to be reproducible now, for reasons we were not able to figure out. (Relevant changelogs did not mention reproducible builds.) Some uploads have addressed some reproducibility issues, but not all of them: Some uploads have addressed nearly all reproducibility issues, except for build path issues: Patches submitted that have not made their way to the archive yet: Reviews of unreproducible packages 101 package reviews have been added, 49 have been updated and 4 have been removed in this week, adding to our knowledge about identified issues. 3 issue types have been updated: Weekly QA work During of reproducibility testing, some FTBFS bugs have been detected and reported by: Debian: Openwrt/LEDE/NetBSD/coreboot/Fedora/archlinux: Misc. We are running a poll to find a good time for an IRC meeting. This week's edition was written by Ximin Luo, Holger Levsen & Chris Lamb and reviewed by a bunch of Reproducible Builds folks on IRC.

11 October 2016

Stig Sandbeck Mathisen: DevOps toys, looking at new and old tools

From last month s toybox of distractions, I ve spent time with GitLab CI, Ansible, Prometheus and OpenShift. GitLab CI is a lot like Travis CI, and a little less like Jenkins. When a commit is pushed to the repository in GitLab, and the branch contains a .gitlab-ci.yml file, a GitLab CI runner will check out the repository, and follow the instructions in that file. Useful for configuration syntax checks, unit tests, and puppet environment deployments. I ve mostly used Ansible for orchestration, performing tasks across a number of nodes. I ve used it much configuration management for a bit, and from what I see, it can do that rather well, too. I ve used Puppet in production for a bit (I committed revision 1 in the old puppet configuration management repository at work in 2007-07-04). A new perspective on configuration management is good. Prometheus is a master-node stats gatherer and presenter. It does a single HTTP GET to fetch all metrics in a single request. I ve used Munin for a long, long time, and while the plugin ecosystem is far larger for Munin, the Prometheus master scales much better (millions of metrics per minute on a modern machine). I use Grafana to present graphs from Prometheus and logs from Elasticsearch in the same dashboard. Prometheus can collect data from a munin node, using a munin node exporter. Last week I got training in OpenShift, which was an eye-opener. I ve used Docker for a good while, and planned to introduce Kubernetes, as well as an imperial buttload of shell scripts to keep it all automated. Thankfully, OpenShift Origin already includes Kubernetes and does the required automation. An OpenShift cluster is now being added to the core infrastructure to do the required care and feeding of the herd of APIs and microservices written over the years. Bunch it together behind an API Management Gateway, and you should be able to label the whole thing Microservice Architecture . I m not running out of fun things to do for a while.

28 May 2016

Stig Sandbeck Mathisen: Puppet 4 uploaded to Debian unstable

Puppet 4 has been uploaded to Debian unstable. This is a major upgrade from Puppet 3. If you are using Puppet, chances are that it is handling important bits of your infrastructure, and you should upgrade with care. Here are some points to consider.

Read Puppet s upgrade checklist First, there are a number of changes in Puppet itself. There is an upgrade checklist for Puppet (the software) published by Puppet (the company). Please read this before you upgrade, and not after.

Using exported resources? In Puppet 4, using exported resources requires PuppetDB, which is not packaged in Debian.

Getting PuppetDB Puppet provides good installation documentation for PuppetDB, and an apt software repository where you you can get the packages you require.

Editor support packages The packages vim-puppet and puppet-el provide support for editors Vim and Emacs. These are no longer built from the puppet source package. The sources for these have moved to separate repositories, and will get individual source packages. For vim-puppet, there are two alternatives for new packaging, rodjek/vim-puppet, and puppetlabs/puppet-syntax-vim For puppet-el puppetlabs/puppet-syntax-emacs and lunaryorn/puppet-mode are available.

18 May 2016

Stig Sandbeck Mathisen: Puppet 4 uploaded to Debian experimental

I ve uploaded puppet 4.4.2-1 to Debian experimental. Please test with caution, and expect sharp corners. This is a new major version of Puppet in Debian, with many new features and potentially breaking changes, as well as a big rewrite of the .deb packaging. Bug reports for src:puppet are very welcome. As previously described in #798636, the new package names are: Lots of hugs to the authors, keepers and maintainers of autopkgtest, debci, piuparts and ruby-serverspec for their software. They helped me figure out when I had reached good enough for experimental . Some notes: I sincerely hope someone finds this useful. :)

27 April 2016

Stig Sandbeck Mathisen: Using LLDP on Linux. What's on the other side?

On any given server, or workstation, knowing what is at the other end of the network cable is often very useful. There s a protocol for that: LLDP. This is a link layer protocol, so it is not routed. Each end transmits information about itself periodically. You can typically see the type of equipment, the server or switch name, and the network port name of the other end, although there are lots of other bits of information available, too. This is often used between switches and routers in a server centre, but it is useful to enable on server hardware as well. There are a few different packages available. I ve looked at a few of them available for the RedHat OS family (Red Hat Enterprise Linux, CentOS, ) as well as the Debian OS family (Debian, Ubuntu, ) (Updated 2016-04-29, added more recent information about lldpd, and gathered the switch output at the end.)

ladvd A simple daemon, with no configuration needed. This runs as a privilege-separated daemon, and has a command line control utility. You invoke it with a list of interfaces as command line arguments to restrict the interfaces it should use. ladvd is not available on RedHat, but is available on Debian. Install the ladvd package, and run ladvdc to query the daemon for information.
root@turbotape:~# ladvdc
Capability Codes:
    r - Repeater, B - Bridge, H - Host, R - Router, S - Switch,
    W - WLAN Access Point, C - DOCSIS Device, T - Telephone, O - Other
Device ID        Local Intf Proto Hold-time Capability Port ID
office1-switch23 eno1       LLDP  98        B          42
Even better, it has output that can be parsed for scripting:
root@turbotape:~# ladvdc -b eno1
my new favourite :)

lldpd Another package is lldpd , which is also simple to configure and use. lldpd is not available on RedHat, but it is present on Debian. It features a command line interface, lldpcli , which can show output with different level of detail, and on different formats, as well as configure the running daemon.
root@turbotape:~# lldpcli show neighbors
LLDP neighbors:
Interface:    eno1, via: LLDP, RID: 1, Time: 0 day, 00:00:59
    ChassisID:    mac 00:11:22:33:44:55
    SysName:      office1-switch23
    SysDescr:     ProCurve J9280A Switch 2510G-48, revision Y.11.12, ROM N.10.02 (/sw/code/build/cod(cod11))
    Capability:   Bridge, on
    PortID:       local 42
    PortDescr:    42
Among the output formats are json , which is easy to re-use elsewhere.
root@turbotape:~# lldpcli -f json show neighbors
            "descr": "ProCurve J9280A Switch 2510G-48, revision Y.11.12, ROM N.10.02 (/sw/code/build/cod(cod11))",
              "type": "mac",
              "value": "00:11:22:33:44:55"
              "type": "Bridge",
              "enabled": true
        "via": "LLDP",
        "rid": "1",
        "age": "0 day, 00:53:23",
          "descr": "42",
            "type": "local",
            "value": "42"

lldpad A much more featureful LLDP daemon, available for both the Debian and RedHat OS families. This has lots of features, but is less trivial to set up.

Configure lldp for each interface
find /sys/class/net/ -maxdepth 1 -name 'en*'  
    while read device; do
        basename "$device"
    while read interface; do
            lldptool set-lldp -i "$interface" adminStatus=rxtx
            for item in sysName portDesc sysDesc sysCap mngAddr; do
                lldptool set-tlv -i "$interface" -V "$item" enableTx=yes  
                    sed -e "s/^/$item /"
            sed -e "s/^/$interface /"

Show LLDP neighbor information
find /sys/class/net/ -maxdepth 1 -name 'en*'  
    while read device; do
        basename "$device"
    while read interface; do
        printf "%s\n" "$interface"
        ethtool $interface   grep -q 'Link detected: yes'    
            echo "  down"
        lldptool get-tlv -n -i "$interface"   sed -e "s/^/  /"
  Chassis ID TLV
    MAC: 01:23:45:67:89:ab
  Port ID TLV
    Local: 588
  Time to Live TLV
  System Name TLV
  System Description TLV
    Juniper Networks, Inc. ex2200-48t-4g , version 12.3R12.4 Build date: 2016-01-20 05:03:06 UTC
  System Capabilities TLV
    System capabilities:  Bridge, Router
    Enabled capabilities: Bridge, Router
  Management Address TLV
    Ifindex: 36
    OID: $
  Port Description TLV
    some important server, port 4
  MAC/PHY Configuration Status TLV
    Auto-negotiation supported and enabled
    PMD auto-negotiation capabilities: 0x0001
    MAU type: Unknown [0x0000]
  Link Aggregation TLV
    Aggregation capable
    Currently aggregated
    Aggregated Port ID: 600
  Maximum Frame Size TLV
    PVID: 2000
    VID 2000: Name bumblebee
    VID 2001: Name stumblebee
    VID 2002: Name fumblebee
  LLDP-MED Capabilities TLV
    Device Type:  netcon
    Capabilities: LLDP-MED, Network Policy, Location Identification, Extended Power via MDI-PSE

on the switch side On the switch, it is a bit easier to see what s connected to each interface:

office switch On the switch side, this system looks like:
office1-switch23# show lldp info remote-device
 LLDP Remote Devices Information
  LocalPort   ChassisId                 PortId PortDescr SysName
  --------- + ------------------------- ------ --------- ----------------------
  42          22 33 44 55 66 77         eno1   Intel ...
office1-switch23# show lldp info remote-device 42
 LLDP Remote Device Information Detail
  Local Port   : 42
  ChassisType  : mac-address
  ChassisId    : 00 11 22 33 33 55
  PortType     : interface-name
  PortId       : eno1
  SysName      :
  System Descr : Debian GNU/Linux testing (stretch) Linux 4.5.0-1-amd64 #1...
  PortDescr    : Intel Corporation Ethernet Connection I217-LM
  System Capabilities Supported  : bridge, router
  System Capabilities Enabled    : bridge, router
  Remote Management Address
     Type    : ipv4
     Address :
     Type    : ipv6
     Address : 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01
     Type    : all802
     Address : 22 33 44 55 66 77

datacenter switch
ssm@site3-row2-rack1> show lldp neighbors
Local Interface    Parent Interface    Chassis Id          Port info          System Name
ge-0/0/38.0        ae1.0               01:23:45:67:89:58   Interface   2 as enp3s0f0
ge-1/0/38.0        ae1.0               01:23:45:67:89:58   Interface   3 as enp3s0f1
ssm@site3-row2-rack1> show lldp neighbors interface ge-0/0/38
LLDP Neighbor Information:
Local Information:
Index: 157 Time to live: 120 Time mark: Fri Apr 29 13:00:19 2016 Age: 24 secs
Local Interface    : ge-0/0/38.0
Parent Interface   : ae1.0
Local Port ID      : 588
Ageout Count       : 0
Neighbour Information:
Chassis type       : Mac address
Chassis ID         : 01:23:45:67:89:58
Port type          : Mac address
Port ID            : 01:23:45:67:89:58
Port description   : Interface   2 as enp3s0f0
System name        :
System Description : Linux 3.10.0-327.13.1.el7.x86_64 #1 SMP Thu Mar 4
System capabilities
        Supported  : Station Only
        Enabled    : Station Only
Management Info
        Type              : IPv6
        Address           : 2001:0db8:0000:0000:0000:dead:beef:cafe
        Port ID           : 2
        Subtype           : 2
        Interface Subtype : ifIndex(2)
        OID               :

6 January 2016

Stig Sandbeck Mathisen: Thoughts on Puppet 4 related packages

It s been a while since I ve looked at the puppet 4 packaging. During this time, a lot of things have happened.

puppet Puppet 4 is out. I ve done some packaging tests, and they are promising.

puppet-agent Puppet Labs released puppet-agent recently, with instructions. It looks like an umbrella project for building and bundling puppet, facter, augeas, ruby, and everything else to install on puppet managed nodes. It downloads a lot of software over HTTP or git, and verifies at least some of it with md5 checksums. I don t think this is needed for Debian.

puppet-server This really needs packaging. There are probably lots of dependencies not packaged yet. I am not familiar with any of the build tools.

puppetdb Needs packaging. There are probably lots of dependencies not packaged yet. I am not familiar with any of the build tools.

vim-puppet This has moved outside the puppet repository. Both puppetlabs and rodjek have vim modes for puppet. I ve grown very fond of rodjek s vim-puppet.

puppet-el This has moved outside the puppet repository. Both puppetlabs and lunaryorn have emacs modes for puppet.

puppet modules There are a lot of puppet modules in the team VCS.

4 January 2016

Stig Sandbeck Mathisen: Munin 3 packaging

The Munin project is moving slowly closer to a Munin 3 release. In parallel, the Debian packaging is changing, too. The new web interface is looking much better than the traditional web-1.0 interface normally associated with munin.

New package layout

perl libraries All the Munin perl libraries are placed in libmunin-*-perl , and split into separate packages, where the split is decided mostly on dependencies. If you don t want to monitor samba, or SNMP, or MySQL, there should be no need to have those libraries installed. That does mean more binary packages, on the other hand.

Munin master Munin now runs as a standalone HTTPD, it no longer graphs from cron, nor does it run as CGI or FastCGI scripts. The user munin grants read-write access, while the group munin grants read only access. The new web interface runs as the munin-httpd user, which is member of the munin group. There is a munin service. For now, it runs rrdcached for the munin user and RRD directory.

munin node The perl munin-node and the compiled munin-node-c should be interchangeable, and be able to run the same plugins. Munin node, and Munin async node, should be wholly separate from the munin master. It should be possible to use the perl munin-node package, and the

munin plugins The munin plugins are placed separate packages named munin-plugins-* . The split is based on monitoring subject, or dependencies. They depend on appropriate libmunin-plugin-*-perl packages The munin-plugins-c package, which is is from the munin-node-c source, contains a number of compiled plugins which should use less resources than their shell, perl or python equivalents. Plugins from other sources than munin must work similar to the ones from munin . More work on this is needed.

Testing Late December 2015, I set up Jenkins, with jenkins-debian-glue to build packages, test with autopkgtest and and update my development apt repository on each commit. That helped developing and testing the new Munin packages. The packages are not quite ready to upload to experimental, but they are continuously deployed to weed out bugs. They can be found in my packaging apt repo. (The usual non-guarantees apply, handle with care, keep away from small children, etc )

Comments Munin developers, packagers and users hang out on #munin on the OFTC network. Please drop by if you have questions or comments.

7 November 2015

Stig Sandbeck Mathisen: Let's Encrypt with Hitch and Varnish

Let's Encrypt is now in beta. Here's how to use the automated CA with Hitch TLS proxy, and Varnish HTTP accelerator as a backend for Hitch.
Let's Encrypt Let's Encrypt is a free, automated and open Certificate Authority (CA), run for the public's benefit.
Varnish Varnish is a HTTP accelerator. I use it as a web server, and it serves content from various backends. Varnish is used on a lot of high-traffic web servers, and supports simple and complex web site configurations.
Hitch Hitch is a TLS proxy, by Varnish Software. It terminates TLS connections, and forwards them to a backend, unencrypted. The TLS proxy is simple to configure, and handles many thousands of requests per second on commodity hardware. Hitch was originally called stud and was written by Jamie Turner at
Varnish plugin for Let's Encrypt Let's Encrypt Varnish Plugin is needed for the Let's Encrypt client to authenticate against their service, for getting the certificates. You can skip this if you have the option of temporarily disabling your web service, when registering and renewing your certificates.
Hitch TLS proxy Hitch must be configured to listen on the https port (TCP/443), with a list of strong ciphers. To get Forward Secrecy, we need ciphers with EECDH or EDH. To use these, we need to generate a set of DH Parameters. In /etc/hitch/hitch.conf:
# Listening
frontend = "[*]:443"
Varnish as backend for Hitch Hitch will forward traffic to Varnish on localhost:6082, using the PROXY protocol. Here's a snippet for /etc/hitch/hitch.conf to do this:
# Send traffic to the varnish backend
backend        = "[::1]:6086"
write-proxy-v2 = on
For varnish, I've added a separate port for the "PROXY" protocol, by adding an extra "-a" argument for port 6086. The -a :80 handles the existing http traffic, while the -a '[::1]:6086,PROXY' adds a listener on localhost, which will be used by hitch.
/usr/sbin/varnishd -j unix,user=vcache -a :80 -a '[::1]:6086,PROXY' ...
Let's Encrypt install letsencrypt First, install the letsencrypt client. The beta program sends you a mail with instructions. When it is generally available, I suspect it'll be something like:
apt install letsencrypt
install varnish plugin Then, get the let's encrypt varnish plugin. The plugin will extend the letsencrypt software to be able to rewrite the VCL and reload Varnish to satisfy the authentication challenge of the Let's Encrypt server.
cd /usr/local/src
git clone
. ~/.local/share/letsencrypt/bin/activate
pip install -e /usr/local/src/letsencrypt-varnish-plugin
get certificate Get certificates. Let's Encrypt is still in beta, so I had to add a few more command line arguments than the documentation specifies:
~/.local/share/letsencrypt/bin/letsencrypt --agree-dev-preview \
    --server \
    -a letsencrypt-varnish-plugin:varnish -d certonly
Adding certificates to Hitch Hitch requires one PEM file per domain we serve. Each .pem file contains the private key, the signed certificate and any required intermediates. Create a file with DH parameters:
openssl dhparam -out /etc/hitch/dhparam.pem 2048
This file may take a long while to generate. Combine the key, the signed certificate, and the dhparam file to something hitch can use:
cat \
    /etc/letsencrypt/live/ \
    /etc/letsencrypt/live/ \
    /etc/hitch/dhparam.pem \
    > /etc/hitch/
chmod 0600 /etc/hitch/
and configure hitch to use the file, by adding it to /etc/hitch/hitch.conf:
# List of PEM files, each with key, certificates and dhparams
pem-file = "/etc/hitch/"
pem-file = "/etc/hitch/"
pem-file = "/etc/hitch/"
pem-file = "/etc/hitch/"

3 October 2015

Stig Sandbeck Mathisen: Free software activities in September 2015

Munin Working on making the munin master fit inside Mojolicious. The existing code is not written to make this trivial, but all the pieces are there. Most of the pieces need breaking up into smaller pieces to fit. Debian Packaging New version of puppet-module-puppetlabs-apache (Closes: #788124 #788125 #788127 ). I like it when a new upstream version closes all bugs left in the bts for a package. A new package, the TLS proxy hitch currently waiting in the queue. Puppet Lots of work on a new ceph puppet module.

18 February 2013

Jan Wagner: Server Management

Server management on daily basis in a growing environment could be a challenge. Most of the tasks is here done with ClusterSSH in help with a homebrew mail notification. Unfortunately this workflow is not scaling well for 200+ systems. I had a look into apt-dater but this seems not to fit our workflow. FAI looks a bit overengineered at the first glance. Maybe Puppet is an option? There seems to be many extensions for it, unfortunately ruby is needed on every single node. Is there a CTO-compatible overview about puppet, any other alternatives? ;) Update: Many thanks for the hints from Andr Lu s Lopes, Stig Sandbeck Mathisen, Phil Miller, Steve Kemp, Andrew Latham, Bob Proulx and Natxo Asenjo Old but conceptual still valid:, for example Bootstrapping an Infrastructure Other thoughts: push- or pull-infrastructure? Software footprint (on nodes and your central instance)! Hints, rants and comments could be send to 'blog - at - waja - dot - info' or via @blogwajainfo.

4 June 2011

Jan Wagner: Monitoring related package updates

Some more about packaging nagios and icinga related packages can be found at our team site.