open source basecamp

RSS
Twitter
 
Blog

Posts Tagged ‘infrastructure’

DRBD – doublez vos octets !

Wednesday, May 2nd, 2012 by Stéphanie Debayle

DRBD (Distributed Replicated Block Device) est un logiciel libre sous licence GNU GPLv2 uniquement supporté sur GNU/Linux. Il permet la réplication de périphériques de stockage bloc à bloc, et peut être vu comme un disque RAID-1 réseau.

C’est un des composants permettant d’assurer la haute disponibilité des ressources installées sur les disques/partitions/volumes logiques qu’il gère. Dans cet article à multimains, il est expliqué ce que d’une part nous avons testé et d’autre part mis en place à l’EPFL pour différentes applications en production.

Mcollective and Augeas

Tuesday, April 17th, 2012 by Raphaël Pinson

Mcollective is a very useful tool, which often saves us a lot of time, especially when gathering information about nodes. One information one might want to retrieve from nodes is configuration parameters.

Look at this colorful configuration tree!

Look at this colorful configuration tree!

These can be easily retrieved using custom facts, but you probably don’t want to write and deploy new facts every time you need to query a specific configuration parameter.

This is where Augeas gets on the scene. Augeas is already used quite widely in Puppet to modify configuration files. It works pretty much like a configuration scalpel, allowing you to edit precisely the parameter you want, without impacting the rest of the file (and mostly, without having to parse the file syntax). But Augeas can also be used as a powerful, generic parser to retrieve configuration parameters using its XPath language. In our case, it only lacks a remote API. Coupling it with Mcollective would thus provide a great means of accessing specific configuration parameters remotely.

Fortunately, I was not the first to have this idea. Dean Wilson already wrote an Mcollective agent for Augeas, available on github. After a bit of improvement, and the addition of a client-side application, we now have a useful tool to query configuration parameters through Mcollective, in a similar way to that of augtool. The application currently provides two actions: match and count:


$ mco augeas match "/files/etc/mtab/*[file = '/']/vfstype" -F lsbdistcodename=precise

* [ ============================================================> ] 5 / 5

host-a7256c41c4
/files/etc/mtab/1/vfstype = ext4
host-b89d50982a
/files/etc/mtab/1/vfstype = ext4
host-21cbf2a961
/files/etc/mtab/1/vfstype = ext4
host-265d6ed4a4
/files/etc/mtab/1/vfstype = ext4
host-12299c6389
/files/etc/mtab/1/vfstype = ext4


$ mco augeas count "/files/etc/passwd/rpinson" -F operatingsystem=Ubuntu

* [ ============================================================> ] 5 / 5

host-a7256c41c4
0 matches found
host-21cbf2a961
1 matches found
host-b89d50982a
0 matches found
host-265d6ed4a4
1 matches found
host-12299c6389
1 matches found

There are however some files that cannot be easily accessed via Augeas, since they are not in standard (or otherwise fixed) locations. You can associate them manually to Augeas lenses in the Mcollective command, using the --transform option:


$ mco augeas match --transform "Desktop=/usr/share/applications/*.desktop" "//Desktop\ Entry/Version" -W /host-21cbf2a961/

* [ ============================================================> ] 1 / 1

host-21cbf2a961
/files/usr/share/applications/gnome-sudoku.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/remmina.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/activity-log-manager-ccpanel.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/shotwell-viewer.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/empathy-accounts.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/deja-dup-preferences.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/inkscape.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/clusterssh.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/shotwell.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/junglediskworkgroup.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/htop.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/nact.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/indicator-datetime-preferences.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/gimp.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/deja-dup-ccpanel.desktop/Desktop Entry/Version = 1.0
/files/usr/share/applications/empathy.desktop/Desktop Entry/Version = 1.0

More than one mapping can be added by separating mapping directives with commas.

The code for agent and application can be found on github.

Open positions @ Camptocamp !!!

Monday, September 12th, 2011 by Marie-France Cochard

Notre division ”Infrastructure Solutions” de Chambéry en France, est à la recherche d’un Ingénieur Système Linux et notre division ”Geospatial Solutions” de Lausanne en Suisse, est à la recherche d’un Open Source Project Manager.

Nous attendons vos dossiers complets à l’adresse : job@camptocamp.com.

CouchDB to easily bootstrap a Puppet CMDB

Friday, May 20th, 2011 by Mathieu Bornoz

For several reasons, the need to centralize some metadata comes relatively quickly when you work everyday with Puppet.

For example:

  • the data that you wish to use are already present in another system/service
  • you want to share data between different systems/services
  • you don’t manage these data, you can just read them
  • etc.

In the example below, I use CouchDB [1], a simple document-oriented database which has the great advantage of providing a RESTful JSON HTTP API. To start, simply install CouchDB. For example, on a recent Debian/Ubuntu you can simply do:

$ apt-get install couchdb

A simple request to check that CouchDB works:

$ curl http://localhost:5984
{"couchdb":"Welcome","version":"0.11.0"}

Now, I want to create a database named “user” and insert in it some documents (users). First of all, I create a file (user1.json) that contains a document that is actually a JSON object:

{
   "_id": "user1",
   "ensure": "present",
   "firstname": "foo",
   "lastname": "bar",
   "uid": 1001,
   "password": "$6$rXn/lNjS$CRdQQ05D7ZV2xgg...",
   "managehome": true,
   "groups": ["admin","sudo"],
   "shell": "/bin/bash",
   "email": "foo@bar.com",
   "ssh_type": "ssh-rsa",
   "ssh_pub_key": "AAAAB3NzaC1yc2EAAAADAQABAAABAQCzc..."
}

Then, I create the database and insert in the document:

$ curl -X PUT http://localhost:5984/user
{"ok":true}
$ curl -X PUT http://localhost:5984/user/user1 -d @user1.json
{"ok":true,"id":"user1","rev":"1-b82efa560b9699fd4d5898bfdaa95277"}

This last step may be repeated to create other users of course with different values especially the username which is the “_id” of the document. Once the users are inserted in the CouchDB database “user”, we can easily test their presence:

$ curl -s http://localhost:5984/user/_all_docs |python -m simplejson.tool
{
    "offset": 0,
    "rows": [
        {
            "id": "user1",
            "key": "user1",
            "value": {
                "rev": "10-aed60887f53030470891c158c424a44b"
            }
        },
        {
            "id": "user2",
            "key": "user2",
            "value": {
                "rev": "3-628d7cc78888a9344273fa42bd95dca5"
            }
        },
        {
            "id": "user3",
            "key": "user3",
            "value": {
                "rev": "3-35e523b183ad70ab4532374f423931b2"
            }
        },
        {
            "id": "user4",
            "key": "user4",
            "value": {
                "rev": "1-b28b7aeea77170126b83d7c7f470ea4f"
            }
        }
    ],
    "total_rows": 4
}

If you want to see the contents of each document, you can use the following query:

$ curl http://localhost:5984/user/_all_docs?include_docs=true

Now, our CMDB is ready to use with Puppet! To start, we will simply retrieve the parameters of resources via a small Puppet function named couchdblookup available inside our module puppet-couchdb [2]. Here is a simple definition which wraps the creation of a user-based on metadata contained in CouchDB:

define couchdb-user () {

  $couchdb_bind_address = "localhost"
  $couchdb_port = "5984"
  $couchdb_baseurl = "http://${couchdb_bind_address}:${couchdb_port}"
  $tinyurl = "${couchdb_baseurl}/user/${name}"
  $email = couchdblookup($tinyurl, "email")
  $firstname = couchdblookup($tinyurl, "firstname")
  $lastname = couchdblookup($tinyurl, "lastname")

  user {$name:
    ensure     => couchdblookup($tinyurl, "ensure"),
    uid        => couchdblookup($tinyurl, "uid"),
    password   => couchdblookup($tinyurl, "password"),
    groups     => couchdblookup($tinyurl, "groups"),
    shell      => couchdblookup($tinyurl, "shell"),
    managehome => couchdblookup($tinyurl, "managehome"),
    comment    => "${firstname} ${lastname}",
  }

  ssh_authorized_key {"${email} on ${name}":
    ensure  => couchdblookup($tinyurl, "ensure"),
    type    => couchdblookup($tinyurl, "ssh_type"),
    user    => $name,
    key     => couchdblookup($tinyurl, "ssh_pub_key"),
    require => User[$name],
  }

}

Finally, you can declare where you want in your recipes one or more users:

couchdb-user {["user1","user2","user3","user4"]:}

The example above is based on a standard approach using the external Puppet DSL which means having to explicitly declare the resources. A great trick would be to loop through all documents in the database “user” to create resources dynamically. Since version 2.6, it’s been possible but for this we must use the Puppet’s Ruby DSL [3].

Here is a simple piece of Ruby (hostclass couchdbusers) which loops through all documents and creates the users:

require 'json'
require 'open-uri'

hostclass :couchdbusers do
  url="http://localhost:5984/user/_all_docs?include_docs=true"
  result = JSON.parse(open(URI.parse(url)).read)
  result['rows'].each do |x|
    user x['doc']['_id'],
      :ensure     => x['doc']['ensure'],
      :uid        => x['doc']['uid'],
      :shell      => x['doc']['shell'],
      :password   => x['doc']['password'],
      :managehome => x['doc']['managehome']

    ssh_authorized_key "#{x['doc']['email']} on #{x['doc']['_id']}",
      :ensure  => x['doc']['ensure'],
      :user    => x['doc']['_id'],
      :type    => x['doc']['ssh_type'],
      :key     => x['doc']['ssh_pub_key'],
      :require => "User[#{x['doc']['_id']}]"
  end
end

Then, this class can be used directly in your manifests (for example, in your site.pp) like this:

import "classes/couchdbusers.rb"
include couchdbusers

This last example does exactly the same as the previous one except that, in this case, we can add documents in our database without having to explicitly declare the new resources. Finally, here’s what you should get by running Puppet:

$ sudo puppetd -t --verbose
info: ...
...
info: Applying configuration version '1305882280'
notice: /Stage[main]/Couchdbusers/User[user2]/ensure: created
notice: /Stage[main]/Couchdbusers/Ssh_authorized_key[foo2@bar2.com on user2]/ensure: created
notice: /Stage[main]/Couchdbusers/User[user1]/ensure: created
notice: /Stage[main]/Couchdbusers/Ssh_authorized_key[foo@bar.com on user1]/ensure: created
notice: /Stage[main]/Couchdbusers/User[user3]/ensure: created
notice: /Stage[main]/Couchdbusers/Ssh_authorized_key[foo3@bar3.com on user3]/ensure: created
notice: /Stage[main]/Couchdbusers/User[user4]/ensure: created
notice: /Stage[main]/Couchdbusers/Ssh_authorized_key[foo4@bar4.com on user4]/ensure: created
notice: Finished catalog run in 1.01 seconds

$ sudo grep "^user" /etc/passwd
user2:x:1001:1001::/home/user2:/bin/bash
user1:x:1002:1002::/home/user1:/bin/bash
user3:x:1003:1003::/home/user3:/bin/bash
user4:x:1004:1004::/home/user4:/bin/bash

Hope someone finds this useful!

[1] http://couchdb.apache.org/
[2] https://github.com/camptocamp/puppet-couchdb
[3] http://projects.puppetlabs.com/projects/1/wiki/Ruby_Dsl

SIG La lettre : interview de Camptocamp

Monday, May 9th, 2011 by Stéphanie Debayle

Le dernier numéro du magazine français SIG La lettre, journal indépendant des éditeurs de SIG et des fournisseurs de données au service des utilisateurs, consacre une interview à Claude Philipona, Directeur Asssocié de Camptocamp.

L’intégralité de l’article est disponible ici.

Puppet Camp EU : Amsterdam, 28-29 April 2011

Wednesday, April 27th, 2011 by Mathieu Bornoz

A delegation of Camptocamp’s Infrastructure Solutions Division will be present in Amsterdam on April 28th and 29th at the second Puppetcamp in Europe. For the first time in addition to traditional track of speakers this event will offer hosted breakout sessions, unconference sessions, a code sprint room, and a bug squash room. This event is really a unique opportunity for many of us to share our experience and discuss various aspects of systems automation.

Camptocamp, Gold Partner of the event uses Puppet to manage hundreds of machines for many years. We try as much as possible to share our developments and experience by making our many puppet-modules available on Github. We also offer training, consulting and complete server farm management for companies (like Swisstopo) who wants to industrialize/automate the management of their infrastructure to focus on application aspects. We are pleased to see the growing enthusiasm around automation tools like Puppet and are convinced it is going in the right direction!

Etude de cas : utilisation de Puppet par Swisstopo

Tuesday, April 26th, 2011 by Mathieu Bornoz

Puppetlabs présente sur son site web un case-study relatif à l’utilisation intensive de Puppet dans le cadre de l’importante migration de Swisstopo dans une infrastructure de type IaaS “Infrastructure as a Service” et plus particulièrement basées sur les services d’Amazon AWS (voir http://aws.amazon.com/solutions/case-studies/swisstopo/).

La division “Infrastructure Solutions” de Camptocamp est très fière de la réussite de ce projet car elle a mis toutes ses compétences au service de Swisstopo pour conseiller, architecturer et réaliser cette nouvelle infrastructure qui n’aurait jamais vu le jour sans la conjonction de paramètres suivants :

  • une très bonne connaissance des besoins du client (Swisstopo) de part une longue et étroite collaboration ;
  • plus de 10 ans d’expérience de Camptocamp conjointement dans les domaines des SIG, de l’infrastructure et des systèmes Linux ;
  • l’arrivée de la virtualisation et des infrastructures du type IaaS qui permet une grande flexibilité tout en se concentrant sur le conteneur applicatif ;
  • l’arrivée de Puppet framework Open Source extrêmement performant qui a révolutionné notre manière de gérer les serveurs (merci Luke, Puppetlabs et toute la communauté !) ;
  • une utilisation intensive de Puppet dès sa création et la réalisation de nombreux modules éprouvés https://github.com/camptocamp/ ;
  • l’émergence des principes “DevOps” qui nous ont conforté dans l’idée d’intensifier la collaboration entre les développeurs (software development) et administrateurs système (IT operations) ;
  • la confiance qui nous est portée par Swisstopo et sa reconnaissance qui dynamise nos équipes et nous encourage à donner le meilleur ;
  • beaucoup de rigueur dans la réalisation.

Plus d’informations également disponibles ici.


Puppet Camp EU : Amsterdam, 28-29 April 2011

Monday, February 14th, 2011 by Mathieu Bornoz

Gold partner of the event, Camptocamp’s Infrastructure Solutions Division will be present at the next Puppet Camp EU in Amsterdam.

Puppet Camp is a bi-annual community oriented gathering of Puppet users and developers. Camptocamp regards it as one of the most valuable and fun conferences we attend since we have been using this framework, contributing to various modules accessible via Github, and promoting its use to our customers.

The event is the opportunity for us to network with a diverse group of Puppet users, to benefit from insightful lectures delivered by prominent community members, and to be able to share experiences and discuss potential implementations of Puppet during breakout sessions.

Stay tuned for a daily summary on the highlights of this conference!

Debian 6.0 “Squeeze” released!

Monday, February 7th, 2011 by Mathieu Bornoz

After 24 months of constant development, the Debian Project is proud to present its new stable version 6.0 (code name Squeeze). Debian 6.0 is a free operating system, coming for the first time in two flavors. Alongside Debian GNU/Linux, Debian GNU/kFreeBSD is introduced with this version as a technology preview.

Camptocamp Infrastructure Solutions team has been providing services based on this solution which represents a free operating system developed by thousands of volunteers from all over the world who collaborate via the Internet;  the Debian project’s key-strengths are its volunteer base, its dedication to the Debian Social Contract and Free Software, and its commitment to provide the best operating system possible.

Thanks to its stability, robustness and versatility, Debian is Camptocamp’s system of choice for the hundreds of servers installed and maintained by our Infrastructure division. Debian 6.0 is another important step in the industrialisation and automation process. Camptocamp is currently working arduously on adapting numerous Puppet modules to this distribution.

Camptocamp’s hosted solutions in Business Solutions and Geospatial Solutions projects have been adapted and Debian “Squeeze” is now part of our standard offerings.

Camptocamp is a proud supporter to the solution and participated to Debian Bug Squashing Parties.

Debian Bug Squashing Party

Monday, November 29th, 2010 by Marc Fournier

Camptocamp sponsored one of the Debian distribution’s Bug Squashing Parties (BSP), which was held in Bern last week-end (27-28 nov. 2010).

Debian’s “testing” branch is currently frozen, which means no new features get added to the distribution, only bugfixes are allowed in. At this point, people focus on bugfixing and several BSPs are usually organised. It’s also the time when any Debian developer is allowed to fix bugs on packages maintained by others, through the “Non-Maintainer Upload” (NMU) mechanism.

During the BSP in Bern, a bit more than 30 bugs were worked on by a handful of Debian developers, maintainers and users. Most of these bugs which were tackled are considered “Release Critical” (RC); which are either security issues, grave disfunctions in software (crashes, data corruption), uninstallable/unremovable/unupgradable packages, or licencing problems.

The next step after the freeze is of course the release of the Debian GNU/Linux distribution’s next “stable” version, which will be 6.0, codename “squeeze”.

At Camptocamp, for its stablility, robustness and versatility, Debian is our system of choice on the hundreds of servers installed and maintained by the Infrastructure division. We are therefore looking forward to the next release, which will bring us another step forward in the industrialisation and automation process.