Rencontres R BoRdeauxBoRdeaux (France): the first French R useR conference

Posted in R and tagged conférence, R on Mar 30, 2012

La première conférence française des utilisateurs de R aura lieu à Bordeaux les 2/3 juillet 2012. L’esprit de ces Rencontres est de fournir un lieu d’échange et de partage d’idées sur l’usage du logiciel R dans différentes disciplines (Visualisation & graphiques, Statistique appliquée, Biostatistique, Statistique bayésienne, Bioinformatique, Analyse des données, Modélisation, Machine learning, High performance computing…). Le programme sera constitué de conférences plénières, de communications libres, de Lightning Talks et de posters.

Les soumissions sont encore ouvertes (jusqu’au ~~30 mars~~ 10 avril). Plus d’informations sur le site web de la conférence : http://r2012.bordeaux.inria.fr

Agrandir le plan The first French R useR conference will be held in Bordeaux on July 2-3. The Rencontres R are conceived as a place to present and share ideas on using the R statistical software. This meeting is designed to be a nationwide event where various topics belong, such as graphical tools, applied statistics, biostatistics, bayesian statistics, bioinformatics, data analysis, modeling, machine learning, high performance computing, … The Rencontres R will contain guest lectures, 20min regular talks, Lightning Talks and posters.

Submissions are still open (until March, the 30th). More information on the conference website: http://r2012.bordeaux.inria.fr

Agrandir le plan

Utilisation basique de GitBasic Git user guide

Posted in Lignes de commande, Linux, Mac OS X and tagged commandes, git on Mar 29, 2012

Git est un utilitaire de gestion de versions. Ce tutoriel liste les commandes de base pour l’utilisation de Git (la partie installation est décrite dans ce post).

Pour utiliser un dépôt git installé sur un serveur distant, il faut d’abord installer et configurer un client git sur votre machine. Ensuite, les commandes de bases pour récupérer le dépôt, modifier un ou des fichiers, gérer les conflits et taguer une version sont décrites.

Configurer git

Pour pouvoir récupérer le dépôt git, l’utilisateur tux doit posséder un client git

apt-get install git

pour ubuntu ou bien ce lien pour Mac OS X (voir ce post pour l’installation sur une version ancienne de Mac OS X) et ce lien pour Windows. Une fois installé, les commandes suivantes permettent d’initialiser la configuration (nom de l’utilisateur et adresse email) :

git config --global user.name "Tux Dude"
git config --global user.email tux-email@whatnot.com

Enfin, pour configurer l’éditeur de test par défaut des messages de commit (j’utilise nano : basique mais rapide), utiliser la commande :

git config --global core.editor nano

Récupérer un dépôt

Pour récupérer le dépôt nommé testproject sur le serveur server.domain-name.org, on utilise alors la commande suivante (dans un terminal dans le dossier où l’on souhaite installer le dépôt git) :

git clone gitosis@server.domain-name.org:testproject.git

(Attention ! Il faut avoir les droits d’accès au serveur ; par exemple, par mot de passe ou en chargeant une clé ssh). La commande donne une réponse du type :

Un dossier nommé testproject.r est alors créé dans le répertoire courant (dans l’exemple de l’image, le projet s’appelle stage-nicolas). Pour visualiser ce qui a été récupéré, on entre dans le répertoire et on lance l’utilitaire graphique gitk :

cd testproject

gitk &

gitk donne accès à une fenêtre récapitulant les diverses versions, leurs auteurs et leurs dates, ainsi que, pour chaque version, le fichier log de la version, la liste des fichiers modifiés, la nature de la modification ainsi que, pour les fichiers texte, les résultats de diff par rapport à la version précédente ou suivante :

Chaque version du dépôt est identifié par un code SHA1 de 40 caractères du type 76983e194193f6d62f9df57830f3902bc701c2a2 ; cet identifiant est le SHA hash de l’intégralité des objets contenus dans cette version du dépôt. On peut faire référence à une version pour la récupérer, la fusionner avec une autre, la taguer, etc en utilisant son nom SHA1 (ou bien son tag si celui-ci a été ajouté : voir plus loin). Celui-ci est visible dans la fenêtre gitk sous la partie qui contient la liste des versions à la suite de « id SHA1 ».

Mise à jour d’un dépôt

Une fois le dépôt récupéré, l’utilisateur peut modifier des fichiers ou récupérer des fichiers qui ont été modifiés par d’autres utilisateurs. Il peut également ajouter des fichiers. Les commandes permettant d’effectuer ces diverses opérations sont les suivantes :

mettre à jour un dépôt en récupérant tous les fichiers distants (il est conseillé d’effectuer cette opération avant de propager ses propres modifications sur le dépôt) :
```
git pull
```
mettre à jour le dépôt local en ajoutant un fichier example.txtqui n’est pas encore sur le dépôt :
```
git add exemple.txt
```
ou bien en mettant à jour un fichier modifié old-example.txtmais existant préalablement sur le dépôt
```
git commit old-example.txt
```
L’éditeur de texte choisi par défaut (pour moi nano) s’ouvre alors qui liste les fichiers qui vont être mis à jour (ici le fichier TODO a été modifié) et demande un message qui explique la nature des changements ; ce message doit être contenu sur une ligne et s’affichera dans gitk :

Une fois le message de log entré, on quitte l’éditeur sans oublié de sauver. Un message indiquant que tout s’est bien passé doit alors être produit.
On peut aussi mettre à jour tous les fichiers existants déjà dans le dépôt local et modifiés localement depuis la dernière mise à jour par</li>
```
git commit -a
```
Attention ! Ces opérations mettent à jour le dépôt local uniquement ; pour propager les modifications effectuées sur le serveur, il faut faire :</li>
envoyer les modifications locales qui ont été enregistrées (par commit) sur le serveur :
```
git push
```
Si l’intégralité de l’opération commit/push s’est bien passé, on doit avoir un message du type</li> </ul>
Gérer les conflits

Si la version locale du dépôt ainsi que la version distante ont été simultanément modifiées, l’utilisation de git pull produit deux situations distinctes :
- il n’y a pas de conflit d’édition (les deux dépôt ont été modifiés à des endroits différents). Dans ce cas, git gère la fusion et produit un dépôt fusionnant les deux versions ;
- il y a un conflit d’édition, dans ce cas, git produit un message d’erreur de ce type
Dans cet exemple, le fichier projetstat.r a un conflit d’édition. Ce fichier étant un fichier texte, git crée un fichier correspondant au résultat de la commande diffentre les deux versions existantes. À ce moment, le fichier projetstat.r présent localement fait apparaître les différences en utilisant des balises du type <<<<<< et >>>>>>. C’est alors à l’utilisateur de procéder manuellement au choix :

Dans l’exemple ci-dessus, le texte se situant entre <<<<<<< HEAD et ======= est le texte du fichier local ; le texte se situant entre ======= et >>>>>>> 76983e194193f6d62f9df57830f3902bc701c2a2 est le texte de la dernière version du serveur dont l’identifiant SHA1 est 76983e194193f6d62f9df57830f3902bc701c2a2. On procède alors manuellement au choix, pour obtenir, par exemple, le fichier :

qui contient la version que l’on souhaite conserver (cette version peut être un mélange des deux versions proposées). Lorsque le choix est finalisé, on termine l’opération avec
```
git commit -a
git push
```
ce qui produit une fusion de branche visible dans gitk : .

Lire les statuts

La commande
```
git status
```
permet de vérifier le statut des différents fichiers du dépôt. TODO : à finir (à commiter, untracked… + copie d’écran)

Taguer

Vous pouvez créer un tag qui référence une version particulière du dépôt git en spécifiant le nom du tag et le nom SHA1 du commit à taguer en options :
```
git tag myprettyversion 76983e194193f6d62f9df57830f3902bc701c2a2
```
ce qui permet d’utiliser le nom myprettyversion

pour faire référence à la version 76983e194193f6d62f9df57830f3902bc701c2a2 (ce qui est tout de même plus pratique !). Le tag est ajouté au serveur (pour utilisation par tous les utilisateurs) par
```
git push --tag
```
Au niveau de gitk, on obtient l’indication suivante :qui indique que l’avant dernière version porte le nom submitted-RR-abstract (les autres versions ne sont pas taguées).

TODO : checkout…
</div>

Installation de PostfixAdminInstalling PostfixAdmin

Posted in Linux, Ubuntu serveur and tagged courrier électronique, postfix, postfixadmin on Mar 19, 2012

PostfixAdmin est une interface web en PHP qui permet de gérer facilement le serveur de mail postfix. L’installation décrite ici est postérieure à l’installation et la configuration de postfix avec dovecot (voir ce post). Elle est donc expliquée pour ce cas précis bien que la procédure puisse être adaptée à une installation « classique » dans laquelle PostfixAdmin est installé avant postfix.

PostfixAdmin is a web based administration interface for postfix. This post describes how to install PostfixAdmin after postfix has been installed and configured to work with dovecot (as in this post ce post). Nevertheless, the post is general enough to be usable in a standard installation where PostfixAdmin should be installed before postfix is configured.
I should have written: this post will be general enough… (it is already « general enough » but in French!)

Avant propos : ce tutoriel a été écrit pour un serveur sous Ubuntu server, version 10.04 (LTS).

Installation et configuration de base

Récupérer le fichier .deb de postfixadmin sur le site de sourceforge et l’installer : au préalable, le package php5-imapdoit être installé :

sudo apt-get install php5-imap
sudo dpkg -i postfixadmin_2.3.5-1_all.deb

Lors de l’installation de postfixadmin, la base de données associées peut être créée : il faut renseigner son type (ici, mysql), son nom (ici, postfixadmindb), un nom d’utilisateur (ici, postfixadminuser) et un mot de passe utilisateur (que l’on notera mypasswddans la suite). L’application est rendue accessible sur le serveur web par la création d’un lien symbolique puis on restreint l’accès à l’application :

ln -s /usr/share/postfixadmin /var/www/postfixadmin
chmod -R o-r /usr/share/postfixadmin
chown root:www-data -R /usr/share/postfixadmin

L’application est alors accessible à http://www.domain-name.org/postfixadmin où www.domain-name.org est l’adresse habituelle du serveur web. Lancer le script d’installation : http://www.domain-name.org/postfixadmin/setup.php : entrez un mot de passe dans l’espace « setup password » ; en validant, postfixadmin vous indique d’éditer le fichier /etc/postfixadmin/config.inc.phppour y modifier la ligne

$CONF['setup_password'] = 'xxxx';

où xxxx est une longue chaîne de caractères correspondant au mot de passe que vous venez de préciser. Entrer alors un administrateur (une adresse email, par exemple postmaster@domain-name.org) et un mot de passe pour cet administrateur. Enfin, les dernières modifications du fichier de configuration /etc/postfixadmin/config.inc.phppeuvent être effectuées :

# Email de l'administrateur
$CONF['admin_email'] = 'postmaster@domain-name.org';
# Configuration de la base de données
$CONF['database_type'] = 'mysqli';
$CONF['database_host'] = 'localhost';
$CONF['database_user'] = 'postfixadminuser';
$CONF['database_password'] = 'mypasswd';
$CONF['database_name'] = 'postfixadmindb';
# Alias par défaut
$CONF['default_aliases'] = array ( 'abuse' =>; 'postmaster@nathalievialaneix.eu',
  'hostmaster' =>; 'postmaster@nathalievialaneix.eu',
  'postmaster' =>; 'postmaster@nathalievialaneix.eu',
  'webmaster' =>; 'postmaster@nathalievialaneix.eu' );
# Configuration du service de vacances (ici non)
$CONF['vacation'] = 'NO';
# Configuration des liens
$CONF['user_footer_link'] = "https://www.domain-name.org/postfixadmin/users";
$CONF['footer_text'] = 'Return to nathalievialaneix.eu';
$CONF['footer_link'] = 'https://www.nathalievialaneix.eu';
# Création des chemins pour les boîtes mail, en adéquation avec dovecot
$CONF['domain_path'] = 'YES';
$CONF['domain_in_mailbox'] = 'NO';
$CONF['create_mailbox_subdirs_prefix']='';
# Configuration de la récupération d'emails avec fetchmail (ici non)
$CONF['fetchmail'] = 'NO';

(re)-Configurer postfix

La première chose à faire, avant de lancer la reconfiguration de postfix, est de redéfinir dans postfixadmin les domaines, utilisateurs et alias qui avaient été définis dans postfix (et ceci afin d’éviter une coupure du serveur mail). Pour cela, dans un navigateur, se connecter à postfixadmin avec l’adresse http://www.domain-name.org/postfixadmin, se loguer avec l’adresse email administrateur définie plus haut postmaster@domain-name.orget entrer le mot de passe correspondant. L’interface est intuitive : on crée noms de domaine, puis alias de noms de domaines puis utilisateurs et alias d’utilisateurs. Dans la suite, on supposera que les données suivantes ont été rentrées :

deux domaines (comme dans ce post) : server.domain-name.org et domain-name.org ;
un alias de domaine de server.domain-name.org vers domain-name.org ;
un utilisateur tuxette@domain-name.org ;
un alias utilisateur de postmaster@domain-name.org vers tuxette@domain-name.org.

Des références utiles pour configurer/re-configurer postfix peuvent être trouvées ici (en français) et là (en anglais). Dans la suite, on part d’un serveur postfix déjà configuré ; si ce n’est pas le cas, les manipulations sont les mêmes : la seule différence réside dans le fait que les fichiers peuvent être créés directement, sans recours à des versions provisoires (.new) destinées uniquement à ne pas couper le serveur. Dans le répertoire /etc/postfix, créez les fichiers :

main.cf.new:

cp main.cf main.cf.new

puis éditer le fichier main.cf.newet modifier les lignes

virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf,
  mysql:/etc/postfix/mysql-virtual-mailbox-alias-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf,
  mysql:/etc/postfix/mysql-virtual-alias-alias-maps.cf

mysql-virtual-mailbox-domains.cf.new : éditer ce nouveau fichier pour y insérer :

user = postfixadminuser
password = mypasswd
hosts = 127.0.0.1
dbname = postfixadmindb
query = SELECT domain FROM domain WHERE domain='%s'