Humus numericus - Mot-clé - debian2019-05-09T20:00:29+02:00urn:md5:c2531a830c9d2a52c5500061b4d5077eDotclearConsole graphique avec grub2 sous Debianurn:md5:e0e279e9aabdd8316f223a2aa95e63842010-11-12T09:42:00+01:002010-11-12T10:42:49+01:00JubaLinux, Debian, etc.debiangrubsysadmin <p>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.</p>
<p>À noter que l’ancienne méthode fonctionne toujours, à savoir passer un argument supplémentaire du type <code>vga=788</code> dans les paramètres du noyau, mais ça n’est plus la méthode recommandée.</p>
<p>Si on regarde dans le fichier <code>/etc/default/grub</code>, on constate la présence d’un paramètre <code>GRUB_GFXMODE</code> 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 <code>/etc/default/grub</code> :</p>
<pre>
GRUB_GFXPAYLOAD_LINUX=keep
</pre>
<p>Mettez ensuite à jour votre grub :</p>
<pre>
$ sudo update-grub
</pre>
<p>Et voilà ! Vous devriez normalement avoir une jolie console graphique au prochain démarrage.</p>
<p>En guise de complément, on pourra aussi noter que :</p>
<ul>
<li>on peut configurer la police de la console graphique et sa taille en modifiant les paramètres <code>FONTFACE</code> et <code>FONTSIZE</code> du fichier <code>/etc/default/console-setup</code>.</li>
<li>si vous ne savez pas quelle résolution indiquer dans <code>GRUB_GFXMODE</code>, vous pouvez ouvrir une console grub en tapant sur <code>c</code> à l’invite de grub et tapez ensuite la commande <code>vbeinfo</code>, qui liste les modes graphiques supportés par votre système.</li>
</ul>Astuces Linux du joururn:md5:3293041399fbb3ac00a0d3b4cd39935b2008-12-02T00:19:00+01:002008-12-19T23:20:32+01:00JubaLinux, Debian, etc.debianipv6linuxsshsysadmin <h3>Ajouter un utilisateur à un groupe rapido</h3>
<p>Jusqu'ici, quand je voulais m'ajouter à un groupe, je faisais un bête :<br /></p>
<pre>
# adduser julien group
</pre>
<p>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 <code>newgrp</code> qui permet de faire ça directement :<br /></p>
<pre>
$ sudo adduser username group
$ newgrp group
</pre>
<ul>
<li>Source : <a href="http://linuxfr.org/comments/911699.html#911699" title="http://linuxfr.org/comments/911699.html#911699">http://linuxfr.org/comments/911699....</a></li>
</ul>
<h3>Accélérer les connexions SSH</h3>
<p>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 <code>~/.ssh/config</code> (fichiers à mettre en 600) :</p>
<pre>
Host *
ControlPath ~/.ssh/mux_socket-%r@%h:%p
</pre>
<p>Puis de lancer un ssh de la manière suivante (par exemple dans votre <code>.xsession</code> :</p>
<pre>
ssh -fMN nomduserveur
</pre>
<p>A partir de là les temps d'établissement de connexion vers ce serveur seront beaucoup plus rapides...</p>
<ul>
<li>Source : <a href="http://linuxfr.org/comments/911768.html#911768" title="http://linuxfr.org/comments/911768.html#911768">http://linuxfr.org/comments/911768....</a></li>
</ul>
<h3>Faire de l'ipv6 facilement</h3>
<p>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 <em>tunnel broker</em>, mettre en place des scripts, avoir une IP fixe... Mais je viens de tomber sur un article de <em>Debian administration</em> qui présente le paquet <code>miredo</code> qui permet de faire tout ça de manière hyper-simple. Une commande suffit :</p>
<pre>
# apt-get install install miredo
</pre>
<p>Et vous aurez la joie de voir la <a href="http://www.kame.net/" hreflang="en">tortue danser</a> !</p>
<ul>
<li>Source : <a href="http://www.debian-administration.org/articles/621" title="http://www.debian-administration.org/articles/621">http://www.debian-administration.or...</a></li>
</ul>Script shell de transfert de photosurn:md5:588f854d8189584b022328c1522933ec2007-12-06T00:14:00+01:002007-12-06T01:25:37+01:00JubaLinux, Debian, etc.debianlinuxphotoscript <p>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 <code>mount_point</code>. Il faut également renseigner les variable <code>source_dir</code> (chemin vers le répertoire dans lequel se trouve les photos à partir du point de montage) et <code>cible_dir</code> (emplacement des photos sur le PC). Vous aurez également besoin du paquet <code>libjpeg-progs</code> pour avoir la commande <code>exifautotran</code>.</p>
<p>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 <code>/home/photos/2007/12</code> par exemple) et d'effectuer une rotation en fonction de l'orientation horizontale ou verticale contenue dans les données EXIF.</p>
<pre>
#!/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
</pre>
<p>Comme d'hab en ces lieux, vous constaterez que c'est du vite fait !</p>Automatiser les mises à jour de sécurité sous Debianurn:md5:20bd588bdd783ee6b58f7cedf8f792a02007-01-12T22:10:00+00:002009-04-06T09:22:26+00:00JubaLinux, Debian, etc.debianlinuxsysadmin <p>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.</p>
<p>La première chose à faire est d'installer le paquet <code>cron-apt</code>, qui est spécialement fait pour ça :</p>
<pre># apt-get install cron-apt</pre>
<p>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 <em>testing</em> ou <em>unstable</em>. Pour cela nous allons créer une source de paquets restreinte aux dépôts de sécurité. On va donc éditer un fichier <code>/etc/apt/security.sources.list</code> contenant la ligne suivante :</p>
<pre>deb http://security.debian.org/ testing/updates main contrib non-free</pre>
<p>(remplacez <code>testing</code> par <code>stable</code> ou <code>unstable</code> selon votre config)</p>
<p>Il faut ensuite indiquer à <code>cron-apt</code> d'utiliser ce fichier. Pour cela, ouvrez le fichier <code>/etc/cron-apt/config</code> et ajoutez ou décommentez la ligne suivante :</p>
<pre>OPTIONS="-o quiet=1 -o Dir::Etc::SourceList=/etc/apt/security.sources.list"</pre>
<p>Par défaut, <code>cron-apt</code> 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é <code>5-install</code> dans le répertoire <code>/etc/cron-apt/action.d/</code> et qui contient la ligne suivante :</p>
<pre>dist-upgrade -y -o APT::Get::Show-Upgraded=true</pre>
<p><strong>Attention :</strong> 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é...</p>
<p>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 <code>/etc/cron.d/cron-apt</code>). 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 <code>anacron</code> et faire un lien sympolique vers <code>/usr/sbin/cron-apt</code> dans <code>/etc/cron.daily</code> :</p>
<pre># ln -s /usr/sbin/cron-apt /etc/cron.daily/cron-apt</pre>Utiliser le browser SWT sous Eclipse 3.1.1 avec Debianurn:md5:258a149a708ecd47dacd258f6b72e9f92006-02-15T11:13:17+00:002006-02-15T13:49:21+00:00JubaLinux, Debian, etc.debianeclipselinux <p>J'utilise depuis peu une version recompilée pour <em>testing</em> du paquet <em>unstable</em> d'Eclipse 3.1.1. Tout fonctionne bien a priori, mais je viens de rencontrer une difficulté après l'installation des RDT (<em><a href="http://rubyeclipse.sourceforge.net/" hreflang="en">Ruby Development Tools</a></em>) pour utiliser la vue <em>ri</em> : j'obtiens un message d'erreur me signalant un crash de SWT.</p>
<p>En fait, cette erreur est due à l'impossibilité pour Eclipse et SWT d'utiliser le widget <em>Browser</em> du fait d'une dépendance non-satisfaite, en l'occurrence il a besoin de la librairie <code>libgtkembedmoz.so</code> qu'il ne retrouve pas. Les instructions pour faire tourner tout ça sont dans <a href="http://www.eclipse.org/swt/faq.php#browserlinux" hreflang="en">la FAQ d'Eclipse</a>, 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 <code>MOZILLA_FIVE_HOME</code>, comme indiqué dans la faq, ne fontionne pas car celle-ci est initialisée dans le script de démarrage d'Eclipse.</p>
<p>La solution la plus simple est donc de modifier le script de démarrage en question, en l'occurrence le fichier <code>/usr/bin/eclipse</code> en transformant le passage suivant :</p>
<pre># 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</pre>
<p>en ceci :</p>
<pre># 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</pre>
<p><strong>Note :</strong> je viens de mettre à jour en version 3.1.2, et le problème est fixé dans le <code>/usr/bin/eclipse</code> de la distribution.</p>Sarge est sortie !urn:md5:3828e03fc09c303af60e9f3fe7e8ffe52005-06-06T23:34:09+00:002005-06-06T23:34:09+00:00JubaLinux, Debian, etc.debianlinux <p>Ç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.<br /></p>
<p><a href="http://www.debian.org/News/2005/20050606" hreflang="fr">http://www.debian.org/News/2005/20050606</a></p>I'm a debian guru..urn:md5:d3bfa38b8a802abd43b5e0a3033eb8162005-02-21T00:58:40+00:002005-02-21T01:00:24+00:00JubaLinux, Debian, etc.debianlinuxridicule <p>Et ouais !<br /></p>
<p>Vous en doutiez ? Ben fallait pas. Attention, accrochez-vous au
fauteuil, ça va décoiffer.<br /></p>
<p>Ç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 :<br /></p>
<ul>
<li>test sous Windows pour voir que ma carte fonctionnait bien</li>
<li>test sous différents programmes</li>
<li>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.</li>
<li>tests multiples avec alsactl, alsamixer, gamix, désinstallation de aumix...</li>
<li>désinstallation et réinstallation complète des paquets Alsa</li>
<li>recompilation du noyau</li>
<li>récupération du dernier noyau avec les derniers patchs</li>
<li>nouvelle recompilation</li>
<li>nouveaux tests...</li>
<li>modification du code source d'un fichier du noyau un peu au pif</li>
<li>recompilation</li>
<li>toujours rien.<br /></li>
</ul>
<p>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 :<br /></p>
<p><em>J'avais branché mes enceintes sur la mauvaise sortie de ma carte son.</em><br /></p>
<p>Putain mais quel con.<br /></p>
<p>I'm a debian guru, vous dis-je.<br /></p>
<p>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.<br /></p>
<p><em>Grrrr...</em></p>Utiliser Jabber avec gaim ou emacs+erc+bitlbee derrière un firewall et/ou un proxyurn:md5:6b37468dca9765653b709a1e22aaa39b2005-01-25T00:15:46+00:002005-01-25T15:53:28+00:00JubaLinux, Debian, etc.debianemacslinux <p>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 <a href="http://www.jabber.org" hreflang="en">Jabber</a>, à travers un firewall et un proxy http (pour discuter avec des collègues de travail sur des sujets strictement professionnels, cela va de soi).<br /></p>
<p>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 <a href="http://gaim.sourceforge.net" hreflang="en">Gaim</a>.<br /></p>
<p>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.<br /></p>
<p>Jusque là, rien de très difficile et je ne fais que reprendre des infos présentes ici :<br /></p>
<pre><a href="http://web.amessage.info/firewalled/" hreflang="en">http://web.amessage.info/firewalled/</a></pre>
<p>On va donc compliquer un peu : et si je veux utiliser non plus Gaim, mais un bon vieux emacs avec Erc, le tout sous <a href="http://www.bitlbee.org" hreflang="en">Bitlbee</a> (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à.<br /></p>
<p>La manip sous Debian est assez simple. En premier lieu, il faut récupérer le paquet source avec un :<br /></p>
<pre># apt-get source bitlbee<br /></pre>
<p>Il faut ensuite remplacer 5222 et 5223 par 443 dans les lignes suivantes du fichier protocols/jabber/jabber.c :<br /></p>
<pre>#define DEFAULT_PORT 5222
#define DEFAULT_PORT_SSL 5223<br /></pre>
<p>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é.<br /></p>
<p>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...<br />
<br /></p>
<p><strong><em>Post-Scriptum :</em></strong> 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 :<br /></p>
<pre>(...)
static void gjab_start(gjconn gjc)
{
struct aim_user *user;
int port = -1, ssl = 1;
(...)</pre>