Le jeudi 7 mars 2013 à 19:11
Les métadonnées et vignettes constituent la majeure partie des données des petites images. Exiftool permet de les éliminer facilement :
exiftool -All= image.jpg
J'ai ainsi pu faire passer une image JPEG de 49K à 13K... Très utile pour réduire le poids des éléments graphiques des sites web !
Le samedi 12 janvier 2013 à 22:37
Pendant des années, j'ai utilisé mon client OpenSSH (ligne de commande) en me figurant qu'une fois lancé, il n'y avait pas moyen d'interagir avec lui : tout ce que je tape au clavier est envoyé à la machine distante. Or parfois, une connexion SSH meurt (par exemple parce qu'on a déplacé la machine cliente d'un réseau à un autre...) et on aimerait bien envoyer la commande quit à son client.
Toutes les frappes au clavier sont-elles vraiment transmises à la machine distante ? Que nenni !
Il existe une séquence d'échappement magique, Enter puis ~, qui permet de dialoguer avec le client SSH. Notons que ces deux premières touches la touche Enter est bien transmise à l'hôte distant, avant interprétation des caractères suivants en local ; le dernier caractère constitue une commande pour le client SSH. Nous avons par exemple :
. (disconnect) : ferme la connexion et le client, ce que je cherchais plus haut. Il faut donc taper en tout trois touches : Enter puis ~ puis .^Z : met le client à l'arrière planC : permet de rajouter des options de forwarding de port sur la ligne de commande? : affiche la liste des commandes disponiblesMise à jour le 18 janvier 2013 : seule la touche Enter est transmise à l'hôte.
Le samedi 27 octobre 2012 à 11:44
My 2008 Radeon HD 2600 (RV 630) stopped working after upgrading to Ubuntu 12.10 “Quantal Quetzal”. X starts up nicely, the login screen is okay, but when I open a session there is no Launcher, no menu bar. That's because the newer AMD drivers don't support the older cards. So X reverts to plain VESA drivers, while Unity needs accelerated graphics.
The solution basically consists in downgrading X and installing “legacy” drivers (newer X.org releases are not supported by “legacy drivers”...). An easy solution is described here. It uses a Personal Package Archive (PPA) set up by Tomasz Makarewicz (praise him!):
sudo add-apt-repository ppa:makson96/fglrx sudo apt-get update sudo apt-get upgrade sudo apt-get install fglrx-legacy
To uninstall:
sudo ppa-purge ppa:makson96/fglrx
Update, 11 January 2014: since then, I have been able to switch to the Open Source radeon driver, which proved to work like a charm under Ubuntu 12.10, 13.04 and 13.10. More information.
Le mardi 19 juillet 2011 à 19:58
It is now quite easy to get a Wifi connection while on the move, in public places or at hotels or holiday apartments. However, a majority of these access points are not to be relied upon. Most often, the network itself is open, and you log in on a web page. This means that the data exchanged between your laptop and the access point is unencrypted. In other words, anybody may eavesdrop on your data, even if they are not logged in. The same goes for Wifi networks “secured” with WEP, as the key may be recovered by any intruder in a matter of just a few minutes using off-the-shelf programs. And anyway, if you're on an unknown network, you never know if someone who has physical access to the network doesn't “monitor” traffic.
If you use only encrypted protocols on top of the insecure Wifi channel (e.g. HTTPS, POPS, SSH, etc.) it's not really a problem. For instance, you may safely connect to your bank account as it's done over HTTPS. However, if you connect to Wikipedia or Facebook for instance (which use HTTP), anybody may 1) steal your password if you log in, or 2) hijack your session if you have logged in already, and in any case 3) gain access to private information by just capturing exchanged data.
Therefore a basic recommendation is not to connect to websites requiring a log in and not offering HTTPS when on untrusted networks. Unfortunately this prevents you from using many sites. So here comes this solution. All you'll need is an SSH client on your laptop and a trusted computer, online somewhere on the Internet, accessible via SSH.
The connection between you and the trusted computer, using SSH, an encrypted protocol, is inherently secure, and may be safely used on an untrusted network. So the basic idea is to tunnel all your traffic through this secure channel. It's very easy using SSH, because the standard OpenSSH client has an option to create a SOCKS proxy on the local host. To do this just connect to the trusted computer using a command like:
ssh -D 8888 my.trusted.box
Once logged onto the computer, a SOCKS proxy will be opened on your laptop, here on port 8888.
Now all you have to do is to configure your browser or OS to use localhost, port 8888, as a SOCKS proxy. Firefox must be configured specifically (Advanced > Network > Proxy parameters), while Chrome, Safari and IE use system-wide parameters. After that, any HTTP connection will be delegated to your trusted computer, which will do it on your behalf. Note that on MacOSX, when you set a SOCKS proxy, it affects all connections, not just HTTP, so for instance when Mail.app sends an e-mail, it's actually done through your trusted computer.
Le lundi 18 octobre 2010 à 19:31
Pour faire une sauvegarde d'une machine Unix et le transmettre par SSH à la volée sans encombrer le disque local :
sudo tar zcvf - répertoires_à_sauvergarder |ssh user@host "dd of=backup.tar.gz"
Ici, host représente la machine cible, sur laquelle le backup sera envoyé.
Attention, sudo va demander le mot de passe local, puis afficher un certain nombre de noms de fichiers, puis SSH va demander le mot de passe distant.
Le mercredi 15 septembre 2010 à 19:52
Surprise après avoir branché une console série sur une carte IGEPv2 sous Debian GNU/Linux : root ne peut pas se connecter !
Explication : on n'y fait en général pas attention, mais l'ensemble des devices depuis lesquels root peut se loguer est limité. Il est défini dans le fichier /etc/securetty. Il suffit donc d'ajouter la ligne série en question (pour la carte IGEPv2, c'est /dev/ttyS2), et le tour est joué !
Le mercredi 28 avril 2010 à 22:50
GNU Screen n'est pas connu de tous les utilisateurs d'Unix. Pourtant, ce programme se rend vite indispensable. Derrière sa description de multiplexeur de terminal se cache un concept simple : vous pouvez laisser tourner des applications consoles sur une machine, même lorsque vous vous en déconnectez, et vous prenez la main sur leurs « terminaux » quand vous le souhaitez, d'où vous le souhaitez.
Screen se lance simplement par la commande screen. Pour se reconnecter (rattacher) à une session existante, on tape screen -r ID_SESSION. La liste des ID de session existants s'obtient par la commande screen -ls.
En cours de fonctionnement, screen dispose de nombreuses commandes accessibles par des raccourcis clavier qui commencent par C-a. La liste des principaux raccourcis est la suivante :
| Combinaison | Action |
|---|---|
| C-a d | détacher (fermer la fenêtre, mais pouvoir récupérer la session plus tard) |
| C-a c | créer une nouvelle fenêtre |
| C-a k | supprimer la fenêtre courante (kill) |
| C-a F | adapte la taille de la fenêtre, très utile en cas de passage d'un terminal à un autre (fit) |
| C-a ? | aide en ligne |
| C-a n | passer à la fenêtre suivante |
| C-a p | passer à la fenêtre précédente |
| C-a 0 à C-a 9 | passer à la fenêtre de numéro indiqué |
| C-a " | menu des fenêtres |
| C-a : | prompt pour taper directement des commandes (cf. manuel) |
Pour plus de détails, on consultera le manuel officiel, ou cette bonne documentation en français.
Screen peut répondre à de nombreux besoins. Il est très utilisé en conjonction avec le client IRC irssi, mais on peut trouver des applications plus exotiques, par exemple screen comme terminal série.
À noter que j'ai eu quelques soucis sur Mac, pour me connecter à une Debian : le terminal local fonctionne bien, screen en local fonctionne bien, le terminal distant par ssh fonctionne bien, mais screen sur la Debian distante posait problème : la touche Backspace envoyait Delete (mais seulement lorsque TERM valait xterm-color, pas xterm)... Il s'agit d'une sombre histoire de terminfo dont une solution est donnée sur Mac OS X Hints : recopier le fichier terminfo xterm-color du Mac sur la debian, dans le répertoire ~/.terminfo/x.
Le mardi 30 mars 2010 à 18:47
Quelle est la mémoire occupée par un processus Linux donné ? C'est dans certains cas très important de le savoir, par exemple pour déterminer combien de processus peut créer un serveur Apache sans risquer de faire swapper la machine (paramètre MaxClients). À première vue, la réponse devrait être donnée par la commande ps. Cette dernière renvoie deux valeurs, VSIZE et RSS :
Clairement, la métrique RSS ne convient pas, car il se peut que le processus ait swappé. Malheureusement, VSIZE ne convient pas non plus, car cette métrique ne tient pas compte des pages qui peuvent être partagées entre plusieurs processus : bibliothèques partagées, code partagé (entre des processus qui ont forké, par exemple diverses instances d'Apache), et même données partagées (sous Linux, fork fonctionne en copy-on-write, c'est-à-dire que les pages du processus fils ne sont dupliquées que lorsque le fils ou le parent effectue une écriture).
Si on y réfléchit un peu, il n'y a pas de solution universelle à la définition d'une métrique de consommation mémoire. Ainsi, les propositions suivantes ont été effectuées (mais pas intégrées dans le noyau à ma connaissance) :
Depuis le noyau 2.6.14, il existe également un fichier /proc/<PID>/smaps qui fournit des informations détaillées sur la mémoire d'un processus. Cela demande certainement un peu de mise en forme, mais il doit être possible d'en tirer des informations du type PSS et USS.
Le samedi 18 juillet 2009 à 19:10
C'est ce que je croyais...
On a dû changer de bus et/ou d'emplacement le disque root d'un serveur ? Qu'à cela ne tienne, on modifie le disque de boot dans le BIOS, on édite les options de grub au démarrage, puis une fois le système booté on va dans /boot/grub/menu.lst pour rendre les changements définitifs. Il y a alors deux lignes par noyau à changer, du type :
root (hd0,0) kernel /boot/vmlinuz-2.6.18-6-486 root=/dev/hda1 ro
À chaque fois, il convient de mettre la bonne partition : ici hd0,0 ou /dev/hda1, selon la convention choisie.
Bien, bien. On reboote la machine, pour valider la chose. Elle boote comme un charme, pas de problème. On va donc la remettre à son emplacement de « production », au hasard au fond d'un placard, sans clavier ni écran bien entendu. Encore un boot, tout se passe bien, on en profite pour appliquer les dernières mises à jour, puis la machine vit sa vie.
Un jour, la machine reboote pour une raison quelconque, et là, perte de contact réseau ! Bien qu'elle soit headless, on se rend vite compte que Debian n'a pas booté. On l'extrait de son placard, on la connecte à un écran et un clavier, et là stupeur, on constate que grub cherche à booter sur l'ancien emplacement de la partition racine... À se taper la tête contre les murs.
Explication
Parmi les mises à jour effectuées, il y avait eu une mise à jour du noyau. Or lors des mises à jour du noyau, les sections par défaut de menu.lst (celles qui sont repérées par les BEGIN/END AUTOMAGIC KERNELS LIST) sont écrasées par un script qui s'appelle update-grub. Les modifications faites à la main sont donc perdues. Il ne faut donc pas faire comme expliqué ci-dessus sous Debian, mais au contraire, modifier directement les paramètres qui sont utilisés par update-grub. Ces paramètres sont donnés directement dans le fichier menu.lst, sous forme de commentaires spéciaux. Il y en a deux qui nous intéressent :
# kopt=root=/dev/hda1 ro # groot=(hd0,0)
Ce sont donc ces deux lignes qu'il faut modifier, puis pour appliquer les modifications aux lignes « réelles » du fichier de configuration, il suffit d'appeler update-grub.
Le mercredi 13 mai 2009 à 22:09
Normalement, avoir la ligne
X11Forwarding yes
dans son /etc/ssh/sshd_config suffit pour que le forwarding de X11 dans SSH fonctionne.
Si cela ne fonctionne pas (variable DISPLAY non définie après le login), vérifier que vous avez installé le package xbase-clients (sous Debian en tout cas) car il est nécessaire (notamment pour xauth).
Le mercredi 4 février 2009 à 21:42
Outre les attributs classiques Unix, MacOS X possède des flags et attributs étendus qui peuvent faire perdre leur latin aux Unixiens... Exemple : il vous est impossible de supprimer un fichier. Pourtant, un ls -la vous confirme que le fichier et le répertoire vous appartiennent, et que vous avez dessus les droits en écriture. Vous ne comprenez pas. Vous essayez de passer root pour forcer les choses et... root ne peut pas non plus supprimer le fichier ! Que se passe-t-il ?
Des drapeaux peuvent être positionnés sur les fichiers. Notamment, il existe un drapeau uchg qui explique le problème ci-dessus. Le drapeau uchg verrouille complètement un fichier. Dans le GUI, il correspond à la case « Verrouiller » de la boîte d'infos du fichier. Pour pouvoir supprimer le fichier dans l'exemple ci-dessus, il faut d'abord retirer le flag uchg.
Pour afficher les flags des fichiers, les options de ls sont :
ls -lO
La modification de ces flags se fait avec la commande chflags, suivie du nom d'un drapeau pour l'ajout, ou du nom préfixé de no pour la suppression. Exemple (-R pour récursif) :
chflags -R nouchg répertoire
Les fichiers peuvent également posséder des attributs étendus. Par exemple, l'attribut com.apple.quarantine signale les fichiers récemment téléchargés. On peut afficher les attributs étendus par la commande :
ls -l@
La commande xattr permet de lister, ajouter et modifier les attributs. Par exemple, pour afficher les attributs et leurs valeurs, on peut utiliser :
xattr -l fichier
⇒ Article d'Ars Technica sur les attributs étendus.
Les ACL permettent de régler finement les permissions, au niveau de chaque utilisateur ou groupe. On peut afficher les permissions étendues avec :
ls -le
La modification se fait avec chmod +a.
Le mercredi 24 décembre 2008 à 11:20
GNU Readline est une bibliothèque peu connue de l'utilisateur lambda, mais à laquelle il est utile de s'intéresser. En effet, c'est grâce à elle que de nombreux outils de type « ligne de commande » dialoguent avec l'utilisateur. Readline permet à l'utilisateur de taper des lignes de texte, de les modifier, et de naviguer dans un historique. Par exemple, c'est Readline qui gère l'édition de la ligne de commande sous GNU Bash, et gère son historique.
Il existe de très nombreuses commandes sous Readline, mais les quelques-unes présentées ci-dessous sont d'usage courant : il est vraiment utile de les connaître. Pour les autres, on peut se référer au manuel utilisateur.
| Combinaison | Action |
|---|---|
| ←, → | Déplace le curseur dans la ligne |
| C-a, C-e | Saute en début ou fin de ligne |
| C-l (« L ») | Efface l'écran |
| C-w | Efface le mot précédent ou en cours (vers la gauche) |
| ESC-d | Efface le mot suivant ou en cours (vers la droite) |
| C-k | Efface la fin de la ligne |
| C-_ | Annule la dernière modification |
| ↑, ↓ | Navigue dans l'historique : plus ancien, plus récent |
| C-r (C-s, C-g) | Recherche un texte dans une commande précédente, puis encore C-r passe à l'occurrence précédente, C-s à l'occurrence suivante. C-g annule la recherche |
| C-v | Insère le caractère qui suit, sans l'interpréter. C'est très utile pour taper tels quels des caractères de contrôle. Par exemple, pour insérer ^A il faut taper C-v, C-a |
Les combinaisons ci-dessus constituent les choix par défaut. En réalité, tout est personnalisable via le fichier ~/.inputrc. Sous Bash, on obtient la liste des bindings en cours avec la commande bind -p.
Le mardi 6 mai 2008 à 23:19
Soit un serveur Unix (disons Linux Debian), depuis lequel on désire envoyer des e-mails, par exemple depuis PHP, ou depuis des cronjobs de maintenance. Mais on n'a pas envie d'installer un MTA, genre Sendmail, Postfix ou Exim, pour diverses raisons (ne pas ouvrir de brèche de sécurité potentielle, ne pas charger la machine « pour rien »).
Il existe quelques solutions de clients SMTP, chargés d'envoyer des e-mails de façon ponctuelle via un relais SMTP, sans pour autant être des MTA en bonne et due forme (donc pas de serveur, pas de file d'attente asynchrone, mais plutôt un envoi synchrone de messages au coup par coup). Parmi eux, msmtp possède un paquet Debian. Voici comment procéder...
Le dimanche 7 octobre 2007 à 23:31
I never had the opportunity to test my VTPlayer driver on an architecture other than IA-32. As I have just got hands on a SunBlade 100, which now runs Ubuntu Linux, I tried to compile and test the driver. There were no compile error nor crashes, but the driver mysteriously failed when probing the device. As usual, this was caused by an indianness mess: everything in the USB protocol is little-endian, so if you test on little-endian machines only, you are prone to making mistakes like this one:
if ((udev->descriptor.idVendor != VTP_VENDOR_ID) ||
(udev->descriptor.idProduct != VTP_PRODUCT_ID)) { ...
The comparisons depend on the computer's endianness, which is not portable (although it seems fine on IA-32). One has to use le16_to_cpu before comparing:
if ((le16_to_cpu(udev->descriptor.idVendor) != VTP_VENDOR_ID) ||
(le16_to_cpu(udev->descriptor.idProduct) != VTP_PRODUCT_ID)) { ...
The latest version of the driver, labelled 0.4.1, now works fine on IA-32 and SPARC architectures, and should be OK on other architectures as well. It is compatible with the latest Linux kernels (2.6.22.9). It is available for download at SourceForge.net.
Le dimanche 7 octobre 2007 à 23:12
J'ai récupéré une station SunBlade 100, qui pourrait venir remplacer mon Ultra 10... J'ai essayé d'y installer une Ubuntu Gutsy. Ce billet présente quelques points à retenir :
boot cdrom (ce qui paraîtrait logique). Cela se termine par un « Illegal Instruction » ou « Memory Address not Aligned » lors du chargement du noyau... Il faut booter sur le CD directement. Pour ma part, j'ai donc fait un petit setenv boot-device cdrom disk net, puis power-off, puis j'ai rallumé la machine (voir ce thread) ;video=atyfb:1024x768@60 ;« billets plus anciens - page 1 de 2