Il est possible d’obtenir un graphe du nombre de sessions actives Freeradius avec un simple script shell si les données d’accounting sont stockées dans une base SQL.
Voici un exemple pour Mysql qui peut s’adapter très facilement à d’autres bases comme Oracle ou PostgreSQL. Consultez la liste complète des bases de données supportées par Freeradius.
#!/bin/bash
SQL_USERNAME=utilisateur_radius
SQL_DATABASE=radius
SQL_PASSWORD=mot_de_passe
SQL_SERVER=127.0.0.1
SQL_ACCOUNTING_TABLE=radacct
BACK_DAYS=5
SESSIONS=`mysql -BN \
-u$SQL_USERNAME \
-p$SQL_PASSWORD \
-h $SQL_SERVER $SQL_DATABASE \
-e \
"SELECT COUNT(*) FROM $SQL_ACCOUNTING_TABLE \
WHERE acctstoptime IS NULL \
AND Acctstarttime > NOW() - INTERVAL $BACK_DAYS DAY;"`
echo $SESSIONS
Il reste toujours un certain nombre de sessions non terminées en base à cause de pertes ou de déconnexions réseau entre le NAS et le serveur Radius. C’est pourquoi les sessions datant de plus de $BACK_DAYS sont ignorées pour retourner la valeur la plus précise possible.
Ce script retourne le nombre de sessions actives. Il est ensuite possible de créer un graphe de cette valeur unique avec MRTG qui en demande normalement deux.
Proposez également à tous vos utilisateurs des graphiques d’upload/download de leur consommation réseau Internet.
Après avoir paramétré un VPN entre deux Cisco PIX, il faut passer du traffic d’un réseau à l’autre pour que la connexion s’initialise et s’établisse. Cela peut être génant si l’on veut s’assurer que la connexion soit bien active avant que le réseau interne ne soit connecté.
Prenons l’exemple de 2 sous-réseaux 192.168.2.0/24 et 192.168.3.0/24.
Une fois les connexions VPN configurées sur les PIX, assurez-vous d’avoir ceci:
Sur PIX1:
PIX1#show run
access-list VPN_VERS_PIX2 permit ip 192.168.2.0 255.255.255.0 192.168.3.0 255.255.255.0
...
ip address inside 192.168.2.1 255.255.255.0
...
management-access inside
Idem sur PIX2, sauf pour l’adresse IP évidemment.
Management-access autorise le PIX à renvoyer le ping recu sur son interface interne.
Pour activer la connexion VPN, il suffit de pinger l’interface interne du Cisco distant depuis l’interface interne locale.
PIX1#ping inside 192.168.3.1
192.168.3.1 response received -- 60ms
192.168.3.1 response received -- 50ms
192.168.3.1 response received -- 50ms
Vérifions que le VPN est bien créé:
PIX1# show crypto isakmp sa
Total : 1
Embryonic : 0
dst src state pending created
PIX2_IP PIX1_IP QM_IDLE 0 2
Les ressources CPU et memoire des AS400 peuvent être récupérées avec le protocole SNMP si le service a été activé. Les valeurs ne sont pas directement exploitable et doivent être retravaillées avant d’être affichées. Toutes ces commandes sont exécutées depuis un serveur Linux. Vérifiez sur votre distribution Linux pour installer snmpwalk qui doit très certainement fournir un package.
Données CPU
Il est préconisé d’extraire le CPU d’un IBM i avec l’OID SNMP .1.3.6.1.4.1.2.6.4.5.1.0 qui retourne une valeur sur 10000. Il faut donc la diviser par 100 pour l’obtenir en pourcentage. Le 2me inconvénient est que seule la valeur entière est retournée. Elle est de ce fait erronée, puisqu’arrondie à la valeur inférieure. L’OID HOST-RESOURCES-MIB::hrProcessorLoad.2 sur un i5 520 retourne directement cette valeur en pourcentage.
Premièrement, MaxBytes, représentant la quantité max de mémoire, peut s’obtenir via snmpwalk (en KB) auquel on applique quelques changements: expr `snmpwalk -v1 -c $COMMUNITY $IP hrMemorySize.0 | awk ‘{ print $(NF-1) }’` \* 1024
Et voici un script shell qui calcule la RAM utilisée à partir des valeurs SNMP. On ne peut pas l’obtenir directement comme vous pouvez le constater:
La configuration MRTG exploitant ces valeurs ressemble à ceci. Elle permet de générer le graphique ci-dessus. Ces valeurs peuvent bien sûr être utilisées par tout autre outil de surveillance comme Zabbix ou Cacti par exemple.
# La méthode classique affichant 2 fois la même valeur
# Target[AS400.cpu]:.1.3.6.1.2.1.25.3.3.1.2.2&.1.3.6.1.2.1.25.3.3.1.2.2:COMMUNITY@IP
# Ou via le script comme décrit ici
Target[AS400.cpu]:`/home/mrtg/get-as400-cpu.sh IP COMMUNITY 1`
RouterUptime[AS400.cpu]: COMMUNITY@IP
MaxBytes[AS400.cpu]: 100
Title[AS400.cpu]: Charge CPU AS400
PageTop[AS400.cpu]: <H1>Charge CPU AS400</H1>
Unscaled[AS400.cpu]: ymwd
ShortLegend[AS400.cpu]: %
YLegend[AS400.cpu]: Utilisation CPU
Legend1[AS400.cpu]: Charge CPU active
LegendI[AS400.cpu]: CPU
Options[AS400.cpu]: growright,nopercent,gauge
Colours[AS400.cpu]: RED#e13c13,RED#e13c13,RED#e13c13,RED#e13c13
# De même pour l'utilisation mémoire
Target[AS400.mem]:`/home/mrtg/get-as400-memory.sh IP COMMUNITY 1`
RouterUptime[AS400.mem]: COMMUNITY@IP
MaxBytes[AS400.mem]: 12129927168
Title[AS400.mem]: Utilisation mémoire AS400
PageTop[AS400.mem]: <H1>Utilisation mémoire AS400</H1>
Unscaled[AS400.mem]: ymwd
YLegend[AS400.mem]: Utilisation mémoire
Legend1[AS400.mem]: Utilisation mémoire
LegendI[AS400.mem]: mémoire
Options[AS400.mem]: growright,nopercent,gauge
Colours[AS400.mem]: ORANGE#F88017,ORANGE#F88017,ORANGE#F88017,ORANGE#F88017
MRTG a besoin d’au moins 2 valeurs pour générer des graphiques. Ainsi, la plupart des configurations contiennent deux fois la même OID sur la ligne target.
Ceci pose 2 problèmes différents:
– La même donnée est collectée deux fois, ce qui nécessite plus de bande passante, surtout quand un nombre important de hosts est supervisé
– La valeur peut varier pendant ce temps très court, produisant 2 lignes différentes sur le graphe. c’est le cas pour le CPU des AS400 par exemple.
Pour grapher seulement une valeur telle que le CPU ou l’utilisation mémoire, vous pouvez écrire un petit script qui collecte la donnée SNMP:
Les cartes graphiques ne sont pas toujours reconnues par Linux, ce qui pose problème puisque de nombreuses distributions ne s’installent plus qu’en mode graphique, que ce soit Ubuntu, Fedora ou Debian.
C’est le cas de mon Packard Bell Easynote E6100 et de sa carte Via Unichrome qui se gèle dès l’entrée en mode graphique.
Une solution est de réaliser l’installation en mode texte. Xubuntu 8.10 alternate donne cette flexibilité et propose Xfce, un environement de bureau très léger, idéal pour un portable.
Configuration du driver générique
Au premier démarrage, on obtient toujours un plantage de la session X.
La seule option est de redémarrer en mode recovery, puis sélectionner « Drop to root shell prompt ». Enfin, remplacer /etc/X11/xorg.conf par celui-ci, qui fait appel au driver générique Vesa:
Ce driver étant générique, il est préférable d’utiliser celui adapté à sa carte graphique pour bénéficier de toutes ses capacités. En attendant, cela permet une utilisation du système en mode graphique.
