Archives de catégorie : console

Installer symfony sur ubuntu 8.04

Publié le par

Ne pas utiliser apt, la version qu’il installe va générer des erreurs.

PHP Fatal error: Uncaught Error: Call to undefined method Composer\Package\RootPackage::getConfig() in /home/manu/.config/composer/vendor/fxp/composer-asset-plugin/Config/ConfigBuilder.php:111
Stack trace:
#0 /home/manu/.config/composer/vendor/fxp/composer-asset-plugin/Config/ConfigBuilder.php(74): Fxp\Composer\AssetPlugin\Config\ConfigBuilder::getConfigBase(Object(Composer\Composer), Object(Composer\IO\ConsoleIO))
#1 /home/manu/.config/composer/vendor/fxp/composer-asset-plugin/FxpAssetPlugin.php(82): Fxp\Composer\AssetPlugin\Config\ConfigBuilder::build(Object(Composer\Composer), Object(Composer\IO\ConsoleIO))
#2 /usr/share/php/Composer/Plugin/PluginManager.php(215): Fxp\Composer\AssetPlugin\FxpAssetPlugin->activate(Object(Composer\Composer), Object(Composer\IO\ConsoleIO))
#3 /usr/share/php/Composer/Plugin/PluginManager.php(188): Composer\Plugin\PluginManager->addPlugin(Object(Fxp\Composer\AssetPlugin\FxpAssetPlugin))
#4 /usr/share/php/Composer/Plugin/PluginManager.php(240): Composer\Plugin\PluginManager->registerPackage(Obje in /home/manu/.config/composer/vendor/fxp/composer-asset-plugin/Config/ConfigBuilder.php on line 111

Si vous l’avez déjà installée, supprimez la avec

sudo apt-get remove composer

ensuite, tapez la commande suivante dans un terminal:

curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/usr/bin --filename=composer

Et ça fonctionne

[Résoudre] LibreOffice: document verrouillé par utilisateur inconnu

Publié le par

Parfois, avec LibreOffice, vous obtenez le message d’erreur suivant:

Le document ‘xxx.ods’ est verrouillé pour édition par :

Utilisateur inconnu

Ouvrez le document en lecture seule ou ouvrez une copie du document pour l’édition.

Lorsqu’il y a plusieurs utilisateurs susceptibles d’accéder au document, c’est peut être un poste dont les données d’identité n’ont pas été renseignées dans les options de LibreOffice. Il faut donc s’assurer que tous les postes ont ces informations de renseignées pour pouvoir trouver quel utilisateur accède actuellement au document.

Par contre, si vous êtes le seul à accéder à ce document, le problème vient du fait que votre document est sur un partage réseau (SMB, NFS, …), même si vous l’avez monté en local et que LibreOffice active par défaut le verrouillage du fichier. Sauf que, quand vous fermez celui ci, il ne relâche pas le fichier…

Une solution de contournement, mais seulement si vous êtes le seul utilisateur à accéder à ces documents, consiste à modifier le lanceur de LibreOffice afin qu’il n’active plus cette fonction par défaut.

Éditez le fichier (en root ou avec sudo) /usr/bin/soffice et modifiez:

SAL_ENABLE_FILE_LOCKING=1
export SAL_ENABLE_FILE_LOCKING

en

#SAL_ENABLE_FILE_LOCKING=1
#export SAL_ENABLE_FILE_LOCKING

Enregistrez, fermez. Vous pouvez désormais immédiatement ouvrir et enregistrer vos fichiers.

Ce n’est pas une solution officielle, et il y a un risque important de perte de données si plusieurs utilisateurs accèdent simultanément au même fichier, mais elle a le mérite de fonctionner et de débloquer les utilisateurs uniques qui travaillent sur un NAS.

Gardez cette page dans vos favoris, la mise à jour de LibreOffice risque bien de remplacer le fichier modifié et de faire ré-apparaitre le problème.

Résoudre l’erreur de screen « Cannot open your terminal ‘/dev/pts/0’ – please check »

Publié le par

En utilisant screen, il est possible que vous ne puissiez démarrer une session en obtenant l’erreur suivante:
Cannot open your terminal '/dev/pts/0' - please check

C’est parce qu’un autre utilisateur (probablement vous) a lancé le terminal actuel. Vous avez sans doute effectué un sudo su vers l’utilisateur avec lequel vous essayez de lancer screen, n’est ce pas?
Il y a deux manières de corriger ceci:

  • Déconnectez vous et connectez vous proprement avec l’utilisateur que vous souhaitez utiliser
  • Lancez script /dev/null dans le shell de l’utilisateur et relancez screen, ce qui devrait fonctionner.

Important: n’effectuez pas de chmod sur le terminal virtuel comme suggéré sur beaucoup de sites du web. Cela fonctionnera mais donnera aux autres utilisateurs les droits de lecture et d’écriture dans la session du terminal!

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

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

Utiliser wget pour télécharger un site entier

Publié le par

C’est plus un pense bête qu’une astuce, et ça m’évitera de chercher encore une fois.

Pour l’anecdote, j’ai scripté cet usage afin de garder une copie de sauvegarde d’un site hébergé chez le prestataire d’un client qui a des « problèmes » avec celui ci. En cas de…je ne sais pas, mais au cas où, j’ai une copie de sauvegarde permettant une reprise sans avoir à tout recréer de zéro (images, mise en page, css,…). Et j’ai ainsi l’évolution des modifications sur les x derniers jours (une sorte de google cache en local)

Si vous voulez télécharger un site entier, peut être pour le visiter off-line, wget peut le faire . Par exemple:

$ wget \
     --recursive \
     --no-clobber \
     --page-requisites \
     --html-extension \
     --convert-links \
     --restrict-file-names=windows \
     --domains website.org \
     --no-parent \
         www.website.org/tutorials/html/

Cette commande va télécharger le site  www.website.org/tutorials/html/.

Les options sont:

  • –recursive: télécharge le site web entier.
  • –domains website.org: ne suit pas les liens pointant hors du domaine website.org.
  • –no-parent: ne suis pas les liens pointant hors du dossier tutorials/html/.
  • –page-requisites: récupère tous les éléments qui composent la page (images, CSS et cie).
  • –html-extension: enregistre les fichiers avec l’extention .html.
  • –convert-links: convertit les liens afin qu’ils fontionnent localement (off-line).
  • –restrict-file-names=windows: modifie les noms de fichiers afin qu’ils fonctionnent aussi sur Windows.
  • –no-clobber: n’écrase pas les fichiers déjà existants (utilisé en cas de téléchargement interrompu et repris).

Il peut aussi être important d’ajouter les options --wait=9 --limit-rate=10K qui éviteront de surcharger le serveur qui vous fournit les pages et d’éviter, éventuellement, de vous faire blacklister par un admin un peu pointilleux.

  • –wait=X : attend X secondes entre chaque téléchargement
  • –limit-rate=XK : limite la bande passante utilisée à X Ko/s

Utiliser ces options permet plus de souplesse que de simplement utiliser l’option -m (mirror).

Notez que wget existe aussi sous windows.

source: http://www.linuxjournal.com/content/downloading-entire-web-site-wget

Activer XDMCP sur Ubuntu Lucid 10.04

Publié le par

Cette astuce fonctionne peut être avec les versions suivantes, mais je ne l’ai pas testée. A confirmer.

Si vous avez besoin d’utiliser XDMCP sur votre réseau, vous constaterez qu’avec la « nouvelle » version de GDM, il n’est plus possible de l’activer facilement ((en tout cas, pas aussi facilement qu’avant)).

Or, il suffit de quelques manipulations pour la remettre en place.

Paramétrer le serveur XDMCP

Tout d’abord, il faut créer le fichier /etc/gdm/custom.conf qui va enregistrer les options de GDM, et en particulier celles concernant XDMCP.

Remplissez le avec ceci:

[daemon]
 User=gdm
 Group=gdm
[security]
 DisallowTCP=true
[xdmcp]
 Enable=true
 DisplaysPerHost=2
 HonorIndirect=false
 MaxPending=4
 MaxSessions=16
 MaxWait=30
 MaxWaitIndirect=30
 PingIntervalSeconds=60
 Port=177
[greeter]
[chooser]
 Multicast=false
[debug]
 Enable=false

Il suffit ensuite de redémarrer le service GDM pour activer le XDMCP.

service gdm restart

Cependant, si vous avez désactivé IPV6 sur votre réseau, cela ne fonctionnera pas, puisque XDMCP écoute par défaut en IPV6 désormais. Vous pouvez le voir en root avec la commande netstat:

root@test4:/home/manu# netstat -putan|grep 177
udp6       0      0 :::177        :::*        646/gdm-binary

Il faut alors désactiver IPV6 sur l’ordinateur qui diffusera son affichage, par exemple en le désactivant au niveau du noyau.

On peut le faire en rajoutant une option au fichier de configuration de grub. Modifiez les fichier /etc/default/grub pour ajouter l’option « ipv6.disable=1 »

GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet splash"

Reconstruisez le fichier de configuration de grub par « sudo update-grub » puis redémarrez votre ordinateur. Netstat vous indique alors que XDMCP écoute en IPV4 ((notez le 6 qui a disparu et la notation des adresses))

root@test4:/home/manu# netstat -putan|grep 177
udp       0      0 0.0.0.0:177        0.0.0.0*        658/gdm-binary

Utiliser le client XDMCP

On peut utiliser Xming depuis Windows, mais depuis Linux, il est plus simple d’utiliser tsclient. Dans la liste des protocoles, si vous ne voyez pas XDMCP, c’est qu’il vous faut l’installer le paquet xnest

sudo apt-get install xnest

tsclient avec XDMCPEnsuite, pour la connexion, c’est du classique.

Un client XDMCP en console

Si vous désirez lancer une session XDMCP systématiquement, il est inutile se charger gnome ou un gestionnaire de fenêtres simplement pour lancer tsclient puis votre session XDMCP. Il est possible de lancer celle ci directement.

Désactivez le lancement de GDM, puis logguez vous sur l’ordinateur et tapez la commande suivante:

/usr/X11R6/bin/X -query 192.168.1.2

où 192.168.1.2 est le serveur sur lequel vous avez activé XDMCP.

Sources:

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…