Il permet également de tunneler un port local vers un port distant d’une autre machine. Ainsi tout ce qui est envoyé sur le port local va être transmis au port distant via la communication ssh sécurisée. Cette manipulation s’avère très pratique pour sortir d’un réseau dont seuls les ports 22 et 80 sont ouverts.

Je viens d’apprendre récemment comment faire l’inverse : tunneler un port d’une machine distante vers un port d’une machine locale. Ainsi tout ce qui est envoyé sur le port de la machine distante va être transmis au port de la machine locale. En résumé, si votre machine locale est sur un réseau protégé par un NAT et un firewall, çette manipulation met en place une backdoor vers le réseau protégé.

Par exemple, vous avez une machine, nommée dest, qui est sur un réseau NATé protégé par un firewall. On ne peut pas s’y connecter en ssh par l’extérieur car le pare feu bloque ce port (ou bien il le redirige sur une autre machine qui ne vous intéresse pas). Prenons maintenant une autre machine, nommée middle, qui se trouve à l’extérieur du réseau protégé. Il suffit de créer un reverse tunnel pour exposer le port 22 de la machine dest sur un autre port de la machine middle. Cette commande est à exécuter au préalable sur dest :

destuser@dest$ ssh -R 2200:localhost:22 middleuser@middle

Tant que la connexion ssh est active, le port 2200 de middle est en écoute et transmet les paquets au port 22 de dest.Ensuite de l’extérieur, depuis chez vous sur votre machine home, il suffit de se connecter à middle de manière classique, puis de se connecter une nouvelle fois en utilisant le port exposé, 2200, pour se connecter à dest.

user@home$ ssh middleuser@middle
middleuser@middle$ ssh destuser@localhost -p 2200
destuser@dest$

Voilà, vous êtes connecté à dest.

Si vous pouvez sortir sur le port 2200 directement, vous n’êtes pas obligé de faire ce double saut. Vous pouvez vous connecter directement au port 2200 de la machine middle :

user@home$ ssh destuser@middle -p 2200

Si vous ne pouvez pas sortir sur un autre port que le prt 22 et que vous voulez vous connecter en une seule commande, on peut rajouter un petit tunnel supplémentaire entre le port 2200 de la machine home et le port 2200 de la machine middle :

user@home$ ssh -L2200:localhost:2200 middleuser@middle

et on se connecte alors ainsi :

user@home$ ssh destuser@localhost -p 2200

Dans cet exemple, j’ai présenté une connexion vers le port 22, pour ssh, mais le plus souvent, vous avez déjà établi un mécanisme permettant une connexion à votre réseau domestique. Dans ce cas cette astuce peut être pratique quand vous êtes à l’extérieur, pour exposer temporairement le port d’un service de votre réseau local à l’extérieur (au hasard, des ports POP et IMAP pour relever votre mail). Attention à bien protéger les accès dans ce cas.

assertEquals(42, answer);
assertFalse(answer == 34);
assertTrue(info.matches("color") || info.matches("colour"));
assertTrue(colorsList.contains("red"));
assertTrue(s instanceof MagicString);

Mais JUnit propose depuis la version 4.4 une nouvelle syntaxe à base de Matchers. En fait, cette syntaxe n’est pas totalement nouvelle : elle est empruntée à JMock qui possède déjà les Matchers JMock pour décrire les contraintes d’un mock. L’idée vient de Joe Walnes dans son article Flexible JUnit assertions with assertThat().

Les assertions précédentes peuvent alors s’écrire de la manière suivante :

assertThat(answer, is(42));
assertThat(answer, is(not(34)));
assertThat(info, either(containsString("color")).or(containsString("colour")));
assertThat(colorsList, hasItem("red"));
assertThat(s, instanceOf(MagicString.class));

Les avantages sont multiples :

• Ça se lit mieux : le développeur communique donc mieux son intention aux autres développeurs, ce qui est essentiel !
• Contrairement aux méthodes assertEquals et consorts, on ne risque pas de tromper dans l’ordre des arguments : la syntaxe d’assertEquals est assertEquals([expected], [actual]) mais beaucoup de gens se trompent et écrivent assertEquals(answer, 42). Avec assertThat, aucun risque.
• Les matchers peuvent être modifiés: par exemple : not(s) pour inverser la condition, either(s).or(t) pour combiner des conditions, each(s) pour appliquer une condition sur chaque élément d’une collection, afterFiveSeconds(s) pour attendre 5 secondes avant de tester…
• En cas d’échec de l’assertion, les messages sont beaucoup plus lisibles. Si on reprend l’exemple précédents, avec les assertXxx classiques, les messages ressembleraient à ça :

  assertEquals(42, answer);
   => expected:<42> but was:<36>
  assertFalse(answer == 34);
   => junit.framework.AssertionFailedError:
  assertTrue(info.matches("color") || info.matches("colour"));
   => junit.framework.AssertionFailedError:
  assertTrue(colorsList.contains("red"));
   => junit.framework.AssertionFailedError:
  assertTrue(s instanceof MagicString);
   => junit.framework.AssertionFailedError:
  

  Avec assertThat, les message ressemblent plutôt à ça :

  assertThat(answer, is(42));
   => Expected: is <42>
           got: <36>
  assertThat(answer, is(not(34)));
   => Expected: is not <34>
           got: <34>
  assertThat(info, either(containsString("color")).or(containsString("colour")));
   => Expected: (a string containing "colour" or a string containing "color")
           got: "rainbow"
  assertThat(colorsList, hasItem("red"));
   => Expected: a collection containing "hello"
           got: <[bonjour, ia orana]>
  assertThat(s, instanceOf(MagicString.class));
   => Expected: an instance of sandbox.FooTest$MagicString
           got: "polop"
  

  Inutile de dire qu’il est beaucoup plus facile de débugguer des tests écrits avec assertThat…

• Il est plus facile d’écrire des Matcher maison plutôt que des méthodes assertXxxx maison. En plus ces Matchers pourront être réutilisés dans des tests JMock.
• C’est sexy

Pour plus d’informations, je vous recommande la lecture de ce billet. Il est en français, il est très détaillé et je suis tombé dessus en écrivant cet article.

Voici une petite méthode pour vérifier que votre classe est bien sérialisable

import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.fail;
 
public class Assert {
    /**
     * Assert that an object is serializable by dumping it and then reading it
     * back and finally by checking the original object and the dumped and read
     * object are equals.
     *
     * <p>Obviously, the method <code>equals()</code> has to be implemented
     * correctly for this method can work.
     * @param objOriginal the instance which will be checked against serialization;
     * must implement <code>equals()</code> or it won't work
     */
    public static void assertSerializable(Object objOriginal) {
        try {
            final ByteArrayOutputStream stream = new ByteArrayOutputStream();
            final ObjectOutputStream out = new ObjectOutputStream(stream);
            out.writeObject(objOriginal);
            out.close();
 
            final ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(stream.toByteArray()));
            final Object objSerialized = in.readObject();
            assertEquals(objOriginal, objSerialized);
        } catch (IOException e) {
            fail("unable to serialize or deserialize object " + objOriginal + ": " + e.getMessage());
        } catch (ClassNotFoundException e) {
            // unlikely to happen...
            fail(e.getMessage());
        }
    }
}

Cette méthode sérialise une classe dans un buffer, puis relit ce buffer et s’assure que l’objet lu est bien égal à l’objet sérialisé.

Si ce test échoue, alors c’est que certaines données membres de l’objet testé ne sont pas sérialisables. Par exemple, un Logger ou un Thread ne peuvent pas être sérialisés. Des données membres de ce type doivent donc être déclarés transient de la manière suivante

class Foo {
    transient private Thread thread;
    transient private Logger logger = LoggerFactory.getLogger(this.getClass());
    private String name;
 
    // etc...
}

Attention une fois l’objet sérialisé puis désérialisé, les membres transients sont perdus. C’est ainsi qu’on se retrouve avec un logger à null et un NullPointerException assez rapidement… Dans ce cas, on peut implémenter une méthode privée ayant la signature readObject(ObjectInputStream) pour y restaurer le logger. La méthode doit être privée pour éviter tout appel par une autre classe ou toute surcharge par une classe fille.

    // code...
 
    private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
        // default implementation
        in.defaultReadObject();
        // restore our logger object
        logger = LoggerFactory.getLogger(this.getClass());
    }
 
    // code...

Tout les détails de la sérialisation sont expliqués sur le site de Sun.

% irb
irb(main):001:0> 42.to_s(2)
=> "101010"
irb(main):002:0> "%b" % 42
=> "101010"
irb(main):003:0> "1001".to_i(2)
=> 9
irb(main):004:0> 0b1001
=> 9

Enfantin non ?

Sans chercher à exploiter toutes les fonctionnalités qu’il propose, certaines facilités me sont maintenant indispensables lorsque je passe à bash. Une seule en fait : le ** qui se substitue à n’importe quel dossier ou sous-dossier. Un globbing puissant qui permet de s’affranchir de find.

# liste tous les fichiers, equivalent de find .
ls **/*
# recherche la chaine 'foo' dans tous les fichiers java
grep foo **/*.java
# recherche la chaine 'bar' dans tous les fichiers java qui ont pour
# repertoire parent le dossier src
grep foo **/src/**/*.java

De plus, on peut ajouter des options de recherche

# tous les fichiers contenant le nom 'dupont' en Ignorant la casse
# correspond à dupond, DUPOND, Dupond, DuPOnD, mais pas Durand
ls (#i)dupont
# liste uniquement les fichiers
ls **/*(.)
# liste uniquement les dossiers
ls -d **/*(/)
# liste tous les dossiers pleins (Full)
ls -d **/*(F)
# liste tous les dossiers vides (not Full)
ls -d **/*(^F)

Il existe beaucoup d’autres possibilités, mais juste ces quelques commandes m’ont permis de m’affranchir du sempiternel find . -type f -iname "*dupont*" | xargs svn revert.

L’autre truc bien de zsh, évidemment, c’est l’aide à la complétion de commande. Il est remarquable dans bien des cas, notamment

• tâches ant : $ ant <TAB> => liste les tâches ant disponibles
• arguments ant : $ ant --n<TAB> => liste les options de ant commençant par –n
• adresses svn : $ svn checkout http://some.svn.server/svn/trunk/src/<TAB> => liste les fichiers disponibles

Bref ça vaut le coup d’essayer. Pour mettre un pied à l’étrier (et me servir d’aide mémoire), voici le .zshrc que j’utilise. Il n’a rien d’exceptionnel, même le prompt est des plus basiques.

# Lines configured by zsh-newuser-install
HISTFILE=~/.histfile
HISTSIZE=1000
SAVEHIST=1000
setopt appendhistory autocd extendedglob nomatch notify
unsetopt beep
bindkey -e
# End of lines configured by zsh-newuser-install
# The following lines were added by compinstall
zstyle :compinstall filename '/home/cbliard/.zshrc'

autoload -Uz compinit
compinit
# End of lines added by compinstall

# Add ~/bin directory to PATH if possible
[ -d $HOME/bin ] && export PATH=$PATH:$HOME/bin

# colors
eval "`dircolors -b`"
alias ls='ls --color=auto'

function l() {
	clear; pwd; echo; ls -lh $*; echo
}

# Set up aliases
alias mv='nocorrect mv'       # no spelling correction on mv
alias cp='nocorrect cp'       # no spelling correction on cp
alias mkdir='nocorrect mkdir' # no spelling correction on mkdir
alias grep='egrep --exclude-dir=\.svn --color=auto'
alias ll='ls -l'
alias la='ls -a'
alias less='less -i'
alias diff='diff -u -x .svn'

# Less verbose ant
alias ant='ant -logger org.apache.tools.ant.NoBannerLogger'

# List only directories and symbolic
# links that point to directories
alias lsd='ls -ld *(-/DN)'

# List only file beginning with "."
alias lsa='ls -ld .*'

# Simple bold prompt
PROMPT="%{%B%}%n@%m:%~%{%b%}%# "

# select words as in bash (for Meta-backspace and Meta-d)
autoload -U select-word-style
select-word-style bash

$ python2.6
>>> 0b101111
47
>>> int('1101', 2)
13
>>> int('0b1101', 2)
13
>>> bin(13)
'0b1101'

Cependant, avec les versions précédentes, seule la conversion de binaire vers décimal est possible facilement.

$ python2.5
>>> int('1101', 2)
13
>>> bin(13)
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'bin' is not defined

Voici donc une petite fonction bin :

def bin(n):
    """Convert an integer to its binary string representation"""
    res = []
    while n > 0:
        res.insert(0, str(int(n % 2)))
        n = n // 2
    return "".join(res)

Et ainsi :

$ python2.5
>>> def bin(n):
...     """Convertit un nombre en binaire"""
...     res = []
...     while n > 0:
...         res.insert(0, str(int(n % 2)))
...         n = n // 2
...     return "".join(res)
...
>>> bin(13)
'1101'
>>> int(bin(13), 2)
13

$ sudo gems install rails -y

Oui mais voilà, Netbeans n’utilise pas sudo. Pour que Netbeans puisse gérer les gemmes lui-même, il lui faut donc les droits d’écriture sur le dossier /var/lib/gems et ses sous-répertoires. Le plus naïf est de donner tous les droits en écriture, mais c’est mal ! Sinon, on peut aussi créer un groupe nommé rubygems et donner le droit d’écriture à ce groupe. Cette approche est meilleure mais un problème se pose lorsque l’utilisateur y crée un nouveau fichier ou dossier : non seulement celui-ci appartient à l’utilisateur et non pas à root, mais en plus le groupe n’a pas le droit d’écriture. C’est là qu’interviennent les ACLs…

Démonstration avec l’utilisateur foo.

On crée un groupe ruby gems et on s’y ajoute

$ sudo addgroup rubygems
$ sudo adduser foo rubygems

On se déconnecte puis reconnecte pour prendre en compte le nouveau groupe, puis on vérifie les permissions

$ sudo mkdir /test
$ sudo chgrp rubygems /test
$ sudo chmod g+w /test
$ ls -ld /test
drwxrwxr-x 2 root rubygems 4096 2008-12-03 22:16 /test
$ touch /test/bar
$ ls -l /test/bar
-rw-r--r-- 1 foo foo 0 2008-12-03 22:21 /test/bar

Ce n’est pas bon du tout. On préférerait avoir quelque chose comme -rw-rw-r-- 1 foo rubygems afin que les autres membres du groupe rubygems puissent eux aussi modifier ce fichier. De manière plus générale, on veut que :

• le groupe soit rubygems ;
• les permissions du groupe soient rwx pour un dossier et rw- pour un fichier ;
• et que les permissions des autres soient r-x pour un dossier et r– pour un fichier.

La partie qui va suivre est issu des connaissances acquises grâce à l’article Group sharing a directory.

Attribuer le groupe automatiquement

Il est simple d’affecter le groupe rubygems automatiquement à chaque nouveau dossier créé dès qu’on connait l’astuce : il suffit de lever le bit ’set groupid’ du groupe du dossier pour que tout nouveau fichier ou dossier créé appartienne au groupe du dossier parent plutôt qu’au groupe de l’utilisateur

$ sudo chmod g+s /test
$ ls -ld /test
drwxrwsr-x 2 root rubygems 4096 2008-12-05 07:54 /test
$ touch f
$ mkdir /test/d
$ ls -l /test
total 4
drwxr-sr-x 2 foo rubygems 4096 2008-12-05 07:59 d
-rw-r--r-- 1 foo rubygems    0 2008-12-05 07:59 f
$ cd /test/d
$ touch bar
$ ls -l
-rw-r--r-- 1 foo rubygems 0 2008-12-05 08:00 bar

Permettre l’écriture au groupe automatiquement

Cette solution fait usage des ACLs. La commande

$ sudo setfacl -m default:user::rwx,default:group::rwx,default:mask:rwx,default:other:r-x /test

permet de définir les permissions par défaut pour les futurs fichiers du dossier /test. La commande est longue et peut être abrégée en

$ sudo setfacl -m d:u::rwx,d:g::rwx,d:m:rwx,d:o:r-x /test

Si la commande setfacl ne fonctionne pas, c’est parce que l’option acl n’est pas active pour votre volume. Assurez-vous d’avoir une ligne qui ressemble contienne l’option acl dans votre /etc/fstab :

/dev/hda2 / ext3 defaults,acl 0 1

Ensuite remontez votre volume pour prendre en compte les modifications

sudo mount / -o remount

Observons maintenant d’un peu plus près la définition d’ACLs

$ sudo setfacl -m d:u::rwx,d:g::rwx,d:m:rwx,d:o:r-x /test
$ ls -ld /test
drwxrwsr-x+ 3 root rubygems 4096 2008-12-05 07:59 /test
$ getfacl /test
getfacl: Removing leading '/' from absolute path names
# file: test
# owner: root
# group: rubygems
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Le + à droite des permissions affichées par la commande ls indique qu’il y a des permissions supplémentaires visibles par getfacl. Ce dernier permet d’afficher les permissions définies avec setfacl. Essayons de créer des fichiers.

$ cd /test
$ touch polop.txt
$ mkdir hello
$ ls -l
total 16
drwxr-sr-x  2 foo rubygems 4096 2008-12-05 08:00 d
-rw-r--r--  1 foo rubygems    0 2008-12-05 07:59 f
drwxrwsr-x+ 2 foo rubygems 4096 2008-12-05 08:17 hello
-rw-rw-r--+ 1 foo rubygems    0 2008-12-05 08:17 polop.txt
$ getfacl hello
# file: hello
# owner: foo
# group: rubygems
user::rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x

Les ACLs ont bien rempli leur rôle : les nouveaux fichiers créés ont la permission d’écriture pour le groupe et ont aux aussi les ACLs définis (notez le +).

Application au dossier de gemmes de ruby

Il nous faut définir le groupe les permissions pour tout fichier ou dossier existant du dossier /var/lib/gems et les ACLs ainsi que le ’set groupid’ bit pour tout dossier, sans oublier de changer le groupe pour qu’il devienne rubygems.

$ sudo chgrp -R rubygems /var/lib/gems
$ sudo chmod -R -s,g=rwX,o=rX /var/lib/gems
$ for dir in $(find /var/lib/gems -type d) ; do
> sudo chmod g+s "$dir"
> sudo setfacl -m d:u::rwx,d:g::rwx,d:o:r--,d:m:rwx "$dir"
> done

notez que si vous étiez sous zsh, vous auriez pu écrire

$ sudo chgrp rubygems /var/lib/gems/**/*
$ sudo chmod -s,g=rwX,o=rX /var/lib/gems/**/*
$ sudo chmod g+s /var/lib/gems/**/*(/)
$ sudo setfacl -m d:u::rwx,d:g::rwx,d:o:r--,d:m:rwx /var/lib/gems/**/*(/)

Voilà ! désomais vous pouvez taper

$ gems install rails -y

en simple utilisateur, ce qui signifie que d’autres programmes tiers comme NetBeans peuvent également installer des gemmes.

Autres applications

On peut trouver d’autres application très utiles au partage de dossier par ACL. Comme ça de tête :

• Quand votre serveur web est partagé entre plusieurs personnes, partager le dossier /var/www d’apache pour que l’utilisateur système www-data ait le droit d’écriture sur tous les fichiers sans donner ces droits à tout le monde ;
• Partager des fichiers sur un disque dur externe pour que chacun puisse y gérer ses films et photos sans se retrouver bloqué quand on veut déplacer ou supprimer certains éléments créés par d’autres utilisateurs.

sudo echo 'Acquire::http::Proxy "http://proxy.mynetwork.com:1234/";' > /etc/apt/apt.conf.d/proxy

ou plus simplement en définissant les paramètres du proxy dans la variable d’environnement http_proxy (ou ftp_proxy dans le cas d’un miroir ftp).

export http_proxy='http://proxy.mynetwork.com:1234/'

Si le proxy est un proxy authentifiant, alors il faut également préciser le login et le mot de passe dans http_proxy.

export http_proxy='http://login:pwd@proxy.mynetwork.com:1234/'

Évidemment, si vous avez un dépôt debian miroir sur votre réseau interne, vous n’avez pas besoin de définir tout ça. Cependant, si vous voulez également accéder aux dépôts externes, c’est là que ça se complique : si vous définissez http_proxy, le dépôt interne devient inaccessible car apt tente de passer par le proxy, et si vous ne le définissez pas, les depôts externes sont inaccessibles car vous ne passez plus par le proxy. Il faut donc procéder autrement.

Une solution est d’utiliser la variable no_proxy. Cette variable définit les hôtes qui ne nécessitent pas un accès via proxy.

Par exemple

export no_proxy='127.0.01,.mynetwork.com,192.168.78.100'

n’utilisera pas le proxy pour accéder à 127.0.0.1, à n’importe quel hôte du domaine mynetwork.com ou à 192.168.78.100. Attention, l’utilisation de wildcards dans no_proxy ne fonctionnera pas. Ainsi écrire ce qui suit n’empêchera pas d’essayer d’utiliser le proxy pour accéder à wiki.mynetwork.com.

# wildcards dont work
export no_proxy='127.0.01,*.mynetwork.com'

Définir http_proxy et no_proxy dans $HOME/.bashrc permettra donc d’accéder à n’importe quel dépôt, qu’il soit sur le réseau interne ou à l’extérieur. Prenons l’exemple de deux dépôts, l’un sur l’hôte deb.mynetwork.com, l’autre sur l’hôte fr.archive.ubuntu.com. Il faut définir

export http_proxy='http://login:pwd@proxy.mynetwork.com:1234/'
export no_proxy='127.0.01,deb.mynetwork.com'

Mais si vous utilisez sudo apt-get pour installer un paquet, ça ne fonctionne toujours pas. C’est parce que sudo filtre les variables d’environnement pour des raisons de sécurité. Pour constater quelles variables sont filtrées et comment :

sudo sudo -V

On y voit que la variable http_proxy est préservée, mais pas no_proxy. Pour y remédier, il va falloir éditer le fichier /etc/sudoers.

sudo visudo

et rajouter la ligne suivante

Defaults        env_keep+="no_proxy"

Attention à bien mettre des double-quotes et non des simple-quotes.

Si vous êtes sous Ubuntu, le fichier devrait ressembler à ça

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults

Defaults        env_keep+='no_proxy'
Defaults        !lecture,tty_tickets,!fqdn

# User privilege specification
root    ALL=(ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

Ainsi, vous pouvez installer des paquets provenant de votre réseau local ou de l’extérieur.

L’avantage de cette solution, c’est qu’elle est valable pour tous les programmes : par exemple l’installation du paquet msttcorefonts va télécharger les polices true type microsoft sur le net en utilisant wget. Si vous êtes derrière un proxy et qu’aucun proxy n’est défini dans le fichier $HOME/.wgetrc, le fichier /etc/wgetrc ou dans la variable d’environnement http_proxy, le téléchargement échouera. En définissant la variable d’environnement http_proxy ça fonctionne comme un charme.

Petite astuce supplémentaire, si votre proxy requiert une authentification, vous n’avez pas envie que tout le monde connaisse votre mot de passe en regardant votre .bashrc.

Une solution est de mettre la définition dans un fichier $HOME/.proxy puis de l’appeler depuis le bashrc.

fichier $HOME/.proxy

#!/bin/bash
# proxy settings
export http_proxy='http://login:pwd@proxy.mynetwork.com:1234/'
export no_proxy='127.0.01,deb.mynetwork.com'

changer les droits d’accès et modifier son bashrc

chmod go-rw $HOME/.proxy
echo 'source $HOME/.proxy' > $HOME/.bashrc