Sylvestre's blog

Still boring to manage proprietary drivers with a Linux Kernel... Each time I want to update my kernel, I have to reinstall the ATI (ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]) and WIFI (Intel Corp. PRO/Wireless LAN 2100 3B Mini PCI Adapter) drivers ...

So, I write down a quick procedure for a lazy copy/paste the next time.
Procedure for GNU/Linux with gcc 3.3 / kernel 2.6.13 / Ati Drivers fglrx 8.16.20 for X.org / ipw2100 1.1.0 / Alien 8.56 (RPM to .deb)
ATI drivers :

wget http://dlmdownloads.ati.com/drivers/linux/fglrx_6_8_0-8.19.10-1.i386.rpm

alien fglrx_6_8_0-8.19.10-1.i386.rpm
dpkg --force-overwrite -i fglrx-6-8-0_8.19.10-2_i386.deb
cd /lib/modules/fglrx/build_mod
chmod +x ./make.sh && ./make.sh
cd ..
chmod +x ./make_install.sh && ./make_install.sh

Wifi Card :

wget http://switch.dl.sourceforge.net/sourceforge/ipw2100/ipw2100-1.1.0.tgz
tar zxvf ipw2100-1.1.0.tgz
cd ipw2100-1.1.0
wget http://www.bughost.org/bugzilla/attachment.cgi?id=429
mv attachment.cgi\?id\=429 compilation_fix
patch < compilation_fix
make
make install

And the /etc/modules should have (the order does matter) :

agpgart
agp_ati
fglrx
i8k force=1
ipw2100

Edit : Comments are closed. Thank you spammers

J'administre le serveur sur lequel tourne mon blog. Il héberge pas mal de sites. Aucun ne générant des trafics délirant mais des sites de trafic moyen.
En autre sur ce blog, c'est entre 400 et 1200 connexions par jour. Il y a aussi quelques autres blogs qui générent entre 200 et 500 connexions par jour. Bref, rien d'énorme. Ceci dit, dans ces chiffres se cachent les robots des Spammeurs qui viennent pourrir les commentaires, les référents et les trackballs. Les robots vont simuler les interventions humaines. C'est-à-dire qu'ils vont consulter les pages HTML et mettre le texte et valider les formulaires. Bien sur, pour chaque page générée pour un robot, le serveur doit parser et traiter les pages PHP, lancer les requêtes SQL, etc d'où une surcharge du serveur inutile.

Suite au commentaire de Ralphy, j'ai testé une fonction (BlockUntrustedVisitors() qui en plus a le bon gout de ne pas être limité à b2evolution) qui se rajoute dans le code de b2evolution. Celle-ci se charge de refuser l'accès au site dès la connexion (c'est-à-dire avant le gros du traitement PHP) les robots hébergés sur des IPs connues comme étant détournées (essentiellement des PC sous Windows bourrés de Spywares).

Bref, j'ai donc rajouté cette fonction et j'ai été très surpris de voir l'impact évident que ça a eu sur le serveur.
Ce graphe (généré par MRTG à partir d'un script qui utilise le programme sar fourni par sysstat) montre l'utilisation processeur avant l'ajout de la fonction et après (vers 7 heure du matin).

Utilisation CPU avant et après l'ajout de la fonction

On voit facilement une diminution de plus de moitié de l'utilisation processeur (25 % d'utilisation à 8/9 %, les piques étant le programme de génération des stats - donc rien à voir) alors que le traitement SQL n'est même pas réalisé sur ce serveur mais sur un autre en LAN.

Par là, je ne veux pas montrer que b2evolution est lent, ça n'est pas le point. C'est surtout pour montrer l'impact économique que le SPAM a actuellement sur Internet car pour être capable de gérer cet utilisation anormale, il faut mettre à jour les serveurs ou en rajouter ... (la modification du code n'étant pas toujours possible). J'en fait déjà fait la désagrable expérience avec les serveurs mail tous les jours depuis des années mais je n'avais pas réalisé qu'elle touchait tant les serveurs web ...

J'avais écris un petit truc pour expliquer comment forcer debian à utiliser des packages spécifiques. Mais comme Gui ne tagge (release) plus ses packages , j'ai du changer les informations dans /etc/apt/preferences pour :

# En global
Package: *
Pin: origin packages.dotdeb.org
Pin-Priority: 990

# Pour un package spécifique
Package: php4
Pin: origin packages.dotdeb.org
Pin-Priority: 990

Package: php4-common
Pin: origin packages.dotdeb.org
Pin-Priority: 990

Package: libapache-mod-php4
Pin: origin packages.dotdeb.org
Pin-Priority: 990
[...]

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 !