Category Archives: Pense bête

Changer le répertoire de mysql sous debian wheezy

Voici un petit script avec quelques explications pour changer le répertoire de mysql (datadir) sous debian wheezy.

Explications :

La ligne permettant de changer le répertoire des données de mysql est la ligne contenant datadir dans le fichier /etc/mysql/my.cnf

datadir  = /app/mysql

Une fois cette ligne modifiée, il faut réinstaller la base de données. Redémarrer simplement mysql ne fonctionne pas. La commande mysql_install_db est prévue à cet effet. Elle crée les fichiers et dossiers nécessaires dans le nouveau répertoire.

Après cela, le redémarrage de mysql fonctionnera. Cependant, un message d’erreur apparaitra. La réinstallation de la base n’a pas conservé l’utilisateur dédié à la maintenance

Message d’erreur au lancement de mysql

ERROR 1045 (28000): Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)

La solution consiste à créer l’utilisateur demandé en récupérant le mot de passe dans le fichier /etc/mysql/debian.cnf

Script shell :

#!/bin/bash
/etc/init.d/mysql stop
# Install database in directory configured in my.cnf
mysql_install_db
# Restart mysql
/etc/init.d/mysql start
#Get password from config file
MYSQL_PWD_DEBIAN=`grep password /etc/mysql/debian.cnf | cut -d= -f2 | head -n 1 | tr -d ' '`
echo "Password for debian-sys-maint = $MYSQL_PWD_DEBIAN"
# Create debian user
mysql -u root -e "GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY '$MYSQL_PWD_DEBIAN';"

Sudo et le path

Problème : L’exécution d’une commande par son simple nom via sudo peut parfois provoquer l’erreur suivante : command not found. Cela se produit quand l’éxécutable n’est pas dans le path « standard »

Cas concret : Grâce à l’enrichissement de son path dans le fichier ~/.bashrc, l’utilisateur jerep6 peut exécuter des scripts de situant dans le dossier /home/jerep6/bin/.

PATH=$PATH:$HOME/bin

Exemple :

$ mon_script1 10 50
somme=60

Si l’utilisateur souhaite exécuter ce même script avec sudo, il devra saisir le chemin absolu ou relatif d’accès au fichier.

$ sudo mon_script1 10 50
[sudo] password for jerep6:
sudo: mon_script1: command not found

$ sudo bin/mon_script1 10 50
bin/mon_script1: line 79: mon_script2.sh: command not found

En indiquant le chemin, le script « mon_script1 » est bien exécuté, mais produit une erreur car il appelle « mon_script2 » qui lui n’est pas trouvé. J’ai en effet utilisé le nom de la commande qui est supposée être dans le path.

Explications :
Sudo n’utilise pas le path de l’utilisateur mais son propre path qui ne contient pas /home/jerep6/bin/

Sur debian squeeze, sudo est compilé avec le flag –with-secure-path. Ainsi lorsque l’utilisateur exécute une commande avec sudo, le path pris en compte est le secure-path :
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin

Il est possible de le redéfinir en renseignant le fichier /etc/sudoers via la commande visudo :

Defaults        secure_path=/usr/bin

Il existe plusieurs possibilités pour manipuler le path de sudo. Voici celles que j’ai testées :

  1. Désactiver le secure_path. Le path sera celui de l’utilisateur. Cela peut toutefois poser des problèmes si les commandes présentes dans le script ne sont pas dans le path de ce dernier mais dans celui de root (/sbin par exemple).
  2. Modifier le secure_path. Le secure path permet d’avoir un PATH « propre » pour exécuter les applications nécessitant les droits d’administration.
  3. Jouer avec exempt_group. Tous les utilisateurs du groupe spécifié seront déchargés de la saisie du mot de passe et du secure_path
  4. Passer l’argument « -i » à sudo. Cela a pour effet de simuler une connexion. Cela signifie que les fichiers .profile, .bashrc ou .login seront lus par le shell. Les variables DISPLAY et TERM ne sont pas modifiée. En revanche, HOME, MAIL, SHELL, USER, LOGNAME et PATH sont positionnées. Le path est donc celui de l’utilisateur root et pas celui de secure_path
  5. Passer l’argument « -s » provequera l’exécution de /root/.bashrc (idem que -i) mais pas le profile. Le path sera celui de secure_path. Il est donc possible d’enrichir le secure_path dans le .bashrc

Connaitre le path utilisé par sudo :

sudo sh -c 'echo $PATH'
→ path de sudo

La commande précédente donne donne le path de sudo tandis que la suivante renvoie celui de l’utilisateur car le shell évalue (expands) la variable $PATH avant que sudo ne soit exécuté.

sudo echo $PATH
→ path de l'utilisateur et non celui de sudo

Copier une liste de fichiers

 

Exemples tirés de superuser.com

Version xargs

xargs -a list.txt cp -t new_folder
xargs --arg-file=list.txt cp --target-directory=new_folder

Version shell

Bash :

for file in $(<list.txt); do cp "$file" new_folder; done
cp $(<list.txt) new_folder

sh :

while read -r line; do for file in $line; do cp "$file" new_folder; done; done < list.txt

PPPOx et IPOx

Post de Vivien sur le forum http://lafibre.info

 

Le retour du combat de PPPoA / PPPoE vs IPoA / IPoE 

Certains s’étonnent que des abonnements à fibre optique utilisent le PPPoE (ou le PPPoA) comme par exemple l’offre fibre d’Orange.

François Contat fait le point entre l’IPoX (l’attribution d’IP serait directement via un client DHCP, ce qui permet de connecter le media-converter / ou l’ONT directement au PC sans faire de configuration) et le PPPoX qui nécessite un login / password pour établir la connexion.

Les avantages du PPPoX :

  • L’avantage de ce protocole est qu’il est lié à Radius, donc on a un nombre important d’informations sur l’utilisateur à l’instant T : On sait (si on a un accounting cohérent et un système de requêtage intelligent) si un client est connecté, le moment de sa dernière coupure (que ce soit à l’initiative de l’abonné ou celle de l’équipement de collecte). On peut faire des stats de trafic sur les tickets d’acct stop, dégager des comportements utilisateurs etc…
  • La gestion de déménagement d’abonné n’implique pas de changer des informations d’authentification : dans le cas du ppp, il s’agit du login qui fera foi, tandis qu’en DHCP, ce sera l’option 82 qui est lié à l’interface physique du DSLAM, OLT, ou autre qui fera foi. Donc en cas de déménagement, il faut aussi prendre en compte la nouvelle option 82. En cas de déplacement de port etc… la gestion via PPP est beaucoup plus flexible.
  • Le tunneling L2TP qui permet de très facilement concentrer la collecte de certains clients (B2B) sur des LNS dédiés ou autre.

Les inconvénients du PPPoX :

  • En PPPoE : La fragmentation liée à la MTU de 1492
  • Le coût du PPP existe (on l’oublie souvent), car il faut bien collecter les clients pour leur assigner une ip (et un subnet dans le cas d’offre B2B). Il y a donc un coût financier en équipement, maintenance, humain pour gérer ces équipements, dalles etc… Bref ce n’est pas un coût si anodin.
  • La QoS qui est anecdotique sur le PPP. On en parle depuis longtemps mais je n’ai jamais vu un équipement de type LNS faire de la QoS qui marche ou qui lorsqu’elle fonctionne n’écroule pas les performances de la machine (on en revient au coût).

Les avantages de l’IPoX :

  • QoS. La QoS est fonctionnelle, éprouvée et fonctionne chez TOUS les constructeurs d’équipement de collecte de ligne (dslam, olt, etc..), du moins ceux auxquels j’ai pu toucher. Il n’y a rien de sorcier pour la mettre en place contrairement à l’expérimentation PPPoX qui est particulièrement lourde et qui ne fonctionne pas.
  • Le coût. Là où on a des équipements de collecte (BAS, LNS), ici nous n’avons plus rien, juste un switch qui fera relay dhcp. Là où l’on avait des radiusd, on remplace par des dhcpd. La différence de coût est grosse.
  • Le coût au niveau IAD. Côté client, je pense (jamais mené de test à ce propos mais la logique le veut) que les performances de l’équipement s’en ressente : une encapsulation / descapsulation en moins. Et dans le cas de petits paquets arrivant à un débit important, les performances du modem peuvent s’en trouver TRES affecté. J’ai mené des stress test sur un certain nombre d’équipementiers modem et il est très facile de tuer un modem avec un « bon » débit en upstream et des paquets bien dimensionnés => la cpu de ce dernier atteint très vite les 100% CPU

Les inconvénients de l’IPoX :

  • Aucune notion de fin de session. On a aucune information sur l’utilisateur et son état et ne récupérons pas d’informations sur sa connexion contrairement au Radius. Ce point peut sembler anodin, il n’en est rien. Une hotline a besoin de savoir à l’instant X si un client est connecté (et non ping n’est pas une réponse) : Un port de dslam peut être marqué up mais ce n’est pas pour autant que le client fonctionne. On a déjà vu des cartes de dslam en carafe qui refusent de laisser passer un paquet tout en restant up. Le ping n’est pas une solution car un certain nombre de gens bloquent le ping. Ce point de notion de session est le plus sensible à mon sens. Pour avoir une info de début de session en dhcp, il suffit d’avoir un parser de log afin d’avoir ces informations. Le point négatif du DHCP est qu’il n’y a pas d’ACCT STOP.

Find

Supprimer les dossiers svn dans les sous répertoires

find . -name ".svn" -exec rm -r '{}' \;

Exemple iproute2

Ayant installé Archlinux et étant donné que le paquet net-tools est déprécié voici quelques exemples d’utilisation de la commande ip :

Exemple ip addr & ip link

Voir les interfaces :

ip addr
ip link show

ip addr show eth0
ip link show eth0

Assigner une adresse IP :

ifconfig eth0 192.168.1.5 netmask 255.255.255.0
ip addr add dev eth0 local 192.168.1.5/24

Supprimer l’adresse IP :

ifconfig eth0 default
ip address del 192.168.1.5/24 dev eth0

RAZ interface  :

ip addr flush eth0
ip -f inet addr del dev eth0

La dernière commande supprime toutes les IPs v4 (inet) de eth0

Up /down interface :

ifconfig eth0 up
ip link set dev eth0 up

ifconfig eth0 down
ip link set dev eth0 down

Documentation

http://linux-ip.net/html/tools-ip-address.html

http://linux-ip.net/html/tools-ip-link.html