Sylvestre's blog

Imagine that you are dirty with your DNS server. You make some modifications very often and you are not sure when your DNS server is up, RFC and running. Here is a little script which will automatically test some domains and send emails in case of error.

In order to test domains validity, I use DNSdoctor (http://www.dnsdoctor.org/), a fork from Zonecheck (http://www.afnic.fr/outils/zonecheck), a tool developed to perform verifications on the quality of the configuration (it is mandatory with a .fr to have the domain correctly configured). DNSdoctor exists with a few GUI :
- the web interface - http://demo.dnsdoctor.org/
- a classical application using GTK
- a command line application

Of course, I am using the last one to perform the automatic testing system.

As DNSdoctor has been made using Ruby, I made this script with this language (I don't want to have to install python for this script). It will call the DNSdoctor with the appropriate parameters. If an error is detected, it will send an email associated to the domain in the configuration.

If an error occurs, this kind of email will be sent :

ZONE  : ledru.info.
NS <= : akira.ecranbleu.org. [195.137.249.60]
NS    : radium.meaweb.com. [83.217.68.103]
NS    : trunks.ecranbleu.org. [195.137.249.61]

[> ICMP answer
w> Host doesn't reply to ICMP requests (firewall?)
=> radium.meaweb.com./83.217.68.103
=> akira.ecranbleu.org./195.137.249.60
=> trunks.ecranbleu.org./195.137.249.61

[> UDP connectivity
f> Server doesn't listen/answer on port 53 for UDP protocol
 | Ref: IETF RFC1035 (p.32 4.2. Transport)
 |   The DNS assumes that messages will be transmitted as datagrams or in
 | a byte stream carried by a virtual circuit. While virtual circuits can
 | be used for any DNS activity, datagrams are preferred for queries due
 | to their lower overhead and better performance.
 `----- -- -- - -  -
=> radium.meaweb.com./83.217.68.103

==> FAILURE (and 3 warning(s))

#!/usr/bin/ruby
require 'net/smtp'

###########" Parameters ###############
pathCommand="export LANG=en_EN; /usr/bin/dnsdoctor"
paramCommand="-q -vn,d,x,-c "
logFile="/tmp/massDNS.log"
subject="DNS error"
from="tech@linesurf.com"
testDNS= [
	{'domain'=>'ecranbleu.org',
	'email'=>'email@domain.com'},

	{'domain'=>'ledru.info',
	'email'=>'email@mondomaine.com'}
]

def sendmail(from,to,content)
	# --- Send using class methods
	msg = [ "Subject: Test\n", "\n", content ]
	Net::SMTP.start('localhost') do |server|
		server.sendmail( msg,  from , [ to ] )
	end
end

######### Don't edit under #############

command="#{pathCommand} #{paramCommand} "	
for domain in testDNS
	puts "Processing of #{domain['domain']}"
	commandLine=command + domain['domain']
	system(commandLine +'  > '+ logFile +' 2>&1')
	if ($? != 0) 
		content=""
		IO.foreach(logFile) { |line| content+=line }
		sendmail(from,domain['email'],content)
		puts "Erreur"
	end
	File.delete(logFile)	
end

Edit : comments are closed. Thank you spammer.

I have to compile a big software for work. It is using the opencascade toolkit to develop and compile.
It compiles everything itself (nice but tricky).
However, I don't have too much control on the compilation directives and as it is automatic, it produces sometimes some huge command line to compile one lib (I have a gcc command line of 1300 lines ...). And the kernel refuses a command of that size with a nice :
/usr/bin/g++: Argument list too long. or /usr/bin/g++: Liste d'arguments trop longue. in French

As I don't want to hack Opencascade, the only "clean" solution I found is to recompile the kernel :

Edit the file /usr/src/linux/include/linux/binfmts.h and change the 32 parameter to 64 to increase this limit. : #define MAX_ARG_PAGES 32 And recompile the kernel ... Here is the crappy trick !

Je compile un exemple de client/server SOAP en C++. Et voila le message que me sort g++ :

../../stdsoap2.c:7958: attention : déréférencement du pointeur type-punned brisera les strictes d'aliases

J'adore les traductions de logiciels (libres ou pas). Si c'est pas google/atlavista qui ont traduit ça, l'auteur devrait apprendre le Français (ou se procurer un babelfish - comprenne qui pourra).

Revenu dans le monde de l'informatique.

Je commence ma semaine par regarder les différents outils de profiling. Outils qui servent à indiquer où le système a passé le plus de temps. Par exemple, si on voit que la fonction/méthode est appelée 6 milliard de fois, on se dit que l'optimiser peut être interessant.

J'ai donc regardé un peu ce qui se fait dans le monde libre.
En ressortent principalement deux outils & méthodes :
- la méthode gprof qui consiste à compiler le programme avec une option spécifique (-pg) et à l'exécuter ce qui produira un fichier contenant le graphe des appels de fonctions. - Commence à être déprécié pour le suivant.
- la méthode callgrind/cachegrind (fournie par valgrind) qui lui va fournir un environnement d'execution et regarder tout ce qui se passe (et aussi regarder les fuites de mémoire (memory leaks)).

Lire la suite »