Fermer une session SSH gelée

Parfois, lorsqu'on est connecté sur une machine distante via SSH, la session se gèle et il n'est plus possible de faire quoi que ce soit. Dans ce cas, il existe une combinaison de touches pour forcer la session à se fermer :

<Entrée> ~ .

Tapez les touches les unes à la suite des autres, et votre session SSH se fermera, débloquant votre terminal.

Drupal, l() et #

Sous Drupal 6, la fonction l() permet de générer des liens formatés et nettoyés tout bien comme il faut. Petit souci, l() ne semble pas pouvoir générer des liens "vides", c'est à dire ne contenant que le caractère #.

Cas d'utilisation

On a un menu dont la hiérarchie des entrées est créée automatiquement via un module (Taxonomy Menu). Seulement, il y a deux complications :

  • on souhaite que certains niveaux de cette hiérarchie ne pointent pas vers une page car ces niveaux ne contiennent pas d'information utile
  • on veut conserver un lien car on utilise le module DHTML Menu qui a besoin d'une balise <a> pour fonctionner.

Le code

La solution est de générer un lien vers une ancre vide, donc ne contenant que "#". Voici ci-dessous la seule manière de générer un tel lien avec la fonction l(), en modifiant le lien existant via theme_menu_item_link(), à placer dans le fichier template.php du thème :

function montheme_menu_item_link($link) {
  if (***ma_condition***) {

    // on change l'URL du lien pour "#"
    $link['href'] = '#';

    // on indique que c'est un lien externe pour éviter le traitement de l'adresse
    $link['localized_options']['external'] = 1;
  }
  return l($link['title'], $link['href'], $link['localized_options']);
}
Tags: 

Un tunnel SSH comme proxy

Le cas classique : un site de développement n'est accessible que depuis les IP du boulot, mais on aimerait bien travailler dessus depuis un autre endroit et pouvoir l'afficher dans son navigateur.

La solution : relayer le trafic du navigateur vers un serveur du boulot, via un tunnel SSH.

Mettre en place le tunnel SSH

Ouvrez un terminal et tapez ssh -D 9999 user@1.2.3.4

9999 sera le numéro du port où vous devrez vous rattacher, user est votre nom d'utilisateur et 1.2.3.4 l'IP ou le nom de domaine du serveur distant.

Configurer le navigateur

Dans les paramètres de proxy de votre navigateur (pour Firefox sous Linux : Édition -> Préférences -> Avancé -> Réseau -> Paramètres) déclarez un proxy manuel SOCKS, sur localhost, au port spécifié dans votre ligne de commande (ici 9999).

C'est tout ! Pour une version plus évoluée, vous pouvez utiliser ssh -fnNqT -D 9999 user@1.2.3.4

  • -f : background
  • -n : redirige les sorties vers /dev/null
  • -N : permet de ne pas pouvoir exécuter de commande à distance
  • -q : quiet mode, mode silencieux
  • -T : désactive l’ouverture d’un TTY

depuis http://www.kasmi.info/windows/tunnel-ssh/

Test rapide de NetBSD et OpenBSD

Après quelques déboires avec Ubuntu 10.04 qui veut tellement automatiser les choses que c'en est impossible de faire des réglages manuels, j'ai décidé de faire un petit retour aux sources en jetant un œil à 2 OS réputés plus basiques : NetBSD et OpenBSD.

NetBSD

J'ai commencé par NetBSD : la communauté française me semble plus présente que celle d'OpenBSD, et le project ne se traine pas une réputation d'élitisme. Et puis, techniquement, il semblait plus avancé.

L'installation de NetBSD 5.0.2 a été relativement facile mais pas des plus rapides. Par contre, après avoir rebooté et s'être loggué, je me suis vite retrouvé perdu. Le fait que le shell ne semble pas avoir d'auto-complétion activée par défaut n'arrange pas les choses. En plus, par défaut c'est une disposition de clavier américaine qui est utilisée, pas des plus pratiques.

Heureusement, la documentation est là pour m'aider et je décide donc de commencer par configurer mon clavier en suisse romand. Manque de bol, dans la doc c'est une disposition qui est censée exister, on peut même la sélectionner à l'installation, mais dans les faits elle n'existe pas. Ça ne donne pas confiance dans la qualité de l'OS.

Ralenti par la disposition de clavier incorrecte, le shell sans auto-complétion et une documentation qui, même si elle est bien faite, me laisse dans le flou, j'abandonne au bout de quelques heures. Je n'aurai pas réussi à installer X ou à installer des paquets supplémentaires via pkgsrc. Déception.

OpenBSD

Passons donc à OpenBSD 4.7. L'installation est simple, presque automatique, et un bon point supplémentaire est que j'ai pu très facilement créer une clé USB d'installation en faisant un dd avec l'image de la disquette d'installation. J'ai l'impression de mieux voir où je mets les pieds, et que le système est plus simple.

Après l'installation et le redémarrage, je peux constater que la disposition de clavier suisse romand fonctionne correctement et que le plus gros de la configuration a été fait lors de l'installation.

10 minutes plus tard, aidé par la documentation du site et par les pages de manuels de bonne qualité, j'ai configuré X et installé XFCE4 et Firefox via pkg_add. Ça fonctionne, c'est cohérent et les réglages par défaut permettent d'utiliser le système rapidement.

À consulter le site et les mailing-lists, il semble qu'OpenBSD est avant tout centré sur sa communauté : les développeurs travaillent sur les points qui les atteignent directement et le support du matériel est lié à celui qu'ils utilisent eux-mêmes. Ce n'est pas la course aux fonctionnalités techniques comme on peut le voir ailleurs.

Cela impose une progression plus lente, cependant le résultat est propre et sans compromis sur la qualité. La configuration du WIFI, par exemple, est d'une simplicité enfantine. En revanche, la gestion de l'Unicode est très récente, et la virtualisation n'est toujours pas intégrée au noyau.

Au final, je recommande OpenBSD à ceux qui aiment mettre les mains dans le cambouis et qui sont agacés par les couches et sur-couches d'automatisation que l'ont peut trouver dans certaines distributions Linux.

Tags: 

Pages

Souscrire à Je suis celui.la RSS
© 2011 Michaël Dupont. Drupal theme by Kiwi Themes.