Humus numericus

Aller au contenu | Aller au menu | Aller à la recherche

R, Spip et autres

Mot-clé - debian

Fil des billets

vendredi 12 novembre 2010

Console graphique avec grub2 sous Debian

Le passage à grub2 sous Debian a entraîné quelques changements dans la configuration du bootloader, et notamment si on souhaite obtenir une console graphique au moment du boot et pas seulement 25 lignes et 80 colonnes de texte.

À noter que l’ancienne méthode fonctionne toujours, à savoir passer un argument supplémentaire du type vga=788 dans les paramètres du noyau, mais ça n’est plus la méthode recommandée.

Si on regarde dans le fichier /etc/default/grub, on constate la présence d’un paramètre GRUB_GFXMODE qui permet de spécifier une résolution pour les consoles graphiques. Celui-ci fonctionne pour l’invite de grub (celle où vous pouvez choisir quel noyau booter), mais n’est pas prise en compte pour la console qui s’affiche ensuite. Pour cela il manque en effet un paramètre, que nous pouvons ajouter à l’aide de la ligne suivante dans /etc/default/grub :

GRUB_GFXPAYLOAD_LINUX=keep

Mettez ensuite à jour votre grub :

$ sudo update-grub

Et voilà ! Vous devriez normalement avoir une jolie console graphique au prochain démarrage.

En guise de complément, on pourra aussi noter que :

  • on peut configurer la police de la console graphique et sa taille en modifiant les paramètres FONTFACE et FONTSIZE du fichier /etc/default/console-setup.
  • si vous ne savez pas quelle résolution indiquer dans GRUB_GFXMODE, vous pouvez ouvrir une console grub en tapant sur c à l’invite de grub et tapez ensuite la commande vbeinfo, qui liste les modes graphiques supportés par votre système.

mardi 2 décembre 2008

Astuces Linux du jour

Ajouter un utilisateur à un groupe rapido

Jusqu'ici, quand je voulais m'ajouter à un groupe, je faisais un bête :

# adduser julien group

Problème : dans ces cas-là on est obligé de fermer sa session pour que le changement soit pris en compte. Et bien je viens de découvrir la commande newgrp qui permet de faire ça directement :

$ sudo adduser username group
$ newgrp group

Accélérer les connexions SSH

Si vous avez tendance à vous connecter souvent aux mêmes serveurs, les versions récentes d'openSSH permettent d'accélérer les temps de connexion via du multiplexage de connexion. Pour cela il faut rajouter les lignes suivantes dans ~/.ssh/config (fichiers à mettre en 600) :

Host *
ControlPath ~/.ssh/mux_socket-%r@%h:%p

Puis de lancer un ssh de la manière suivante (par exemple dans votre .xsession :

ssh -fMN nomduserveur

A partir de là les temps d'établissement de connexion vers ce serveur seront beaucoup plus rapides...

Faire de l'ipv6 facilement

J'avais déjà essayé deux ou trois manières de me connecter en ipv6 depuis la maison, mais c'est en général un peu lorudingue : faut s'inscrire chez un tunnel broker, mettre en place des scripts, avoir une IP fixe... Mais je viens de tomber sur un article de Debian administration qui présente le paquet miredo qui permet de faire tout ça de manière hyper-simple. Une commande suffit :

# apt-get install install miredo

Et vous aurez la joie de voir la tortue danser !

jeudi 6 décembre 2007

Script shell de transfert de photos

Pas sûr que ça en vaille la peine, mais je me permets quand même de mettre en ligne le petit script bash que j'utilise pour transférer les photos depuis mon appareil numérique vers mon PC. Le script en question part du principe que l'appareil est reconnu comme un périphérique de stockage de masse USB et qu'il est automatiquement monté au point de montage indiqué par la variable mount_point. Il faut également renseigner les variable source_dir (chemin vers le répertoire dans lequel se trouve les photos à partir du point de montage) et cible_dir (emplacement des photos sur le PC). Vous aurez également besoin du paquet libjpeg-progs pour avoir la commande exifautotran.

Une fois que vous avez tout ça, vous aurez juste à brancher votre appareil et à lancer le script. Celui-ci s'occupera de monter le périphérique, de copier chaque image dans un répertoire nommé selon la date de prise de la photo (au format /home/photos/2007/12 par exemple) et d'effectuer une rotation en fonction de l'orientation horizontale ou verticale contenue dans les données EXIF.

#!/bin/sh                                                           
                                                                    
mount_point=/mnt/photo
source_dir=dcim/100km028 
cible_dir=/home/photos

mount $mount_point
for i in $mount_point/$source_dir/*.jpg; do  
        img=`basename $i`
        annee=`stat -c %y $i | cut -d '-' -f 1`
        mois=`stat -c %y $i | cut -d '-' -f 2`
        cible=$cible_dir/$annee/$mois
        if [ ! -d $cible ];
        then
                mkdir -p $cible
        fi      
        echo "Copie de $i vers $cible/$img"
        cp -i $i $cible/$img
        exifautotran $cible/$img
done;   
sleep 2s
umount $mount_point

Comme d'hab en ces lieux, vous constaterez que c'est du vite fait !

vendredi 12 janvier 2007

Automatiser les mises à jour de sécurité sous Debian

Tout utilisateur de Debian qui se respecte connaît les dépôts de paquets spécialement conçus pour colmater les failles de sécurité. Dès qu'un problème est identifié, l'équipe de sécurité applique les correctifs existants et met tout ça à disposition le plus vite possible. Nous allons voir ici comment faire en sorte que ces mises à jour soient appliquées automatiquement, par exemple une fois par jour.

La première chose à faire est d'installer le paquet cron-apt, qui est spécialement fait pour ça :

# apt-get install cron-apt

Ce paquet permet de lancer une mise à jour à intervalle régulier. Le problème est que nous ne voulons mettre à jour que les paquets concernés par les problèmes de sécurité, et pas l'ensemble de notre distribution. Ceci est particulièrement important si on utilise une distribution testing ou unstable. Pour cela nous allons créer une source de paquets restreinte aux dépôts de sécurité. On va donc éditer un fichier /etc/apt/security.sources.list contenant la ligne suivante :

deb http://security.debian.org/ testing/updates main contrib non-free

(remplacez testing par stable ou unstable selon votre config)

Il faut ensuite indiquer à cron-apt d'utiliser ce fichier. Pour cela, ouvrez le fichier /etc/cron-apt/config et ajoutez ou décommentez la ligne suivante :

OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/security.sources.list"

Par défaut, cron-apt ne fait que mettre à jour les sources de paquets, et ne les installe pas. Si vous souhaitez automatiser également l'installation, il faut que vous rajoutiez un fichier nommé 5-install dans le répertoire /etc/cron-apt/action.d/ et qui contient la ligne suivante :

dist-upgrade -y -o APT::Get::Show-Upgraded=true

Attention : il est normalement déconseillé d'effectuer ce genre d'actions automatiquement sur un serveur. En cas de problèmes lors de la mise à jour, ceci peut empêcher certains services de redémarrer. Dans tous les cas, pensez à bien regarder les rapports envoyés par Cron pour vérifier que tout s'est bien dérouolé...

Et voilou. Il nous reste à régler la fréquence et le moment des mises à jour. Par défaut elles ont lieu une fois par jour à 4h du matin (cf le fichier /etc/cron.d/cron-apt). Ceci est très bien si vous avez un serveur qui tourne en permanence. Mais pour une machine de bureau, on pourra plutôt utiliser anacron et faire un lien sympolique vers /usr/sbin/cron-apt dans /etc/cron.daily :

# ln -s /usr/sbin/cron-apt /etc/cron.daily/cron-apt

mercredi 15 février 2006

Utiliser le browser SWT sous Eclipse 3.1.1 avec Debian

J'utilise depuis peu une version recompilée pour testing du paquet unstable d'Eclipse 3.1.1. Tout fonctionne bien a priori, mais je viens de rencontrer une difficulté après l'installation des RDT (Ruby Development Tools) pour utiliser la vue ri : j'obtiens un message d'erreur me signalant un crash de SWT.

En fait, cette erreur est due à l'impossibilité pour Eclipse et SWT d'utiliser le widget Browser du fait d'une dépendance non-satisfaite, en l'occurrence il a besoin de la librairie libgtkembedmoz.so qu'il ne retrouve pas. Les instructions pour faire tourner tout ça sont dans la FAQ d'Eclipse, mais en fait sous Debian le problème vient du fait que SWT cherche la librairie manquante sous Firefox alors qu'elle n'est présente que sous Mozilla. Et modifier la variable MOZILLA_FIVE_HOME, comme indiqué dans la faq, ne fontionne pas car celle-ci est initialisée dans le script de démarrage d'Eclipse.

La solution la plus simple est donc de modifier le script de démarrage en question, en l'occurrence le fichier /usr/bin/eclipse en transformant le passage suivant :

# Set path for the Mozilla SWT binding
if [ -d /usr/lib/firefox ]; then
    export MOZILLA_FIVE_HOME=/usr/lib/firefox
elif [ -d /usr/lib/mozilla-firefox ]; then
    export MOZILLA_FIVE_HOME=/usr/lib/mozilla-firefox
elif [ -d /usr/lib/mozilla ]; then
    export MOZILLA_FIVE_HOME=/usr/lib/mozilla
fi

en ceci :

# Set path for the Mozilla SWT binding
#if [ -d /usr/lib/firefox ]; then
#    export MOZILLA_FIVE_HOME=/usr/lib/firefox
#elif [ -d /usr/lib/mozilla-firefox ]; then
#    export MOZILLA_FIVE_HOME=/usr/lib/mozilla-firefox
if [ -d /usr/lib/mozilla ]; then
    export MOZILLA_FIVE_HOME=/usr/lib/mozilla
fi

Note : je viens de mettre à jour en version 3.1.2, et le problème est fixé dans le /usr/bin/eclipse de la distribution.

lundi 6 juin 2005

Sarge est sortie !

Ça y'est ! Après trois ans de travail de la part de centaines de bénévoles, la Debian Sarge est officiellement sortie aujourd'hui. C'est beau, tiens.

http://www.debian.org/News/2005/20050606

lundi 21 février 2005

I'm a debian guru..

Et ouais !

Vous en doutiez ? Ben fallait pas. Attention, accrochez-vous au fauteuil, ça va décoiffer.

Ça faisait un moment que j'avais des problèmes de son bizarre sur ma debian. Par exemple, en regardant un film, j'avais la musique et pas la voix. Bien décidé à ne pas me laisser arrêter par ce genre de bricole, je me suis lancé à fond dans la résolution du problème :

  • test sous Windows pour voir que ma carte fonctionnait bien
  • test sous différents programmes
  • exploration des différents réglages des différents programmes de mixage. Là, je repère les contrôles qui sont en cause. J'arrive à remettre un son correct, mais dès que je mets un nouveau son ça revient au départ.
  • tests multiples avec alsactl, alsamixer, gamix, désinstallation de aumix...
  • désinstallation et réinstallation complète des paquets Alsa
  • recompilation du noyau
  • récupération du dernier noyau avec les derniers patchs
  • nouvelle recompilation
  • nouveaux tests...
  • modification du code source d'un fichier du noyau un peu au pif
  • recompilation
  • toujours rien.

Et là, au bout de peut-être 5 heures cumulées de réflexion, l'illumination, l'éclair de génie qui m'a permis de régler le problème sans l'aide de personne malgré mes recherches nombreuses sur Internet :

J'avais branché mes enceintes sur la mauvaise sortie de ma carte son.

Putain mais quel con.

I'm a debian guru, vous dis-je.

Bon, ben me reste plus qu'à faire refonctionner mon accélération 3d, ma clé usb et mon graveur, et j'aurai un système à nouveau un peu utilisable.

Grrrr...

mardi 25 janvier 2005

Utiliser Jabber avec gaim ou emacs+erc+bitlbee derrière un firewall et/ou un proxy

Je viens d'installer ma machine sur le réseau de mon nouveau lieu de travail, et cela a été l'occasion de me repencher sur le sujet de "comment arriver à utiliser un client IM, en l'occurrence Jabber, à travers un firewall et un proxy http (pour discuter avec des collègues de travail sur des sujets strictement professionnels, cela va de soi).

Lorsqu'il n'y a qu'un firewall, c'est assez simple, car en général celui-ci autorise les connexions au port 80. Il suffit donc de se créer une adresse sur un serveur du type jabber80.com, qui tourne justement sur un port 80, et le tour est joué en utilisant Gaim.

Quand on a en plus un proxy http qui filtre les connexions, c'est un peu plus compliqué car les requêtes Jabber ne sont pas des requêtes http classiques. Le proxy risque donc de les bloquer, ce qui était mon cas. L'astuce réside alors à utiliser non pas le port 80, mais le port 443 (https), car les requêtes destinées à ce port ne sont pas filtrables par le proxy si celui-ci les accepte. Or, de nombreux serveurs Jabber tournent sur le port 443, dont toute la série des amessage (amessage.info...) et bien d'autres (jabberes.org, chrome.pl...). Là encore, avec Gaim, pas de problème, tout se paramètre lors de la création/modification du compte.

Jusque là, rien de très difficile et je ne fais que reprendre des infos présentes ici :

http://web.amessage.info/firewalled/

On va donc compliquer un peu : et si je veux utiliser non plus Gaim, mais un bon vieux emacs avec Erc, le tout sous Bitlbee (en fait, n'importe quel client IRC sous Bitlbee) ? A priori, suffit de faire pareil en commençant par indiquer les paramètres du proxy dans le fichier bitlbee.conf (le plus souvent dans /etc). Sauf qu'il n'est pas possible, en tous cas je n'ai pas trouvé l'option, de modifier le port par défaut pour la connexion aux serveurs Jabber dans les comptes sous Bitlbee. Gloups. Prenant mon courage à deux mains, j'ai donc décidé de tenter un gros hack bien sale et tout con mais qui a le mérite de marcher : modifier le port par défaut de connexion aux serveurs Jabber de 5222 et 5223 à 443 dans les sources de Bitlbee et recompiler la chose. Il va de soi que cette "astuce" au bulldozer ne pourra vous intéresser que si vous êtes sûr de ne vouloir vous connecter qu'à des ports 443 pour les serveurs Jabber de ce Bitlbee-là.

La manip sous Debian est assez simple. En premier lieu, il faut récupérer le paquet source avec un :

# apt-get source bitlbee

Il faut ensuite remplacer 5222 et 5223 par 443 dans les lignes suivantes du fichier protocols/jabber/jabber.c :

#define DEFAULT_PORT 5222
#define DEFAULT_PORT_SSL 5223

C'est fait ! Il n'y a plus qu'à reconstruire le package avec un petit dpkg-buildpackage, puis à l'installer avec un dpkg -i et le tour est joué.

Enfin, dernier intérêt, les connexions entre la machine faisant tourner Bitlbee et le serveur Jabber, si je ne me gourre, devraient être chiffrées. Ce qui n'est pas sans intérêt pour des conversations professionnelles hautement confidentielles...

Post-Scriptum : en fait non, je viens de vérifier pour le chiffrement des communications, et c'est à moitié vrai. Pour que ça marche sous Gaim, il faut cocher "forcer l'ancien SSL" dans la configuration du compte. Pour bitlbee, il faut modifier à nouveau le code source du fichier jabber.c, et plus précisément mettre "ssl=1" dans la portion de code suivante :

(...)
static void gjab_start(gjconn gjc)
{
   struct aim_user *user;
   int port = -1, ssl = 1;
(...)