You are currently browsing the archives.



Petite passe-passe avec Konsole

Comme je l’avais déjà presque promis, et comme certains m’ont suggéré, voilà le truc tout simple que je me suis préparé pour afficher automatiquement le nom du serveur dans un onglet de Konsole.

Il s’agit simplement d’ajouter ces lignes dans votre fichier .bashrc (désolé, utilisateurs d’autres shell, j’utilise Bash. L’adaptation est sans doute facile…):

function ssh(){
b4=`dcop $KONSOLE_DCOP_SESSION sessionName`
args=$# # Nombre de parametres.
msg=${!args}
dcop $KONSOLE_DCOP_SESSION renameSession "ssh $msg"
/usr/bin/ssh $@
dcop $KONSOLE_DCOP_SESSION renameSession "$b4"
}

Comment ça marche?

On commence par garder en mémoire la nom de l’onglet courant. On ramasse le nom qu’on veut donner à la console (ie on ramasse le dernier argument, qui devrait normalement être le nom du serveur), puis on invoque le Konsole courant avec dcop et on lui passe le nom que l’on veut voir. Une fois que ssh a retourné, on remet l’ancien nom.

La fonction bash s’appelant ssh, elle remplace carrément l’exécution de la commande ssh qui est dans le $PATH: il suffit de la renommer si ce n’est pas l’effet désiré.

L’avantage d’une petite fonction de ce genre est que ça permet de fonctionner simplement pour n’importe quelle connection.

J’ai aussi un code indentique (mouais, cut/paste: y’aurait plus élégant, mais bon, c’est juste un .bashrc…) qui a certains paramètres que j’utilise souvent prêt à l’emploi. La plupart de ces paramètres sont déjà dans mon .ssh/config, mais les mettres dans la fonctions bash permet de rendre leur utilisation plus souple quand je me promène d’un réseau à l’autre.

Le code en question:

function sshcanoe() {
myparams=’ FIXME: mes parametres SSH’
b4=`dcop $KONSOLE_DCOP_SESSION sessionName`
dcop $KONSOLE_DCOP_SESSION renameSession “$1″
/usr/bin/ssh $myparams “$@”
dcop $KONSOLE_DCOP_SESSION renameSession “$b4″
}

Évidemment, à la place du “FIXME”, il faut mettre quelque chose… :)

J’y mets les paramètres propres à notre réseau, ie mon nom d’usager, les paramètres particuliers pour SSH, etc.

Auparavant, j’utilisais un ensemble de fonctions pour configurer chaque serveur: ça permet d’avoir à n’écrire que le nom du serveur, mais ça oblige à créer une fonction pour chaque serveur. Jusqu’à 5-10 serveurs, ça va bien, mais rendu à 30, 40, 50, ça devient un peu fou à gérer… J’utilise donc ces fonctions de moins en moins, mais bon, à tout hasard:

# Fonction wrapup de SSH
function xssh() {
b4=`dcop $KONSOLE_DCOP_SESSION sessionName`
dcop $KONSOLE_DCOP_SESSION renameSession “$1″
shift
/usr/bin/ssh $@
dcop $KONSOLE_DCOP_SESSION renameSession “$b4″
}

# la fonction propre à un serveur
function nomduserveur() {
xssh nomduserveur username@nomduserveur
}

Mais bon, de cette façon, ça pourrait permettre de passer des paramètres propres à chaque serveur. Par exemple, pour configurer une couleur particulière, Konsole nous permet d’appliquer un schema:

function monserveurencouleur() {
prevschema=`dcop $KONSOLE_DCOP_SESSION schema`
dcop $KONSOLE_DCOP_SESSION setSchema DarkPicture.schema
xssh monserveur user@monserveur
dcop $KONSOLE_DCOP_SESSION setSchema “$prevschema”
}

L’appel a dcop avec le paramètre schema permet de lire le schéma courant; l’appel setSchema permet d’appliquer le schéma voulu, puis de ramener le schéma d’origine. J’appelle ici ma fonction xssh(), mais dans le fond, je pourrais appeler ma fonction ssh(), ou encore mon sshcanoe().

La genèse de Genesis

Trouvé sur BoingBoing, une page retraçant l’origine du nom d’un série de band rock. Fun. :)

Le setup Linux parfait

Bon, en ce samedi matin, je lis mes nouvelles avec mon café, et la caféine doit me stimuler trop, ou me faire défoncer l’enthousiasme… Ou encore, c’est la perspective de m’occuper de ma piscine/gazon/feuilles mortes/travaux de peintures qui me pousse l’intérêt ailleurs.. Peut importe… :D

Mais bon, ce matin, j’ai lu ce texte sur lwn.net.
Ce n’est pas le texte référé lui même qui m’a allumé (ça parles de la façon que Canonical peut avoir du succès avec Ubuntu): ce qui m’a allumé, c’est le commentaire de l’usager “drag”, auquel j’ai répondu une réponse un peu “me-too” (je suis holstein).

L’idée, c’est d’avoir un genre de Ubuntu-SMB (Small Medium Business), avec une version serveur et une version cliente.

La version serveur te fait une installation assez classique d’Ubuntu, mais orienté serveur: elle te demande comment marche ton réseau, ta zone horaire, etc, puis quels services tu veux avoir (genre, partages réseau, emails, serveur web, etc.).

Puis, tu prend la version cliente, et tu la configures pour qu’elle se connecte automatiquemetn au serveur. Elle l’utilise alors automatiquement pour la gestion des usagers, le DHCP (bon, c’est déjà fait ici…), l’accès Internet, etc.
Le client peut alors automatiquement savoir quels sont les paratages réseaux disponibles, il est déjà prêt pour lire ses courriels, surfer sur Internet, etc. Tout est déjà prêt pour que les gens du bureau puisse partager des documents (d’OpenOffice ou autre), travailler en collaboration (on pense à y mettre un calendrier, un wiki/forum/watever).
L’idée de pousser pour le genre de petit-bureau-pas-de-budget peut même être étiré en détectant automagiquement que la machine cliente est un peu petite et on peut alors la faire tomber (dynamiquement, ou à l’installation) en configuration “je roules tout à partir du serveur” (via X) ou carrément la transformer en client LTSP.

A vu de nez, il me semble que l’idée est bonne… Est-ce qu’un de mes rares lecteurs (je vous comprends.. :D ) a une opinion?

Mise-à-jour (déjà!):

J’ai trouvé sur le wiki d’Ubuntu une proposition qui va dans le même sens. C’est marqué “low-priority” et ça date de 2005, alors j’imagine que si ça m’intéresse, me reste plus qu’à voté avec mes pieds et mettre l’épaule à la roue… :P

Seconde mise-à-jour (encore!)

Une discussion sur le sujet existe sur le forum d’Ubuntu.