Archive for the Category » NetAdmin «

Tuesday, September 14th, 2010 | Author:

eth0I recently switched from puppet daemon to mcollective commander : it kicks the “stuck in outer space puppet daemon” feature out of the way and brings me nice features (as load control). To do so I deployed the puppetd agent over my boxes.

As most of the sysadmins say : “if it’s not monitored, it doesn’t exist” I had placed a script in cron based on the puppetlast script to report by mail once a day which hosts had not checked in during the last 30 minutes. This method had 2 serious flaws : it runs only once a day (I hate being flooded by mails) and test machines keep nagging you until you remove the yaml files on the puppetmaster. Talking with Volcane on #mcollective I discovered that the agent was able to report when the client last run, so I decided to use this to check my puppet runs freshness with a nagios plugin.

Good bye cron job, say hello nagios.

Category: Code, NetAdmin, Puppet, SysAdmin  | Tags: , ,  | Comments off
Thursday, May 20th, 2010 | Author:

eth0Readers of this little blog may know I’ve spent some time to have a munin setup that was tweaked to be optimized. But I’ve reached a point where my knowledge did not suffice to balance the design problems of munin. This is not a rant, I just say that when your infrastructure reaches a certain size munin reaches its limits. The pull based model, the graph generation (don’t tell me about the CGI graph, this thing never worked as expected) overloaded my management box. Talking with other peoples brought collectd to my attention so I gave it a try.

Collectd has many nice features : 10 seconds precision (versus 5 minutes), written in C for performance, multicast support (even if I don’t use it), and you can even create collectd relays. There are some packages for many different targets, even for my OpenWRT based access points ! Configuration can easily be automated (flat files, superior), a mandatory point to me.

Of course collectd comes without an UI but that’s no big deal : there are many around. As I said in the previous post, I use visage.

For the load generated a picture says a thousand words (click to enlarge) :

goodbyemunin

Next step is working on the IO congestion caused by so many RRD updates, collectd wiki has many tips about this, this will probably be fixed in a couple of hours.

Tuesday, May 18th, 2010 | Author:

eth0Some friends told me for a while about collectd, why I should look at it, why munin is so painful and so on. If you’ve been reading my posts you know I have tweaked a little my $WORK munin install to make it faster and lighter. But I finally took time to explore collectd, and I regret to not have done this before. It has so many pros that I decided to implement it in parallel with munin (because I can’t afford being blind on metrics). But collectd comes without an UI : it “only” collectds data, but that’s not a problem. There are various web interfaces and after giving a look to a bunch of them I fell in love with Lindsay Holmwood‘s Visage.

This piece of software is definitely cool : all graphs are rendered live in your browser in SVG. Yes ! Realtime graphs, no need for crappy flash s***, zoom. It is based on sinatra, haml and some JS libraries (I won’t talk about this, my JS foo is deeper than the Mariana Trench). But it lacked some features : it’s OK when you have a few hosts but when the hosts list starts being loooong then the interface needs some improvements. So I forked it on github and implemented (some parts of) what I needed. My github fork has host grouping & per host profiles. Check this out and enjoy Visage !

Now working on sets of graphs :)

PS : <3 Guigui2

Category: BOFH Life, Code, NetAdmin, SysAdmin, Tech  | Tags: , , ,  | Comments off
Monday, July 06th, 2009 | Author:

Il y a des trucs, ça relève du bon sens mais on y pense pas toujours. Dans le monde des sysadmins, il y en a qui militent pour ce qu’on appelle “l’agilité”. C’est en fait appliquer certaines techniques à la base mises en place pour le développement au monde de l’administration système. Personnellement, je trouve que ce sont essentiellement des conseils de bon sens, l’expérience qui parle en somme.

Une de ces “bonnes pratiques” est que le code est la documentation, ce qui évite d’avoir à la réécrire – parce que c’est chiant avouons le – voire même d’oublier de l’écrire, ce qui arrive souvent.

Comme je suis en pleine frénésie puppet-ienne, j’écris des classes à tout va mais pas la doc qui va avec.. et ça PAS BIEN. Je me suis donc lancé dans un petit projet pour documenter mes classes puppet vite fait bien comme une loutre.

Il suffit d’ajouter au dessus de chaque classe (ou en dessous ou peu importe, le code est crade et ne fait pas la différence) des commentaires formattés comme suit :

# @name : debian
# @desc : classe de base pour debian
# @info : ne pas affecter, sera incluse automatiquement

Pour que le script sorte les données dans un tableau façon dokuwiki en 3 colonnes.

Le script va ensuite poster les infos dans le dokuwiki via XML-RPC dans la page indiquée par le script. Tout ce que contient la page sera écrasé, ce n’est pas de l'”append”.

Personnellement je conjugue ce script avec le plugin “include” de dokuwiki. J’ai donc la syntaxe suivante dans une des pages de mon wiki :

{{page>:auto_puppetclasses}}

Le XML-RPC est désactivé par défaut dans dokuwiki, pour l’activer ajoutez dans conf/local.php

$conf['xmlrpc'] = 1;

Et enfin, le script en ruby avec des bouts de XML-RPC dedans (dispo dans le package libruby sous debian). Warning, code sale.

#!/usr/bin/env ruby
#
# Automagicaly adds puppet classes in the dokuwiki corporate documentation
# For use with the "include" plugin
# By nico <nico@gcu.info>
 
require 'xmlrpc/client'
 
xmlrpc_url = "http://XXXXX/wiki/lib/exe/xmlrpc.php"
basedirs = [ "/home/nico/sysadmin/puppet/manifests/classes", "/home/nico/sysadmin/puppet/manifests/os"]
destination_page = "auto_puppetclasses"
 
server = XMLRPC::Client.new2(xmlrpc_url)
 
def doku_class(classfile, final_page)
	fp=File.open(classfile)
	fp.readlines().each { |line|
 
		line=line.gsub("n","")
 
		if line =~ /@name/
			final_page += "| " + line[10,line.length]
		end
 
		if line =~ /@desc/
			final_page += " | " + line[10,line.length] + " | "
		end
 
		if line =~ /@info/
			final_page += line[10,line.length] + " |n"
		end
	}
 
	return final_page
end
 
final_page=""
 
# output some dokuwiki thing
final_page += "===== Classes disponibles =====n"
final_page +=  "n"
final_page +=  "^ Nom de la classe ^ Description rapide ^ Infos supplémentaires ^n"
 
basedirs.each{ |basedir|
	Dir.new(basedir).entries.each { |entry|
		if File.file? basedir+"/"+entry then
			final_page=doku_class(basedir+"/"+entry,final_page)
		end
	}
}
 
server.call2("wiki.putPage", destination_page, final_page, "", 0)
Monday, February 16th, 2009 | Author:

J’ai eu à changer récemment des paramètres sur de nombreux switches cisco. Plutot que d’y  passer ma matinée, j’ai utilisé crisco et ça ne m’a pris que 30 minutes. Petite astuce : pour enchainer facilement des commandes mettez tout dans une seule variable / ligne et parsemez de “\n”, la lib aura moins de mal.

Tuesday, September 16th, 2008 | Author:

Contexte : je l’ai déjà dit mais je gère quelques asterisk au boulot, j’aime bien utiliser la même technologie (à savoir SNMP) pour monitorer toutes mes machines. Mais on ne peut pas dire qu’asterisk soit un grand communiquant : parler avec le monde extérieur, c’est un peu dur pour lui, il est limite autiste là dessus.

J’ai donc écrit (en python, pas très très propre, doit y avoir moyen de mieux faire mais je suis pas un gourou) un petit pour étendre SNMPd et ainsi avoir des infos sur asterisk via SNMP.

Il permet de récupérer les infos suivantes :

  • Nombre de channels actifs
  • Nombre d’appels en cours
  • Uptime (en jour)
  • Nombre de peers SIP (total / online)
  • Nombre de peers IAX (total / online / offline / unmonitored)

Pour ajouter les “capacités” de ce script à SNMPd c’est simple, il faut insérer à la fin de snmpd.conf les lignes suivantes :

exec 1.3.6.1.4.1.29726.3.1.1. channels /opt/scripts/snmp_asterisk.py 1.1
exec 1.3.6.1.4.1.29726.3.1.2. calls /opt/scripts/snmp_asterisk.py 1.2
exec 1.3.6.1.4.1.29726.3.1.3. uptime /opt/scripts/snmp_asterisk.py 1.3
exec 1.3.6.1.4.1.29726.3.2.1. total_sip /opt/scripts/snmp_asterisk.py 2.1
exec 1.3.6.1.4.1.29726.3.2.2. online_sip /opt/scripts/snmp_asterisk.py 2.2
exec 1.3.6.1.4.1.29726.3.2.3. total_iax /opt/scripts/snmp_asterisk.py 2.3
exec 1.3.6.1.4.1.29726.3.2.4. online_iax /opt/scripts/snmp_asterisk.py 2.4
exec 1.3.6.1.4.1.29726.3.2.5. offline_iax /opt/scripts/snmp_asterisk.py 2.5
exec 1.3.6.1.4.1.29726.3.2.6. unmonitored_iax /opt/scripts/snmp_asterisk.py 2.6

Le fichier est ici.

Have fun !

Saturday, September 22nd, 2007 | Author:

En tant que {sys,net}admin junior, j’ai encore plein de trucs à apprendre. Et pour ça j’aime bien lire des livres. Rien ne remplace la pratique mais quand ceux qui ont 15 ans de pratique partagent leur expérience et leurs “best practices” c’est quand même plus sympa.

# 1 : gérer son temps

Time management for system administrator

# 2 : best practices

tposana

# 3 : un peu de réseau

network warrior

Les 2 premiers sont du même auteur : Thomas Limoncelli. Ils sont faciles à lire, très abordables et restent généralistes : ils ne se spécialisent pas sur tel ou tel OS. Le second est clairement tourné vers le matériel Cisco (tous les exemples sont destinés à IOS). Seule la partie “network design” est indépendante (heureusement).

3 bons bouqins qui traitent de sujets vastes, sans tomber dans trop de simplicité ou de superficialité.

Category: Books, NetAdmin, SysAdmin  | 70 Comments