Aller à la recherche

Des Logiciels Libres

Pour parler de Logiciels Libres en milieu professionnel... ou pas!

mardi, février 5 2013 00:37

Mais où est passé systemd-analyze?

Si vous venez de faire une installation toute fraîche de Fedora 18 vous serez peut être étonné que la commande systemd-analyze n'est plus disponible de base. Cette commande très utile est dans le paquet "systemd-analyze", qu'il suffit d'installer:

yum install systemd-analyze

Et voilà! Utile pour diagnostiquer un démarrage lent:

$ systemd-analyze blame
  2055ms postfix.service
   601ms systemd-udev-settle.service
   530ms firewalld.service
   476ms fedora-storage-init.service
   451ms iscsid.service
   335ms bluetooth.service
   229ms abrt-ccpp.service
   222ms systemd-binfmt.service
   204ms NetworkManager.service
   199ms fedora-storage-init-late.service
   195ms systemd-logind.service
   185ms avahi-daemon.service
   169ms ntpd.service
   162ms cpupower.service
   159ms acpid.service
   158ms fedora-loadmodules.service
   127ms systemd-udev-trigger.service
   105ms sshd.service
   103ms systemd-readahead-collect.service
   101ms abrt-vmcore.service
    98ms ksmtuned.service
    93ms gdm.service
    93ms lvm2-monitor.service
    92ms sys-kernel-debug.mount
    90ms systemd-readahead-replay.service
    85ms ksm.service
    80ms dev-mqueue.mount
    79ms udisks2.service
    78ms proc-sys-fs-binfmt_misc.mount
    68ms dev-hugepages.mount
    67ms systemd-vconsole-setup.service
    66ms systemd-remount-fs.service
    66ms systemd-tmpfiles-setup.service
    65ms home.mount
    62ms rpcbind.service
    60ms fedora-readonly.service
    59ms bacula-fd.service
    53ms colord.service
    52ms iscsi.service
    51ms tmp.mount
    51ms systemd-sysctl.service
    48ms polkit.service
    47ms systemd-modules-load.service
    45ms boot.mount
    45ms auditd.service
    42ms sys-kernel-config.mount
    29ms wpa_supplicant.service
    27ms accounts-daemon.service
    27ms systemd-udevd.service
    23ms upower.service
    12ms rtkit-daemon.service
     9ms systemd-user-sessions.service

Pas mal cette Fedora 18, assez propre sans rien faire (et encore j'ai perdu 2 secondes au boot en installant postfix). La transition vers systemd est de plus en plus complète, vu ce qu'il reste dans init.d:

$ ls /etc/init.d/
ebtables  functions  iscsi  iscsid  libvirt-guests  netcf-transaction  netconsole  network  README

A suivre!

lundi, février 4 2013 19:44

Automount via systemd

Quand il est nécessaire d'accèder à des systèmes de fichiers particuliers, à travers le réseau (NFS, CIFS, etc) ou sur une ressource pas toujours disponible (disque externe USB), voire même pour soulager les requêtes sur ce montage, il est utile de passer par la fonctionnalité "automount". Comme son nom l'indique, cela permet de monter automatiquement un point de montage, dès la première requête d'accès sur ce dernier. L'inverse est aussi de mise, démonter le point de montage quand celui-ci n'a pas été accédé depuis un certain temps (timeout).

Avant il fallait passer par autofs/automount, et configurer un ou plusieurs fichiers de configuration pour indiquer les points de montage à gérer. Rien de très complexe ceci dit. Mais aujourd'hui, le fameux remplaçant de SystemVinit, systemd, a de nombreux avantages dont celui de prendre en charge nativement les points de montage, particulièrement pratique pour remplacer autofs/automount.

Il y a deux possibilités pour configurer un point de montage automatique avec systemd:

  • via les fichiers unit de systemd, avec la création d'un fichier .automount et son associé en .mount
  • via directement le fichier /etc/fstab

Comme ici, le but est de faire plus simple qu'à l'époque de autofs, nous allons juste voir la méthode via fstab. Attention c'est simple, il suffit d'ajouter une ligne classique du montage souhaité, et dans les options d'ajouter la mention x-systemd.automount. Et voilà le tour est joué.

Exemple avec un montage nfs4:

srvnfs:/nfs/exports/home /mnt/nfs/home nfs4 x-systemd.automount 0 0

Exemple avec un disque externe usb (ex /dev/sdb1):

UUID=a2969b8d-c90a-432e-8198-f697c23f8c96 /mnt/externe		  ext4	  noauto,x-systemd.automount 0 0

(blkid /dev/sdb1 pour avoir l'UUID).

Au prochain reboot, au moindre accès dans le point de montage indiqué par x-systemd.automount, ce dernier sera automatiquement monté. C'est magique!

vendredi, octobre 19 2012 19:51

Configurer sysctl avec systemd

Sur la prochaine Fedora 18, l'ancestral fichier /etc/sysctl.conf n'existe plus. Il faut maintenant déposer les modifications souhaitées dans un fichier .conf dans le répertoire /etc/sysctl.d.

Ce qui est dommage pour l'instant, c'est que la commande sysctl -p, que nous avions l'habitude de lancer pour prendre en compte les nouvelles modification, n'a pas connaissance de tout ceci. Elle finit donc en erreur. Ceci est dû au fait que les fichiers présents dans /etc/sysctl.d sont en réalité pris en charge par le service systemd-sysctl. Donc pour activer tout changement:

systemctl restart systemd-sysctl.service

Exemple concret pour l'activation des Magic Sysrq Keys:

echo "kernel.sysrq = 1" > /etc/sysctl.d/magic.conf
systemctl restart systemd-sysctl.service

Pour vérifier:

sysctl kernel.sysrq

Que de surprises avec cette Fedora 18!

vendredi, septembre 14 2012 17:49

Compiler OpenElec pour Raspberry Pi

Les pré-requis pour la compilation

Pour récuperer les sources il faut un client git:

yum install git

Il faut ensuite les paquets classiques pour compiler:

yum install gcc-c++ flex bison gawk gperf autoconf automake m4 \
cvs libtool texinfo gettext libxslt expat zlib-devel ncurses-devel zip

La commande pour récupérer les sources est la suivante:

git clone git://github.com/OpenELEC/OpenELEC.tv.git

Avant de compiler il faut se placer dans la repertoire des sources:

cd OpenELEC.tv

Pour mettre à jour de temps en temps les sources, il suffira de faire un git pull.

La compilation

Les sources d'OpenElec peuvent couvrir plusieurs projets, celui qui nous interesse ici est le projet "RPi". L'architecture pour la compilation sera "arm". La commande pour la compilation (spécifique à OpenElec) est la suivante:

PROJECT=RPi ARCH=arm make

La compilation peut être assez longue. Si tout ce passe bien, la compilation se termine par la création de l'image système au format SquashFS. Ce qui nous intéresse maintenant se découpe en 3 parties:

  • Une partie qui gère le boot
  • le kernel
  • le système incluant xbmc

Ces 3 parties vont être copiées dans la partition "System" qui peut être vu comme une partition /boot en gros.

Préparation de la carte SD

Pour fonctionner, il faut une carte SD partitionnée (avec fdisk par exemple) comme suit:

  • une partition vfat de 128Mo, flaguée bootable
  • une partition ext4 utilisant le reste de la carte SD

La partition en vfat de 128Mo devra être labelisée en tant que "System", l'autre partition en ext4 en tant que "Storage".

Pour formater en vfat avec le label "System":

mkfs.vfat -n System /dev/<carte SD partition 1>

Pour formater en ext4 avec le label "Storage":

mkfs.ext4 -L Storage /dev/<carte SD partition 2>

L'installation sur la carte SD

Le bootloader

La première partie à copier sur la carte SD gère le boot, elle se décompose en 3 fichiers:

  • arm128_start.elf
  • bootcode.bin
  • loader.bin

Ces 3 fichiers sont à copiés sur la carte SD dans la partition System, par exemple montée dans /media/System. Le arm128_start.elf est à renommer en start.elf. Les commandes de copies sont les suivantes:

cp build.OpenELEC-RPi.arm-devel/bcm2835-bootloader-*/arm128_start.elf /media/System/start.elf
cp build.OpenELEC-RPi.arm-devel/bcm2835-bootloader-*/bootcode.bin /media/System/
cp build.OpenELEC-RPi.arm-devel/bcm2835-bootloader-*/loader.bin /media/System/

Le répertoire bcm2835-bootloader-* contient dans son nom un numero de release qui varie en fonction des sources récupérées, d'où le "*". Si un "make clean" est exécuté avant chaque compilation, il n'y aura qu'un seul répertoire bcm2835-bootloader-<release>, dans le cas contraire, et si les sources concernant le bootloader ont été mises à jours, il pourrait y en avoir plusieurs.

Le kernel

Le kernel sous format de fichier image, se trouve dans le répertoire target. Son nom de fichier contient un numero de release et peut donc varier en fonction des sources utilisées. Il est à copier sur la carte SD dans la partition System, en le renommant en kernel.img. La commande est la suivante:

cp target/OpenELEC-RPi.arm-devel-*.kernel /media/System/kernel.img

Le système

Le système est dans un fichier image au format SquashFS. Cette image est créée en fin de compilation et se trouve dans le repertoire target. Son nom de fichier contient lui aussi un numéro de release, qui peut donc varier en fonction des sources utilisées. Cette image du système est à copier sur la carte SD, toujours dans la partition System, renommée en SYSTEM. La commande est donc la suivante:

cp target/OpenELEC-RPi.arm-devel-*.system /media/System/SYSTEM

Conclusion

Rien de bien compliqué en soit, grâce au fichier configurant le projet "RPi" et à l'excellent travail de l'équipe OpenElec. Il ne reste plus qu'à démonter la carte SD et l'insérer dans le Raspberry Pi.

Ce billet est en gros une traduction allegée de la documentation issue du wiki officiel consultable ici.

jeudi, juillet 5 2012 10:21

Ralonger l'historique du shell

En shell, l'historique joue un rôle bien pratique en nous permettant de rappeler et/ou de retrouver d'anciennes commandes. Par défaut il ne conserve que 1000 entrées, ce qui suffit bien souvent. Mais sur des serveurs très utilisés, ou pour n'importe quelle autre raison, il est possible de changer cette valeur. Pour cela il suffit d'ajouter dans votre ~/.bashrc la ligne suivante (où de la corriger si elle existe déjà):

export HISTSIZE=3000

Cette valeur sera prise en compte au prochain login, mais pour que ce soit pris en compte immédiatement, au choix:

  • source ~/.bashrc
  • ou taper la commande export HISTSIZE=3000

Pour s'en assurer:

echo $HISTSIZE

Pour voir la taille actuelle de l'historique:

history | wc -l

J'avais déjà cité il y a quelques temps des raccourcis bien pratiques, certains utilisent l'historique.

PS: cette méthode a été testé sous bash uniquement.

dimanche, mars 25 2012 10:42

Problèmes de rafraichissement partiel de l'ecran sous Gnome 3

Si vous rencontrez des problèmes de rafraichissement partiel de l'ecran sous Gnome 3, particulièrement visible sous gnome-terminal, voici une astuce qui vaut le coup d'être testée.

Lire la suite...

mardi, juin 7 2011 10:45

Supprimer la liste des utilisateurs sous GDM

Une courte astuce pour masquer la liste des utilisateurs courants sous l'écran de connexion GDM.

Lire la suite...

dimanche, janvier 16 2011 15:06

Création d'un fichier swap

Un espace de swap est utilisé sous Linux quand il n'y a plus ou pas assez d'espace en mémoire vive. Il est donc important mais pas obligatoire d'en avoir un. Il est d'usage d'avoir au moins une partition de type swap, mais il est tout à fait possible de s'en passer ou d'en avoir plusieurs.

Dans certains cas, comme un besoin temporaire de swap, des tests, un manque de place pour ajouter une partition swap dédiée, ou un bête oubli lors de l'installation, nous pouvons être amener à créer un fichier de swap, plutôt qu'une partition.

Création du fichier

La création du fichier peut se faire avec l'outil dd, en ligne de commande, afin de définir une taille, prenons par exemple 512Mo:

dd if=/dev/zero of=/swap bs=1M count=512

A l'issue de cette commande, nous aurons un fichier /swap de 512Mo rempli de zéros.

Formatage du fichier

La swap utilise son propre système de fichier, simplifié et adapté à la gestion de données en mémoire. Notre fichier /swap doit donc être formaté et marqué pour être identifié comme espace swap:

mkswap /swap

Montage du fichier

Nous pouvons maintenant utiliser ce fichier directement à chaud avec la commande suivante:

swapon /swap

A l'inverse pour l'arrêter:

swapoff /swap

Pour vérifier que cette nouvelle swap est bien utilisée nous pouvons utiliser plusieurs commandes:

free
swapon -s

Ajout dans fstab

Pour utiliser ce fichier de swap de manière plus permanente (c'est à dire même après un redemarrage), il faut l'ajouter dans /etc/fstab. Il suffit d'y ajouter la ligne:

/swap swap swap defaults 0 0

Avec ça, au prochain reboot, le fichier /swap sera monté en swap, il est de type swap et utilisera les options par défaut.

mardi, octobre 12 2010 14:57

Rechercher une adresse MAC avec grep

Pratique de pouvoir rechercher ou valider une adresse MAC avec une commande shell, et comme grep supporte très bien les expressions régulières cela est même facile à utiliser.

Pour construire notre expression régulière, il faut réfléchir sur ce que nous cherchons. Une adresse mac est toujours représentée comme suit: XX:XX:XX:XX:XX:XX soit 6 champs de 2 caractères. Mais il y a le séparateur ":" que nous devons aussi prendre en compte. Le plus simple est de ce dire que nous cherchons en fait 5 blocs de 2 caractères suivit du ":" avec à la fin un bloc de 2 caractères.

Concernant les caractères constituant nos blocs, vu qu'il s'agit en fait d'une notation hexadécimale, il faut aussi en tenir compte. Pas la peine par exemple de rechercher toute lettre de l'alphabet, l'hexadécimal s'arrête à F. Nous pouvons aussi avoir des chiffres de 0 à 9. Pour signifier en expression régulière que nous recherchons des chiffres de 0 à 9 il faut utiliser la syntaxe suivante:

[0-9]

Pour les lettres de A à F celle-ci:

[A-F]

Il suffit de mélanger les 2 pour avoir la plage hexadécimale de 0 à F, et nous allons rajouter les minuscules, ce qui donne:

[0-9a-fA-F]

Cette expression donne un résultat dès qu'elle tombe sur un chiffre de 0 à 9, ou 1 lettre de a à f, ou 1 lettre de A à F. C'est déjà un bon début.

Pour indiquer dans une expression régulière le nombre d'occurrence que nous recherchons, il suffit de préciser ce nombre entre accolade. Nos blocs sont toujours constitués de 2 caractères, donc:

[0-9a-fA-F]{2}

Il nous manque plus que le séparateur ":" qui est un caractère spéciaux en expression régulière, il faut donc l'échapper avec \. Notre premier bloc sera donc:

[0-9a-fA-F]{2}\:

Ce premier bloc dans une adresse mac est présent 5 fois, nous allons donc dire que tout ce bloc doit être vu 5 fois de suite. Pour délimiter un bloc, il faut utiliser les parenthèses:

([0-9a-fA-F]{2}\:){5}

Nous terminons avec le dernier bloc, qui est en fait similaire au premier mais sans le séparateur:

([0-9a-fA-F]{2}

L'expression régulière complète est donc:

([0-9a-fA-F]{2}\:){5}[0-9a-fA-F]{2}

Nous pouvons la tester avec grep et l'option -E ou directement avec la commande egrep. Par exemple sur les fichiers de configuration réseau d'une Fedora:

cd /etc/sysconfig/network-scripts/
egrep -ho "([0-9a-fA-F]{2}\:){5}[0-9a-fA-F]{2}" ifcfg-eth*

options: -h pour ne pas indiquer le nom du fichier et -o pour n'afficher que ce qui correspond au résultat et non toute la ligne complète

dimanche, août 22 2010 21:15

Bash plus intelligent?

Il est possible de rendre bash plus intelligent, en permettant le complètement des commandes (completion en anglais) jusque dans leurs arguments, du moins pour certaines. Pour cela il faut installer le logiciel bash-completion. Le paquet pour Fedora est bien adapté aux commandes Fedora ce qui le rend très utile. Il n'y a rien de magique, ce n'est pas non plus de l'introspection dynamique, bash-completion repose sur une sorte de base de données qui référence les commandes et leurs arguments.

Enfin bref, pour l'installer, sous Fedora, il suffit de taper la commande suivante:

yum install bash-completion

Pour l'activer sans avoir à se deloguer:

source /etc/bash-completion

Voici des exemples surpuissants que vous pouvez vous aussi utiliser chez vous:

ser[tab] ht[tab] res[tab] => service httpd restart
yu[tab] ins[tab] ligh[tab] => yum install lighttpd

Et oui encore un truc de faignasse d'admin :)

Une dernière petite astuce pratique, toujours sur la completion. Qui n'a jamais tapé trop vite au clavier un chemin, par ex "/Etc" au lieu de "/etc" à cause de la touche shift pour faire le "/"? Et bien il est possible de rendre insensible à la casse le complètement des commandes et chemins sous Bash. Pour cela il faut éditer le fichier "/etc/inputrc" pour imposer ce réglage de manière globale ou sinon "~/.inputrc" pour votre utilisateur seulement et ajouter une ligne (à la fin par exemple):

set completion-ignore-case on

Il faut se déloguer par contre, a moins que quelqu'un connaisse l'astuce pour faire relire ce fichier par bash. Pour vérifier que ça marche:

cd /E[tab] => cd /etc

Et voilà :)

mardi, août 4 2009 10:04

Passer de la Fedora 11 à la Fedora Rawhide future F12

Un changement important est apparu dans le format de compression des RPMs, qui passe ainsi de GZIP à XZ (nouveau format de compression LZMA). Il faut donc avant toute tentative de mise à jour vers la rawhide faire en sorte que votre système sache prendre en compte ce nouveau type de RPMs. Sans quoi vous aurez ce genre d'erreurs:

rpmlib(PayloadIsXz) <= 5.2-1 is needed by <blop>

Avant d'activer le dépot RawHide, il faut mettre à jour rpm grâce au dépot updates-testing:

yum --enablerepo=updates-testing update rpm

A partir de là, vous pouvez activer le dépôt RawHide et mettre à jour votre système avec un bon gros "yum update".

Pour information, le nouveau format de compression XZ est censé apporter les mêmes avantages que la compression BZIP2 sans la forte utilisation CPU lors de la décompression (uniquement). Donc en théorie un gain de temps et d'espace lors des mises à jour, a voir... Et pour plus d'information: https://fedoraproject.org/wiki/Features/XZRpmPayloads

jeudi, mai 21 2009 15:07

Connexion SSH à travers un Proxy Web

Il est possible de faire passer une connexion SSH à travers un proxy web du moment que celui-ci autorise la méthode CONNECT. Cette méthode est utilisée lors des connexions HTTPs par exemple et sert à établir un tunnel HTTP. Il est de ce fait assez courant qu'un proxy (ou serveur mandataire) laisse passer ce genre de communication. Tant mieux car c'est ce que nous allons utiliser.

Pour nous faciliter cette tâche, il existe un utilitaire qui s'occupe d'établir une fausse connexion HTTP entre votre machine et la machine distante. Car un proxy n'est juste qu'un relai, entre une machine sur le réseau local qui demande une requête HTTP, et le serveur distant. Ce logiciel demande donc à notre proxy web, s'il peut se connecter à la machine distante pour communiquer avec elle. Le serveur proxy s'exécute en pensant qu'il va s'agir d'une communication HTTPs, notre logiciel communique donc maintenant avec la machine distante et passe maintenant le relai à la commande ssh. Cet utilitaire s'appelle "corkscrew" (tire-bouchon en anglais), son site officiel est ici.

corkscrew

L'avantage de cette méthode, c'est que la machine distante n'a pas à avoir de configuration spécifique. Le seul problème est quand le proxy web n'est pas autorisé à joindre le port 22 (ssh) sur une machine distante, car c'est assez rare que des machines s'échangent des données en HTTP avec ce port. Dans ce cas, il suffit soit de faire une redirection de port sur la machine distante (ip proxy => port 443 => port 22/ssh), soit de lancer le démon ssh en écoute sur un autre port. Il suffira de choisir le port 443 qui correspond habituellement au HTTPs pour être tranquille avec ce genre de filtrage.

Comment parler à votre proxy

Pour tester votre proxy:

[tipiak@client ~]$ nc proxy.reseau.local 3128
CONNECT serveur.distant.com:22 HTTP/1.1
Host: serveur.distant.com:22 (appuyer sur entrée 2 fois)
....
blabla...
Access Denied
...

Si le proxy vous répond par une page html, comme quoi vous n'avez pas acces, c'est donc que les communications vers le port 22 sont interdites. Restera la méthode vers le port 443 qui sera en fait redirigé vers votre démon ssh:

[tipiak@client ~]$ nc proxy.reseau.local 3128
CONNECT serveur.distant.com:443 HTTP/1.1
Host: serveur.distant.com:443

HTTP/1.0 200 Connection established

Voilà, c'est mieux.

Configuration du client SSH

La configuration du client SSH permet d'indiquer une commande qui sert à établir une connexion à un intermediaire. C'est avec ce paramètre que nous allons indiquer qu'il faille utiliser corkscrew. Soit vous modifier la configuration du client ssh sur la machine de manière globale, et donc toutes les connexions ssh passeront par corkscrew, soit vous utilisez un fichier de configuration annexe qui sera utilisé au cas par cas. Le fichier de configuration du client est /etc/ssh/ssh_config. Pour avoir la manière globale suffit de le modifier directement, sinon il faut le copier dans un autre fichier (par exemple cp /etc/ssh/ssh_config ~/corkscrew.conf).

Pour utiliser corkscrew, il faut ajouter cette ligne:

# remplacer proxy.reseau.local par l'adresse du proxy
# remplacer 3128 par le port du proxy
ProxyCommand /usr/local/bin/corkscrew proxy.reseau.local 3128 %h %p

L'appel à la commande "ssh serveur.distant.com" sera donc remplacé par "/usr/local/bin/corkscrew proxy.reseau.local 3128 serveur.distant.com 22", dans le cas de la configuration globale. Si vous avez opté pour la manière au cas par cas, il faut indiquer à la commande ssh notre fichier de configuration spécifique:

ssh -f ~/corkscrew.conf toto@serveur.distant.com

Si comme expliquez plus haut, le port 22 est interdit, on précisera le numero de port distant (ici 443):

ssh -f ~/corkscrew.conf toto@serveur.distant.com -p443

Et voilà.

Configuration éventuelle du serveur SSH

Cette configuration n'intervient que si le port 22 par défaut pour le protocole SSH est interdit par le serveur proxy. Il existe 2 méthode pour utiliser un autre port pour votre serveur SSH:

  • Associer le démon sur un autre port pour l'écoute en plus du port 22
  • Utiliser le pare-feu pour rediriger un flux vers le port 22

Associer le démon ssh au port 443

Il faut editer le fichier /etc/ssh/sshd_config et s'assurer d'avoir les lignes suivantes:

Port 22
Port 443

Il ne reste plus qu'à relancer le service sshd:

[root@serveur ~]# service sshd restart

Rediriger la connexion vers le port 22

Cette méthode est plus complexe mais si vous avez déjà un serveur web en HTTPs sur votre serveur distant vous n'aurez pas trop le choix. Pour cela on rajoute une configuration dans le pare-feu:

*nat
:PREROUTING ACCEPT [7:913]
:POSTROUTING ACCEPT [1:83]
:OUTPUT ACCEPT [1:83]
# Requetes entrantes
-A PREROUTING -s <IP PUBLIQUE DU PROXY> -p tcp -m tcp --dport 443 -j DNAT --to-destination <IP PUBLIQUE DU SERVEUR>:22
# Requetes sortantes
-A POSTROUTING -s <IP PUBLIQUE DU SERVEUR> -p tcp -m tcp --sport 22 -d <IP PUBLIQUE DU PROXY> -j SNAT --to-source <IP PUBLIQUE DU SERVEUR>:443
COMMIT
*filter
[...]
# HTTPS
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
[...]

Cette configuration se fait dans le fichier /etc/sysconfig/iptables associée au service iptables (à relancer après les modifications). Ceci est bien sûr un exemple, qu'il faudra adapter.

Autres méthodes

Il existe d'autres utilitaires que corkscrew, comme hts ou httptunnel (cf billet du blog de Nicolargo). Les man-pages de ssh_config semble aussi nous indiquer que c'est possible avec netcat/nc.

L'ultime solution, si le proxy n'accepte pas les tunnels HTTP, reste l'utilisation d'un shell dans une page web, avec l'excellent AjaxTerm (attention à la sécurité).

samedi, mai 16 2009 15:45

Partager une souris et un clavier entre plusieurs PC

De nos jours il est presque normal d'avoir plusieurs machines sur son bureau, ne serait-ce un poste de travail fixe, et un ordinateur portable. Plutôt que de multiplier les allers-retours entre les claviers et souris de toutes ces machines, il existe un outils permettant d'utiliser qu'un seul de ces éléments. Cet outil s'appelle "Synergy", il est libre et en plus multi-plateformes. Pour ceux qui connaissent, il s'agit d'une sorte de KVM en version logiciel.

Pour plus d'information: http://synergy2.sourceforge.net/ (le site officiel du projet).

Cet outil existe depuis assez longtemps, et sa configuration n'a jamais été très compliqué, mais avec l'interface graphique plus récente "QuickSynergy" ça devient presque ridicule de simplicitié.

On commence simplement par installer quicksynergy, sur les 2 machines, ce qui par dépendance devra tirer synergy.

[root@pc] # yum install quicksynergy

Sur le poste qui servira d'entrée principale pour la saisie, là où le clavier et la souris seront donc mutualisés, il suffit de lancer quicksynergy. Cette application possède 2 onglets, pour le "serveur" qui partage son clavier et sa souris, il faut aller sur l'onglet "share" (partage). Cet onglet présente 4 boites de saisies aux positions relatives des autres machines; celles dont vous aurez entré le nom d'hôtes seront accessibles en déplaçant la souris sur le bord choisi de l'écran.

QuickSynergy-Share

Cette capture autorisera donc le client Synergy sur la machine "portable" à communiquer avec notre serveur Synergy. Sur la machine portable, il suffira de lancer quicksynergy, sur l'onglet "use" (utiliser), et d'entrer l'adresse IP du poste partageant son ensemble clavier/souris.

QuickSynergy-Use

Si la liaison est effective, deplacer la souris sur le bord de l'ecran que vous avez choisi et ho miracle! la souris bougera sur l'autre machine. Du coup le clavier aussi. On peut difficilement faire plus simple.

Pour le parefeu, si vous en avez un sur le poste de partage, il faut autoriser le port 24800 en tcp.

mardi, février 10 2009 11:48

cyrus imap de fedora8 à fedora 10

Résolution d'un problème de migration d'un serveur IMAP Cyrus de Fedora 8 à Fedora 10.

Lire la suite...

lundi, janvier 26 2009 23:36

TCP/IP over Bluetooth

Comment monter un réseau TCP/IP sur une liaison Bluetooth.

Lire la suite...

Changer le thème du démarrage sous Fedora

Configuration du thème graphique à utiliser au démarrage avec Plymouth.

Lire la suite...

vendredi, janvier 9 2009 17:34

Raccourcis Bash bien pratiques

Quelques raccourcis clavier indispensables.

Lire la suite...