Archives par mot-clé : console

Tester sa vitesse de connexion Internet depuis le terminal

Publié le par

speedtest-cli permet de tester sa vitesse de connexion sans utiliser de navigateur, et sans les problèmes liés au flash nécessaire pour utiliser les sites de test. C’est un outil écrit en python fonctionnant sur Debian et dérivées, ainsi que sur Fedora et dérivées.

Pour l’installer, il vous faudra python-pip et lancer la commande suivante:

sudo pip install speedtest-cli

Ensuite, il suffit de lancer speedtest-cli pour avoir une idée du débit descendant et ascendant de votre ligne. Les valeurs obtenue sur la mienne sont variables (dépend de l’utilisation de la ligne, du PC, de l’heure) mais restent dans une fourchette qui permet de voir quel est le débit moyen.


usage: speedtest-cli [-h] [--bytes] [--share] [--simple] [--list]
[--server SERVER] [--mini MINI] [--source SOURCE]
[--timeout TIMEOUT] [--version]
Command line interface for testing internet bandwidth using speedtest.net.
--------------------------------------------------------------------------
https://github.com/sivel/speedtest-cli
optional arguments:
-h, --help show this help message and exit
--bytes Display values in bytes instead of bits. Does not affect
the image generated by --share
--share Generate and provide a URL to the speedtest.net share
results image
--simple Suppress verbose output, only show basic information
--list Display a list of speedtest.net servers sorted by
distance
--server SERVER Specify a server ID to test against
--mini MINI URL of the Speedtest Mini server
--source SOURCE Source IP address to bind to
--timeout TIMEOUT HTTP timeout in seconds. Default 10
--version Show the version number and exit

Résultat chez moi
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Free SAS (78.207.166.41)...
Selecting best server based on latency...
Hosted by Altanetica SL (Calonge) [80.18 km]: 188.878 ms
Testing download speed........................................
Download: 7.35 Mbit/s
Testing upload speed..................................................
Upload: 0.99 Mbit/s

Si vous utilisez l’option –share, vous obtiendrez l’adresse d’une image, montrant les résultats, que vous pourrez partager.

Pour faire la mise à jour, utilisez:

sudo pip install speedtest-cli --upgrade

[Memo] Supprimer une règle Iptables

Publié le par

Lister les règles avec un numéro de ligne :
iptables -L INPUT -n --line-numbers

Supprimer une ligne particulière (avec le numéro de la colonne de gauche) :
iptables -D INPUT numeroDeLaLigneASupprimer

 

Source: http://nicolasolivero.wordpress.com/2010/01/24/supprimer-une-regle-iptables/

rsync par Cron: permission denied

Publié le par

J’ai été confronté à un étrange problème sur certaines machines en Ubuntu 12.04 (precise) pour lequel je vous livre ma solution de contournement. Ce n’est pas transcendant, mais ça fonctionne en attendant d’en savoir plus ou de trouver une autre solution.An_rsync_Primer

S.O.S.s.h.

J’ai des dossiers que je synchronise avec ou depuis un serveur distant en utilisant rsync, principalement pour faire des sauvegardes. Ces commandes rsync sont intégrées dans des scripts que j’utilise depuis plusieurs années sans problème. Pour pouvoir éviter les problèmes de droits, ces scripts sont lancés par le cron du root.
La commande qui nous intéresse est de cette forme:
rsync -avP dossier/local manu@serveur:/dossier/distant/ > /tmp/monlog.log 2>&1

Et le root peut se connecter au serveur sans mot de passe par échange de clef ssh.

Or, depuis quelques temps, impossible de faire la sauvegarde. Les logs contiennent quelque chose comme ceci:

Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]

Alors que lorsque le programme est lancé en root depuis un terminal, il fonctionne sans erreur! (Donc pas de problème de droits d’accès aux dossiers/fichiers)

Environnement variable ou Variables d’environnement

Le cron n’ouvre pas un véritable shell lorsqu’il lance une action programmée, et les variables d’environnement utilisées dans une console ne sont pas toutes présentes. C’est peut être l’une des raisons du problème.

Sur certains forums, on a parlé de SSH_AUTH_SOCK et de SSH_AGENT_PID, mais je n’ai pas réussi à les faire prendre en compte pour résoudre le problème…

Où est la clef?

Qu’importe, indiquons à ssh qu’on veut utiliser la clef qui nous permet de s’identifier sur le serveur

rsync -avP -e "ssh -l root -i /root/.ssh/id_rsa" dossier/local manu@serveur:/dossier/distant/ > /tmp/monlog.log 2>&1

Et? Pas mieux, toujours rejeté par le serveur…

Qui me parle ?

Comme les logs du serveur n’indiquaient pas d’informations utiles, il faut demander à rsync d’être plus bavard

rsync -avvvv -e "ssh -l root -i /root/.ssh/id_rsa" dossier/local manu@serveur:/dossier/distant/  > /tmp/monlog.log 2>&1

Du coup, ça donne quelques indications dans le log:

opening connection using: ssh -l root -i /root/.ssh/id_rsa -l manu serveur rsync --server -vvvvue.Lsf . /dossier/distant/
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).

Ahhhh! Pourquoi il me met un -l manu alors que je lui ai spécifié -l root ?
Eh bien je ne sais pas, mais c’est la source du problème: identifié en tant que manu, il ne peut donc plus accéder à la clef ssh du root.

Comme je suis vicieux et mauvais perdant, j’ai essayé d’accéder à la clef de manu:

rsync -avvvv -e "ssh -l root -i /home/manu/.ssh/id_rsa" dossier/local manu@serveur:/dossier/distant/  > /tmp/monlog.log 2>&1

Et ça marche! Parce que le root peut entrer partout et lire les clefs de tous les utilisateurs (et surtout parce que manu aussi peut s’identifier en ssh sur le serveur sans mot de passe)

Et les droits d’accès aux dossiers ? Pas de problème, c’est toujours root (par l’intermédiaire du cron) qui lit les fichiers, mais il n’utilise pas sa propre clef et se fait passer pour manu dans le rsync.

Carpe diem

Pour résumer:

  • Plein de personnes ont rencontré le même problème, mais aucune solution proposée n’a fonctionné pour moi
  • Tout se passe comme si rsync refusait d’utiliser la clef du root
  • On peut utiliser la clef de n’import quel utilisateur, tant qu’il peut accéder au serveur. Au besoin, créer un utilisateur dédié.
  • C’est pénible, il faut que je modifie mes scripts qui me permettaient d’unifier la méthodologie
  • Bug ou pas bug ? Je ne sais pas.
  • Résolu? Je ne suis pas sûr. J’aimerai comprendre pourquoi sur certaines installations ça fonctionne, et pas sur d’autres, d’autant que j’essaye d’avoir des configurations logicielles le plus identiques possibles pour en simplifier la gestion.

En tous cas, si vous avez des infos sur ce changement de comportement, ou sur le moyen de fonctionner à l’ancienne mode, n’hésitez pas à laisser une bafouille.

Ubuntu: system halted ou le poste ne s’éteint pas

Publié le par

L’ordinateur ne s’éteint pas

J'ai dit halte!
Depuis ubuntu 11.04 ((il me semble)), un problème récurent se produit: lors d’une demande d’arrêt, le poste reste sous tension et un message indique laconiquement:

*Will now halt
[...] System halted

C’est d’autant plus embêtant que parfois la commande entrée manuellement dans un terminal fonctionne sans provoquer ce problème, mais que dans un script ou avec certains logiciels, le système ne se coupe pas. Et si le système n’est pas coupé, impossible de démarrer les postes par wake on lan!

J’avais écrit à ce sujet en donnant une solution de contournement qui ne fonctionnais pas systématiquement non plus…

A noter que ce problème apparait lors d’une mise à jour ou d’une installation neuve, quelle que soit la distribution basée sur ubuntu (voyager, mint, Xubuntu, …)

Je suis tombé sur l’explication de Steve Langasek (vorlon) sur bugs.launchpad qui éclaire ce problème:

Ok, j’ai travaillé à ma façon sur toutes les formes de ce bug maintenant, et je dois conclure que ce comportement ne peut pas / ne devrait pas changer.

– La commande «shutdown» a trois options: « -h » (arrêt ou mise hors tension), ‘-H’ (arrêt), et «-p» (hors tension).
– La commande «halt» fait référence à -H,  par défaut.
– La commande «poweroff» fait référence à -p, par conception.
– La configuration de /etc/default/halt affecte *uniquement* le comportement lorsque ni -H ni -P n’a été spécifié.
– Il n’y a pas moyen de faire «halt» correspondre par lui-même à «poweroff», sans qu’il soit impossible de faire un véritable «arrêt».
– Ce sont toutes des options standard qui ne devraient pas être changé.

Donc, je ferme ce rapport de bug comme «wontfix». Le comportement actuel est incompatible avec le comportement arriviste précédent, mais ce comportement était bogué. Le comportement actuel est correct, et je crains que les gens vont juste devoir apprendre que «halt» ne signifie pas ce que vous avez été amené à croire que cela signifie.

Si vous voulez que le système se coupe, vous avez besoin pour fonctionner soit de « shutdown -h now», «halt -p», ou «poweroff». Toutes ces trois commandes fonctionnent. «halt -p» est la plus courte et probablement la plus compatible avec la mémoire musculaire existante.

Même si le ton est un peu hautain à mon goût ((pour les pauvres utilisateurs perturbés que nous sommes, et vraiment nombreux au vu des pages complètes de google à ce sujet)) , il est logique de comprendre que « halt » arrête le système informatique ((ce qu’il fait d’ailleurs très bien comme le prouve le message « system halted »)) et que « poweroff  » coupe l’alimentation matérielle.

Le problème est que pendant des années nous avons appris à utiliser « halt » plutôt que « shutdown -h » ou « poweroff » et qu’il nous semble que ce nouveau comportement est un bug, alors que c’est l’ancien comportement qui était anormal. Il va falloir commencer à changer certaines habitudes…

On peut contourner ce comportement en modifiant les aliases (alias halt= »halt -p ») mais c’est à faire pour tous les utilisateurs et ne fonctionne pas pour les scripts ou programmes qui ne lancent pas un shell.

De plus, sur la 10.04, vous constaterez que « halt » est un lien vers la commande « reboot »… D’autant plus surprenant que « reboot » fonctionne…

Eteindre ubuntu ET l’ordinateur

Note: la solution proposée par chmd dans les commentaires est en effet plus propre et conseillée.

Je me trouve confronté à des logiciels écrits il y a quelques années qui font appel à la commande halt et à qui je peux difficilement expliquer ((pour diverses raisons…)) que c’est une mauvais habitude, mais une solution de comportement existe en interceptant la commande halt et en la renvoyant vers poweroff

  • renommez la commande halt en autre chose

sudo mv /sbin/halt /sbin/haltorig

  • Créez un programme /sbin/halt qui fera appel à « poweroff » ou « shutdown -h now »

#!/bin/sh
/sbin/poweroff

puis sudo chmod +x /sbin/halt

On retrouve ensuite un comportement « normal » ((le comportement attendu, à savoir une coupure propre, même s’il vaudrait mieux prendre la bonne habitude immédiatement)) du système.

Depuis quelques jours que je teste cette modification, je n’ai remarqué aucun effet de bord, ni graphiquement, ni sur le fonctionnement des autres programmes. À part que c’est un bonheur de pouvoir à nouveau éteindre ses machines par cron ou ssh et de pouvoir les relancer par WOL.

J’ai pensé que vous trouveriez cet article utile ;oD

Equivalent à CHKDSK sous Linux

Publié le par

Il est bien évident qu’à choisir un système de fichier mon choix premier ne se porterait pas sur les formats Microsoft. Cependant, l’interopérabilité fait que le choix ne nous est pas forcément disponible.

Surtout quand on me transmet un disque externe  en me disant « Tiens, voilà la sauvegarde, prends en soin c’est la seule » et que je me rends compte que le système de fichier est dans les choux… ((d’ici à ce qu’on vienne dire que c’est parce que j’ai osé le brancher sur un Linux, il n’y a qu’un pas qui a déjà été franchi depuis longtemps!)).

Sueurs froides, tremblement, méditation et incantations :d plus tard, voici ce que ça donne.

Partitions FAT

Certains appareils (lecteur DVD, décodeur TNT, autoradio ou systèmes propriétaires) n’acceptent que les lecteurs externes au format VFAT. Or, quand il y a des problèmes sur la partition et qu’on veut la corriger, c’est dommage de ne garder un windows que pour ça.

Heureusement, le paquet dosfstools possède la commande dosfsck qui permet de le faire:

sudo dosfsck -a -t -w /dev/sdc1

Cette commande va nous permettre de vérifier le disque /dev/sdc1 en réparant automatiquement les erreurs sans confirmation (-a), en marquant les mauvais secteurs comme tels (-t) et en le faisant immédiatement (-w). Vous pouvez aussi ajouter les options -n (à la place de -w) pour simplement tester, -l pour afficher la liste des fichiers traités et -v pour avoir plus de sortie à l’écran.

Démontez votre disque sans le retirer avant de lancer la commande, mais dans les cas où je l’ai utilisée, le disque ne montait pas de lui même.

Partitions NTFS

Je n’ai pas trouvé de commande permettant de le faire. Si vous en connaissez une, je suis preneur.

La commande ntfsfix du paquet ntfsprogs permet de faire certaines réparations simples, mais pas une véritable vérification. Comme le dit le man:

ntfsfix est un utilitaire qui permet de résoudre certains problèmes NTFS communs. ntfsfix N’EST PAS une version Linux de chkdsk. Il répare seulement certaines incohérences fondamentales du NTFS, réset le journal NTFS et programme une vérification du système de fichiers au prochain boot de Windows.

Cependant, on peut s’en sortir sans avoir windows installé, simplement avec le CD d’installation (exemple pour XP) ((même si ça pique les yeux, tout ce bleu)):

  • démarrez un ordinateur où le disque est branché depuis le CD d’installation
  • Dans les choix qui vous sont donnés, choisissez R pour réparation
  • Quand vous êtes dans la console de réparation, lancez la commande CHKDSK C: /R. Si un seul disque est présent, vous pouvez omettre de le nommer.

Si vous n’avez pas le CD d’installation de windows, vous pouvez télécharger Revovery Console (RC.iso) fourni par The computer paramedic qui contient des outils de réparation et l’utiliser comme dans la méthode donnée ci dessus. Notez que si vous avez eu un ordinateur sans CD d’installation, il est utile de le télécharger pour l’avoir sous la main, y compris pour réparer le MBR…

Pour Vista et Seven, la méthode est approximativement la même, même si elle n’apporte rien de plus. Démarrez avec votre DVD d’installation et adaptez la méthode à ce qui vous est proposé. Vous pouvez aussi consulter cette page même si l’accès aux consoles de réparation est devenu payant pour des problèmes de licences Microsoft ((Obligé de payer des licences à Microsoft pour permettre de réparer leur système… Comme quoi c’est un business de leur part, pas un bug. Encore un bonnet d’ÂNE mérité.)) depuis Aout 2011.

Désactiver le lancement de GDM sur Lucid

Publié le par

Sur l’une de mes machine, destinée à un usage spécifique dont je parlerais plus tard, j’avais besoin d’avoir une interface graphique pour l’installation et le réglage d’un logiciel particulier.

Mais une fois celui ci configuré, je souhaitais que GDM ne se lance plus, sauf à la demande. J’ai donc installé une version « desktop » puis j’ai cherché à désactiver GDM.

Or, si cela était évident (ou du moins connu) dans les versions précédentes, en supprimant le lien de lancement dans /etc/rc2.d ou avec update-rc.d, avec upstart c’est désormais différent.

Les programmes lancés au démarrage sont situés dans des fichiers de configuration placés dans /etc/init. Celui qui nous intéresse est gdm.conf.

Il faut modifier le fichier de la manière suivante:

de

# gdm - GNOME Display Manager
#
# The display manager service manages the X servers running on the
# system, providing login and auto-login services
 
description    "GNOME Display Manager"
author        "William Jon McCann &lt;<a class="linkification-ext" title="Linkification: mailto:mccann@jhu.edu" href="mailto:mccann@jhu.edu">mccann@jhu.edu</a>&gt;"
 
start on (filesystem
          and started dbus
          and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
          or stopped udevtrigger))
stop on runlevel [016]
 
emits starting-dm
 
env XORGCONFIG=/etc/X11/xorg.conf
...

à

# gdm - GNOME Display Manager
#
# The display manager service manages the X servers running on the
# system, providing login and auto-login services
 
description    "GNOME Display Manager"
author        "William Jon McCann &lt;<a class="linkification-ext" title="Linkification: mailto:mccann@jhu.edu" href="mailto:mccann@jhu.edu">mccann@jhu.edu</a>&gt;"
 
start on []
#start on (filesystem
#          and started dbus
#          and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
#          or stopped udevtrigger))
stop on runlevel [016]
 
emits starting-dm
 
env XORGCONFIG=/etc/X11/xorg.conf
...

Relancer ensuite l’ordinateur, GDM ne se lancera plus au démarrage, et vous pourrez alors vous connecter sur les consoles.

Ce n’est pas une astuce exclusive, mais j’ai perdu assez de temps à chercher la réponse que je le note pour savoir où le retrouver.

Ne vous affolez pas parce que vous serez en mode texte, vous verrez qu’on arrive à faire des choses sympas ensuite.

Par exemple, vous pouvez vous identifier avec votre mot de passe et lancer la commande startx pour lancer votre environnement graphique.

Dans un prochain article, nous verrons qu’il y a mieux…