Notes et astuces sur les systèmes libres basés sur GNU/Linux

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

jeudi, 26 décembre 2013

Afficher les pistes jouées par mocp dans votre i3bar

musique-coloree_878063.jpgAujourd'hui, un tips sur l'ajout d'information dans votre i3bar.
Pour effectuer ces manipulations, il vous faudra :

  • i3-wm : le gestionnaire de fenêtre qui est leger et qui roxe du poney
  • moc : le lecteur musical en ligne de commande

Récupération des informations de mocp

On peut obtenir les informations sur la piste lue par mocp assez simplement
Soit en utilisant le formatstring du fichier de configuration (lien vers la configuration de mocp)

mocp -Q  "%(a:%a – :)%(t:%t:)%(A: (%A):)"

Soit en utilisant le formatstring du man (qui est quand même plus lisible):

mocp -Q "%state %song - %artist (%album)"

Modifier l'affichage de i3status

On ne peut pas modifier i3status avec des scripts externes mais par contre on peut l'encapsuler dans un script pour y rajouter notre sauce :

#!/bin/sh
i3status | while :
do
	mocp=`mocp -Q  "%state->%song - %artist(%album)" 2> /dev/null`
	 read line
	 echo "$mocp | $line" || exit 1
done

Appeler votre script depuis i3bar :

Pour cela, vous devez modifier votre fichier .i3/config en remplaçant l'appel à i3status par votre script

bar {
         status_command /home/toto/script/myi3.sh
}

Bien penser à indiquer le chemin complet pour i3bar. Car il n'est pas exécuté avec le même path que vous.
Et surtout n'oubliez pas de rendre exécutable votre script.

chmod +x script/myi3.sh

Plus qu'à recharger votre configuration avec votre raccourci favoris.

cat .i3/config| grep restart
bindsym $mod+Shift+r restart

vendredi, 20 décembre 2013

Faire du sso avec ssh sous Archlinux, slim et zsh

Pam-Anderson1.jpgUn billet un peu technique mais qui me semble super utile dans notre gestion des clés ssh au quotidien.

La petite histoire

Avec mon serveur dédié à administrer, je me suis replongé sur cette histoire de clé ssh.
J'en avais déja parlé dans mon article sur la migration de clé ssh entre windows et Archlinux mais la manipulation que j'avais proposé me paraissait bancale.
Je souhaitais trouver quelque chose de plus propre et de plus intégré.
J'ai essayé de me tourner vers seahorse mais cette tentative fut vite interrompue car le logiciel plantait et ne gérait pas mes accès ssh depuis un terminal.
Si quelqu'un dans la salle l'utilise, je suis preneur d'une explication censée.

Sur le papier : SSO et pam_ssh

Ayant lu un billet sur pam_ssh, je souhaitais mettre cette solution en place.
Sur le principe, cette méthode est ce qui se fait de mieux en terme de sécurité/simplicité d'utilisation.

  • On se loggue via son gestionnaire de session avec son login
  • On peut soit rentrer son mot de passe unix soit sa passphrase de sa clé située dans votre .ssh
  • Si la passphrase est valide, le gestionnaire de session lance ssh-agent et ajoute de lui-même la bonne clé dans votre trousseau.
  • Ainsi, vous beneficiez d'un ssh-agent tout configuré au plus haut niveau de votre session (en terme de processus).

En pratique : Archlinux, slim, pam_ssh, zsh

Pour arriver à vos fins, il vous faudra installer la librairie PAM SSH, elle n'est malheureusement disponible que dans AUR.

yaourt -Sy aur/pam_ssh

Ensuite, il vous suffit de modifier votre configuration de pam :

vim /etc/pam.d/login
#%PAM-1.0

auth       required     pam_securetty.so
auth       requisite    pam_nologin.so
+auth       sufficient   pam_ssh.so
auth       include      system-local-login
account    include      system-local-login
session    include      system-local-login
+session    optional     pam_ssh.so

Cette modification vous permettra de faire fonctionner votre pam_ssh avec gdm, kdm et sur un tty mais pas sur XDM ou Slim.
Pour avoir cette merveilleuse fonctionnalité, il vous faudra modifier également le fichier /etc/pam.d/slim

vim /etc/pam.d/slim
#%PAM-1.0
+auth       sufficient   pam_ssh.so
auth        include     system-local-login
account     include     system-local-login
session     include     system-local-login
+session    optional     pam_ssh.so

Note à moi-même : Pour utiliser .zprofile et .zlogin quand on utilise zsh

Cela n'a rien avoir avec la choucroute mais pour bénéficier des scripts .zlogin ou .zprofile, il faut définir dans slim zsh comme un login shell.

vim /etc/slim.com
...
login_cmd           exec /usr/bin/zsh --login ~/.xinitrc %session
...

Maintenant, vous n'avez plus qu'à vous deconnecter ou essayer sur un tty avec votre login et votre passphrase.
Pour vérifier que tout fonctionne, je vous propose les commandes suivantes :

#Normalement le ps devrait vous retourner un process de ce style
ps faux | grep ssh
ssh-agent -s

#Lister les clés en mémoires
ssh-add -l
1024 65:22:54:00:4a:5f.... /home/toto/.ssh/id_dsa (DSA)

Nota Bene :

  • J'ai observé que le mécanisme mis en place ne fonctionnait pas tout le temps et vous ?
  • Je viens d'y penser, si vous le souhaitez vous pouvez également ne pas utiliser de passphrase dans votre clé ssh ! Cela vous permettra de ne plus être importuné par le ssh à chaque connexion :D

Sources :

Ps :

Paméla est là pour représenter PAM, logique non ?

lundi, 19 août 2013

Netkit, UML et Qemu sont dans un bateau Archlinux ... qui tombent à l'eau ?

Hi,

Boussole
Cet article est un résumé de mon expérience de la veille, cela me permettra de savoir ce que j'ai testé et ce qui n'a pas fonctionné mais j'espère que cela vous fera découvrir des solutions.
Un article riche en lien et en expérience, j'espère que cela vous sera utile.

Le besoin :

Comme vous le savez maintenant, je suis en train de configurer mon serveur dedié Online aux petits ognons (nouveaux).
Pour ce faire, je me suis monté une petite infrastructure passionnante.
Pour être un peu plus proche de ma configuration réelle, je m'étais dit qu'il me fallait un système qui me permettrait de simuler mes Iptables et le contexte réseau autour de mon serveur.
J'avais pensé utiliser Virtualbox ou kvm mais la procédure d'installation me paraissait longue et lourde (installation de l'hyperviseur, génération d'un fichier disque dur, installation de l'os virtualisé sur le disque dur) pour un si petit besoin. ...
Par pur fainéantise et commodité, je souhaitais un logiciel prêt à l'emploi.

Netkit : Une solution clé en main intéressante pour simuler des labos virtuels

Netkit était idéal car je n'avais qu'à installer, indiquer le nombre de VM et lancer la vm.
Si vous ne connaissez pas ce projet, je vous invite à consulter les ressources en-dessous pour vous faire une petite idée.
Je dégaine mon yaourt. Un paquet existe. Je lance la compile ...
Crack pas assez de place dans tmp... Faudra que je me penche sur ce problème déjà rencontré, mais je pare au plus pressé, je change de cheval.

UML (UserMode Linux) : Un trousse à outil pour virtualiser une machine

Je prends l’élément de base de netkit, je tombe sur UML.
Wikipedia me dit que c'est nul mais je lis quelques articles et cela semble prometteur et customisable.
Je compile le paquet, je télécharge tout comme il faut, paf ça ne marche pas, cela boucle au démarrage, j'ai dû louper une étape.

QEMU :

Le temps file et les solutions défilent, je vais donc revenir aux vrais valeurs, je réinstalle vite fait un kvm-qemu.
Le paquet a changé de nom depuis mon dernier article, je vais donc feuilleter le wiki fr Archlinux mais il n'est pas à jour.
Peut être que les paquets évoluent trop vite pour notre wiki francophone ...
Il faudra que je m'inscrive pour modifier le wiki.

Comme dit plus haut, je ne voulais pas me farcir l'installation d'un OS juste pour une VM, je pensais donc réutiliser l'image disque Debian téléchargée sur le site UML..
L'image disque n'est plus bootable, je télécharge le kernel mais cela ne marche pas mieux, décidément je suis maudit, je n'ai pas envie de chercher plus longtemps.

Le renoncement ...

On revient à la base de la base, je télécharge une image netinst de Debian et je suis parti.
Tout marche comme il faut, out of box.
Youpii, enfin.
Un petit bémol, la solution "réseau privé" fournie par Qemu ne me convient pas car la machine n'est pas dans le même réseau que ma machine réelle, je devrais donc utiliser des redirections pour tester mon firewall.
Or, quand je teste des règles de pare-feu, il vaut mieux avoir une architecture simple sans redirection foireuse par dessus.
Dans mon optique de réutilisation et de gain de temps, qui a été une pure réussite jusqu'à présent, j'essaye de créer une interface virtuelle et de l'ajouter à mon pont à la mode lxc.
Après quelques incompréhensions, je tombe sur l'explication de lxc sur le réseau veth..
Je me dis qu'il faut juste prendre le numéro de process de mon kvm pour que cela fonctionne mais non cela aurait été trop simple, cela ne fonctionne pas.
J'essaye la solution simple du Wiki archlinuxfr : la création d'une interface virtuelle.
Bien entendu, le paquet uml_utilities a disparu ce qui n'arrange pas mes affaires.
Je me rabats sur la solution openvpn mais je l'abandonne car je peux utiliser la fonction dédiée dans Iproutes2.
Il faudra vraiment que je m'inscrive pour apporter ma pierre à l'édifice Wiki Archlinux.

La partie utile :

#Installation de Qemu
yaourt -S qemu
#Creation du disque dur
qemu-img create debian.raw -f raw 4G
#Installation de l'os virtuel sur le disque virtuel
qemu-system-x86_64 -enable-kvm -m 512 -k fr -drive file=debian.raw,if=virtio,media=disk -usb -usbdevice tablet -cdrom votre_iso.iso -boot d
#Creation de l'interface virtuel
sudo ip tuntap add dev tap1 mode tap
#On monte l'interface
sudo ip link set tap1 up

On l'ajoute au pont (pré-requis la configuration du pont cf : mon article lxc)

brctl addif br0 tun1
#On boot sur le système tout beau :
qemu-system-x86_64 -enable-kvm -m 512 -k fr -drive file=debian-7-amd64.raw,if=virtio,media=disk -usb -usbdevice tablet -net nic -net tap,ifname=tap1,script=no --curses

L'option : curses permet de ne pas ouvrir une nouvelle fenêtre et de n'afficher qu'une fenêtre console, cela permet d'économiser des ressources.
Pour ceux qui ne veulent pas du tout de sortie console, il y a l'option nographic.

Et voilà, plus le temps manque plus on en perds à chercher quelque chose qui fonctionne.
J'arriverai même à penser qu'avoir une distribution rolling release n'est peut être pas l'idéal pour la documentation de la communauté.

                           Au plaisir !!!

Ressources :

Netkit : Un pdf intérressant , Quelques exemples à picorer
UML : Tutoriel pas à pas UML Utilisation d'UML pour monter des labos Le wiki d'Ubuntu
Qemu : Présentation détaillée de Qemu dans un contexte pédagogique L'architecture réseau de Qemu

jeudi, 16 mai 2013

LXC, la solution de virtualisation légère

Si comme moi vous aimez bien tester différents outils ou services GNU/Linux sans encombrer votre machine réelle, la solution de virtualisation par container LXC pourrait grandement vous aider.poupée russe

Voici les quelques avantages de cet outil :

  • Optimisation de l'utilisation de votre machine en hébergeant plusieurs configurations systèmes
  • Sécurisation de vos process en les mettant à l'abris dans un "chroot amélioré".
  • Facilité d'installation car l'outil est intégré au noyau Linux.
  • Avoir sous la main un autre GNU/Linux sans manger toute vos ressources CPU


Cet article n'a pas d'autre prétention que de me servir de bloc-note lors d'une prochaine réinstallation et ajouter une ressource française sur le sujet.

Pour l'installer sous Debian :Logo debian

Si besoin ajouter le système de paramétrage CGROUP à votre liste de points de montage dans votre fichier etc/fstab (vérifiez si la ligne suivante est déjà présente):

cgroup          /sys/fs/cgroup  cgroup  defaults        0       0

Si l'on souhaite mettre nos machines virtuelles directement sur le réseau physique, nous avons besoin de créer un pont sur lequel viendra se brancher notre machine physique ainsi que nos machines virtuelles.

Le paquet bridge-utils va créer un pont/commutateur/switch entre vos machines virtuelles/physique et votre réseau local (LAN).

Schema reseau

aptitude install bridge-utils
Pour mettre en place cette configuration, vous allez devoir remplacer votre eth0 en DHCP par br0 dans /etc/network/interfaces :
auto br0
iface br0 inet dhcp
bridge-ports eth0

Installez le paquet LXC contenant un ensemble de script et de templates :

aptitude install lxc

Si vous souhaitez installer une Debian dans un de vos conteneurs, vous aurez besoin d'installer debootstrap :

aptitude install debootstrap

Maintenant, pour créer votre premier container de type Debian sans limitation :

lxc-create -n le_nom_de_votre_container -t debian

Il faudra configurer votre container avant de le lancer en allant toucher le fichier de configuration dans /var/lib/le_nom_de_votre_container/config. Les lignes importantes à modifier sont :

lxc.network.type = veth
lxc.network.flags = up
#On s'appuie sur l'interface br0 physique
lxc.network.link = br0
#On nomme notre interface virtuel eth0
lxc.network.name = eth0

Par défaut sous Debian, lxc ne vous crée pas de terminal pour vous connecter à votre machine virtuelle.
Avouez que c'est dommage !
Nous allons y remédier en créant nous même le fichier spécial correspondant à un terminal virtuel avec mknod :

mknod -m 666 /var/lib/lxc/le_nom_de_votre_container/roots/dev/tty c 4 1

Si vous souhaitez lancer votre machine avec une console virtuel mais ATTENTION vous ne pourrez pas quitter la console sans éteindre votre container :
lxc-start -n le_nom_de_votre_container

Si vous voulez avoir en tâche de fond votre machine virtuelle ou tout simplement pouvoir quitter votre console quand vous le souhaitez (via Ctrl a +q) :

lxc-start -n le_nom_de_votre_container -d

Maintenant, vous pouvez accéder à votre console :

lxc-console -n le_nom_de_votre_container

Ma difficulté à l'installation venait surtout de la création de la console virtuelle sur une version Testing.

Pour l'installer sous ArchLinux :Logo archlinux

La seule difficulté que j'ai rencontré sous Archlinux est la configuration du bridge.
Je passe brièvement l'installation des paquets vus précédemment :

pacman -S lxc bridge-utils

Si besoin rebooter votre machine pour prendre en compte vos nouveaux modules :

lsmod | grep br
bridge                 85984  0
stp                     1621  1 bridge
llc                     3729  2 stp,bridge

Normalement, l'utilitaire netcfg doit créer votre pont automatiquement avec les paramètres que l'on va spécifier ci-dessous :

pacman -S netcfg
Modifier le fichier/etc/network.d/bridge :
INTERFACE="br0"
CONNECTION="bridge"
DESCRIPTION="Mon pont davignon"
BRIDGE_INTERFACES="enp4s0"
IP="dhcp"

Modifier le fichier /etc/conf.d/netcfg :

# Network profiles are found in /etc/network.d
NETWORKS=(bridge)

Ajouter l'unité à votre démarrage afin de monter le réseau à chaque démarrage :

systemctl enable netcfg@bridge.service

Pour créer manuellement votre pont si cela n'a pas été fait :

brctl addif br0 enp4s0

Modifier le fichier /usr/share/lxc/templates/lxc-debian (L.175)afin de faire fonctionner le template:

arch="amd64"


Au plaisir.

Ps : Pas de bol pour moi, une personne vient de publier un article sur LXC sous Debian à l'instant en Français. J'aurais été en début d'écriture, je n'aurai pas écrit ...

Edit : Ajout de la modification du template debian

dimanche, 30 décembre 2012

Ttyecho : Lancer un editeur de texte CLI depuis une GUI

Echo

Bonjour,

Derrière ce titre un peu alambiqué se cache un petit plaisir personnel enfin assouvi.
Je m'explique, imaginons que vous utilisiez un explorateur de fichier de type GUI (eg. Nautilus, pcmanfm ...) parce que vous êtes un peu tordu, vous utilisez un éditeur de texte en ligne de commande (eg. vim, emacs ou nano).
Cette situation est embêtante car vous avez envie d’éditer un programme en C que vous voyez s'afficher dans votre explorateur mais vous ne pouvez double-cliquer directement dessus car cela ne va pas vous lancer votre éditeur favoris.

Alors, j'ai trouvé une solution que je vais vous détailler ci-dessous, cependant si vous avez d'autres idées je suis comme un bar dans une soirée étudiante, open !

Bon on commence par récupérer le code source magique de ttyecho :

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <string.h>
#include <unistd.h>

void print_help(char *prog_name) {
        printf("Usage: %s [-n] DEVNAME COMMAND\n", prog_name);
        printf("Usage: '-n' is an optional argument if you want to push a new line at the end of the text\n");
        printf("Usage: Will require 'sudo' to run if the executable is not setuid root\n");
        exit(1);
}

int main (int argc, char *argv[]) {
    char *cmd, *nl = "\n";
    int i, fd;
    int devno, commandno, newline;
    int mem_len;
    devno = 1; commandno = 2; newline = 0;
    if (argc < 3) {
        print_help(argv[0]);
    }
    if (argc > 3 && argv[1][0] == '-' && argv[1][1] == 'n') {
        devno = 2; commandno = 3; newline=1;
    } else if (argc > 3 && argv[1][0] == '-' && argv[1][1] != 'n') {
        printf("Invalid Option\n");
        print_help(argv[0]);
    }
    fd = open(argv[devno],O_RDWR);
    if(fd == -1) {
        perror("open DEVICE");
        exit(1);
    }
    mem_len = 0;
    for ( i = commandno; i < argc; i++ ) {
        mem_len += strlen(argv[i]) + 2;
        if ( i > commandno ) {
            cmd = (char *)realloc((void *)cmd, mem_len);
        } else { //i == commandno
            cmd = (char *)malloc(mem_len);
        }

        strcat(cmd, argv[i]);
        strcat(cmd, " ");
    }
  if (newline == 0)
        usleep(225000);
    for (i = 0; cmd[i]; i++)
        ioctl (fd, TIOCSTI, cmd+i);
    if (newline == 1)
        ioctl (fd, TIOCSTI, nl);
    close(fd);
    free((void *)cmd);
    exit (0);
}

1. On stocke tout ça dans un fichier ttyecho.c par exemple.

2. On compile :

make ttyecho

3. On fait une petite copie vers un répertoire binaire contenu dans votre PATH :

sudo cp ttyecho /usr/local/bin/ttyecho

Pour vérifier que tout est en ordre, vous pouvez ouvrir deux terminaux.

#Terminal1
tty
> /dev/pts/0

sudo ttyecho -n /dev/pts/1 echo "toto"
#Terminal2
tty
> /dev/pts/1
>toto
  • Il est à noter que nous sommes obliger d'effectuer cette opération en tant que root.
  • L'option -n, permet d'effectuer un retour chariot dans le terminal distant.

Pour remédier au problème de droit, je vous propose cette manipulation qui comme d'habitude n'est pas très secure :

chmod +s /usr/local/bin/ttyecho

Avec le sticky bit, les utilisateurs qui lanceront cette commande auront les droits du propriétaire du fichier autrement dit "root".

Et maintenant le bouquet final : Application à notre problème

  • On ouvre notre explorateur de fichier, pour moi c'est pcmanfm.
  • On fait un joli clic-droit sur le fichier que nous souhaitons editer (ttyecho.c).
  • On choisit l'item "open with" et on remplit l'onglet "custom command line" comme suit :
ttyecho -n/dev/pts/0 nano %f

Il peut paraitre sot de rappeler qu'il faut que /dev/pts/0 soit déjà ouvert ...

Enjoy !

dimanche, 18 novembre 2012

Selector : un outil bash de gestion d'historique de commandes et de repertoires visités

Ceci est une revolutionBonjour,

Cela fait depuis quelques semaines que j'accumule les billets que j'aimerai partager.
J'aurai même le temps de vous les écrire mais je n'ai pas eu l'envie suffisante; à la place je ponds des compte rendu de réunion inutiles.



Mais aujourd'hui, j'ai pris ma plume pour vous présenter une révolution (Steve si tu me regardes)

Cet outil est vraiment mon coup de cœur du moment, je vais vous détailler en deux points les défauts qu'il corrige.

  • Qui n'a jamais pesté contre le Ctrl+R de bash, il suffit que l'on ait une commande que l'on ait exécuté plusieurs fois avec des paramètres différents pour s'en rendre compte. Ce maudit raccourci vous allez devoir le taper x fois jusqu'à temps de tomber sur la bonne commande. Je ne vous parle même pas de l'utilisation non ergonomique de la commande history ...
  • Qui ne s'est jamais dit, j'en ai marre de faire des 'cd' dans tous les sens, j'étais dans /usr/lib/cups/backend/noname puis je suis allé dans /var/log/apache2/, puis dans mon home et maintenant je voudrais retourner dans /usr/lib/cups/backend/noname. J'ai passé des heures à essayer divers bricoles comme autojump et autres pour gagner du temps.

Mes biens chères sœurs (y en a !), mes biens chers frères :

Ce temps est révolu grâce à l'outil Selector de François Fleuret.


Cet outil vous offre :

  • Une interface d'historique des commandes accessible en un raccourci clavier (Alt-r), recherche immédiate dès le premier caractère (à la google), compatible avec les expressions régulières ...
  • Une interface qui présente de la même manière vos pérégrinations sous votre OS.

Maintenant que vous piaffez d'impatience place à l'installation de cet outil révolutionnaire !

1. Premier étape, installation de git (et de ncurses-dev, make pour les autres distros)

yaourt -Sy git

Parce que git c'est trop à la mode, je vous conseille la lecture de ce tutoriel pour être hype.

2. Deuxième étape, on rapatrie le code source :

cd /opt
git clone http://fleuret.org/git/selector/ 
cd selector

3. On compile le code

make selector

4. On fait un petit lien ou on copie le binaire dans un repertoire qui est dans votre path :

ln -s /usr/local/bin/selector /opt/selector/selector

5. On met le joli script d'interception des commandes dans votre .bashrc

cd
nano .bashrc
+ source bash-selector.sh --hist --cd

6. On se ressource :

source .bashrc

Copie d'ecran de l'outil selector 7. On profite : En faisant pleins d'aller et venue dans tous les répertoires puis on fait un alt+r pour consulter l’historique des commandes ou un alt+c pour consulter l'historique des navigations.

Quelques notions très basiques :

  • Pour utiliser une commande surlignée, appuyer sur la touche enter.
  • Pour quitter l'outil, utiliser la touche echap ou ctrl+c.
  • Pour plus d'information :
selector --help

Qu'on se le dise, ceci est une révolution, cela devrait être intégré dans tous les OS Unix ! Et dire que j'ai même pas trouvé un paquet pour l'installer ...

Je trouve cet outil vraiment sympa et je ne l'ai pas beaucoup vu circuler sur le web, j'ai peut être un train de retard aussi !

A bientôt !

Source image : les guignols

Merci à Linus Torvalds pour le prêt de son doigt ! Je trouve ça magique !

- page 1 de 5