Proxmox Virtual Environnement

Proxmox VE s’installe sur un serveur nu, à partir d’une image iso téléchargeable sur le site officiel. Etant donné qu’il repose sur une distribution Debian Lenny, il est tout à fait possible de l’installer, sur un système existant, à partir de paquets. La dernière version (1.8) utilise les extensions de virtualisation des processeurs 64 bits, elle n’est disponible que pour cette architecture, inutile donc,  de tenter une installation sur une machine 32 bits.

Une interface web d’administration offre une surveillance et une gestion simplifiée des machines virtuelles KVM (kernel-based Virtual Machine) et para-virtuelles OpenVZ . Nous pouvons en quelques clics, créer, modifier, supprimer, démarrer, arrêter, suspendre ou visualiser l’état d’une machine.

Des outils, en lignes de commandes, permettent des fonctionnalités plus poussées, telles que la sauvegarde à chaud par snapshot ou la restauration.  Enfin, des fonctions de clustering permettent, par exemple, la migration à chaud de machines virtuelles d’un serveur physique à un autre.

Je vous propose ci-dessous, trois petites démonstrations en screencast. La première montre l’utilisation de l’interface Web pour la création et l’installation d’un serveur virtuel kvm sous Debian Squeeze, la deuxième, le clonage de ce serveur à l’aide des outils de snapshot et de restauration et enfin, la troisième, la création d’un cluster de deux serveurs Proxmox VE ainsi que la migration d’une machine virtuelle d’un serveur vers l’autre.

Démo n°1 – Installation d’un serveur virtuel Debian.

Click here to view the video on YouTube.

Démo n°2 – Utilisation des outils de sauvegarde et de restauration pour le clonage d’une VM.

Click here to view the video on YouTube.

Démo n°3 – Création d’un cluster Proxmox VE et migration à chaud.

Click here to view the video on YouTube.

Sources :

• Site officiel Proxmox,
• Wikipedia.

Tor (The Onion Router) est un réseau permettant la transmission anonyme de paquets TCP au travers d’internet…

…Au lieu d’emprunter un itinéraire direct entre la source et la destination, les paquets de données suivent une trajectoire aléatoire à travers plusieurs relais…

La suite de ce billet donne une brève introduction à Tor et à son principe de fonctionnement, pour finir par un exemple pratique d’installation et d’utilisation.

Comment ça marche ?

Après interrogation d’un serveur Tor, le client reçoit une liste de noeuds. Il construit alors un chemin aléatoire au travers, de telle sorte que chaque relais ne connaisse que l’adresse de son prédécesseur et de son successeur. Aucun noeud ne connait à lui seul le chemin complet.

Un nouveau chemin sera recalculé régulièrement.

Pour garantir sa confidentialité dès le départ, un paquet tcp est chiffré « en couches » successives avec la clef publique de chaque noeud, en commençant par le dernier…

Lorsque le paquet parcours son chemin, chaque couche de chiffrement sera enlevée par son noeud respectif, jusqu’au dernier, qui transmettra alors le paquet en clair au serveur destinataire. Je vous laisse faire l’analogie avec l’oignon… Même si mon schéma est un peu « carré ».

Il faut être conscient, cependant, que Tor a ses limites : Il gère seulement le transport des paquets TCP et n’assure pas de protection en UDP. Protocole utilisé entre autres pour les requêtes DNS. De plus, une page web peut récolter directement des informations privées (dont l’adresse IP), directement auprès du navigateur, par l’utilisation de Javascript ou la lecture de cookies.

Pour la navigation Web, on va généralement coupler Tor  à un serveur mandataire (proxy) tel que privoxy. Ce dernier va faire l’interface entre le navigateur et Tor, tout en fournissant un filtrage anonymisant supplémentaire (gestion des cookies, des accès, suppression des pubs, etc…).

En pratique

Tor est disponible sous licence BSD et facilement installable pour la majorité des distributions Linux et BSD. Il est également disponible pour de nombreuses plateformes telles que Windows, OSX ou Androïd… si si !).

Sous Ubuntu 10.4 :

 # echo "deb http://deb.torproject.org/torproject.org lucid main" >
         /etc/apt/sources.list.d/tor.list
 # gpg --keyserver keys.gnupg.net --recv 886DDD89
 # gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add -
 # apt-get update
 # apt-get install tor privoxy
. 

Un (tout) petit peu de configuration…

/etc/privoxy/config/

...
#  Décommenter la ligne suivante pour connecter Privoxy à Tor
forward-socks5   /               127.0.0.1:9050 .
...
# Il peut être judicieux de commenter la ligne suivante pour
# que les logs ne soient pas écrits.
# logfile logfile
...

On redémarre tout ça :

 # /etc/init.d/tor restart
 # /etc/init.d/privoxy restart

Privoxy doit ensuite être déclaré comme proxy dans les préférences du navigateur ou directement dans les préférences réseaux de Gnome. Dans l’exemple, nous avons bien une installation locale (127.0.0.1) et le port laissé par défaut (8118).

Le premier indice permettant de conclure que la configuration est bonne est la lenteur de la navigation. Le passage au travers du réseau Tor ne se fait pas sans perte de performances…

Le second peut se trouver sur la page : http://www.monip.org, qui ne devrait plus retourner notre adresse IP publique, mais celle du dernier relai traversé.

Au delà de la navigation

Au delà de la navigation web et des services pris en charge par le proxy, TOR est capable de sécuriser les connexions d’autres services grâce à la commande « torify« . Par exemple, la commande suivante permet une connexion ssh à travers le réseau Tor.

$ torify ssh mon.serveur.public.et.fictif.com

Voilà pour un petit tour rapide au pays de Tor… Pour (beaucoup) plus d’informations, je vous conseille de visiter le site officiel du projet et sa page Wikipédia.

Liens :

• Tor Project,
• Wikipedia – Tor (Réseau),
• Privoxy.

J’ai eu l’agréable surprise de découvrir qu’il existait un paquet pour Squeeze, mais après une bonne soirée d’acharnement, je n’ai pas réussi à obtenir quelque chose de vraiment fonctionnel. Une interface web pleine de bugs, des modules manquants, bref, pas génial génial.

L’installation étant bien documentée, sur le site officiel, pour une distribution RedHat, je me suis finalement résigné à tenter le coup sur une CentOS 5.  Après tout, je n’avais pas mis le nez dans une RedHat depuis des lustres, c’était l’occasion.

Heureux de cette expérience réussie sous CentOS, j’ai ressenti une pointe de frustration de n’avoir pas pu faire tourner le binious sous ma distribution préférée. J’ai finalement consacré une dernière soirée à une installation à partir des sources, sous Lenny.

CentOS 5

La documentation officielle est très bien faite et ne justifie pas un article dédié à l’installation sous CentOS. Il faut veiller cependant à adapter la configuration du dépôt utilisée dans cette doc, en remplaçant RHEL5 par CentOS5.

/etc/yum.repos.d/inverse.repo

[RHEL5]
 
name=Inverse SOGo Repository
 
#baseurl=http://inverse.ca/downloads/SOGo/RHEL5/$basearch
 
baseurl=http://inverse.ca/downloads/SOGo/CentOS5/nightly/$basearch
 
gpgcheck=0

Note : J’ai utilisé la branche « nightly » après avoir rencontré des problèmes de dépendances avec la branche classique (inverse.ca/downloads/SOGo/CentOS5/$basearch). C’est évidemment peu recommandé pour une machine en production.

A noter également que la doc est basée sur une utilisation avec postgresql, mais passe sous silence l’installation de ce dernier. Un petit coup de « yum » règle rapidement le problème :

# yum install postgresql-server

Enfin, j’ai bloqué un petit moment à cause du firewall SeLinux qui interdit par défaut les connexions sur le port http. Pour autoriser les connexions au port 80 :

# setsebool httpd_can_network_connect=1

Debian Lenny

Pré-requis

SOGo utilise un LDAP pour l’authentification et les annuaires mails centralisés, un serveur SMTP et IMAP pour la gestion des mails. Dans cet exemple, je vais me baser sur l’architecture décrite ici :

Installation d’un serveur mail brique par brique… (OpenLDAP, Postfix, Cyrus-imap, TLS, SASL, Spamassassin, Amavis, etc…)

Installation de quelques paquets nécessaires au fonctionnement et à la compilation de SOGo ( Apache2, GNUStep, Postgresql, etc…)

# aptitude install apache2 apache2-mpm-prefork apache2-prefork-dev
# aptitude install postgresql
# aptitude install make patch subversion monotone
# aptitude install gobjc gnustep-make libgnustep-base1.16 libgnustep-base-dev libpq5 libpq-dev libldap2-dev libxml2-dev libmysqlclient15-dev gnustep-base-common gnustep-base-runtime

La compilation de SOGo nécessite la librairie Memcached (libmemcached2 libmemcached-dev), non disponible par défaut sous Lenny. Les paquets peuvent cependant être empruntés à Squeeze :

- http://packages.debian.org/squeeze/libmemcached2
- http://packages.debian.org/squeeze/libmemcached-dev

# aptitude install memcached
# dpkg -i libmemcached2_0.31-1_i386.deb libmemcached-dev_0.31-1_i386.deb

Postgresql

Création d’un utilisateur « sogo » dans postgresql et création d’un base « sogo« .

# su – postgres
$ createuser –no-superuser –no-createdb –no-createrole –encrypted –pwprompt sogo
$ createdb -O sogo sogo

Note : Pour l’exemple, j’ai utilisé « sogopasswd » comme mot de passe.

Récupération des sources

SOGo  ( monotone )

$ mtn db init –db=db.mtn
$ mtn –db=db.mtn pull inverse.ca ca.inverse.sogo
$ mtn –db=db.mtn checkout –branch ca.inverse.sogo SOGo

SOPE (Subversion)

$ svn export -r 1660 http://svn.opengroupware.org/SOPE/trunk/ SOPE

Compilation

SOPE

$ cd SOPE
$ patch -p0 < ../SOGo/SOPE/sope-patchset-r1660.diff
$ patch -p0 < ../SOGo/SOPE/sope-gsmake2.diff
$ source /usr/share/GNUstep/Makefiles/GNUstep.sh
$ ./configure –with-gnustep –enable-strip –enable-debug
$ make
$ su
# make install
# exit

SOGo

$ cd ../SOGo
$ source /usr/share/GNUstep/Makefiles/GNUstep.sh
$ ./configure –enable-strip –enable-debug
$ make
$ su
# make install
# cp Scripts/sogod-wrapper /usr/sbin/
# cp debian/sogo.init /etc/init.d/sogo

# chmod +x /etc/init.d/sogo

Edition du fichier /etc/init.d/sogo pour affecter 3 à la variable PREFORK. Ce qui permet de lancer 3 démons Sogo simultanément.

/etc/init.d/sogo

...
 
# specify more if you are using a load-balancer
 
# PREFORK=1
 
PREFORK=3
 
SOGO_ARGS=""
 
USER=sogo
 
...

Configuration

Création d’un utilisateur « sogo » :

# adduser sogo –home /var/lib/sogo

Création des répertoires :

# mkdir /var/spool/sogo /var/run/sogo /var/log/sogo
# chown -R sogo /var/spool/sogo /var/run/sogo /var/log/sogo

Création du fichier de configuration :

# su – sogo
$ mkdir -p GNUstep/Defaults
$ vi GNUstep/Defaults/.GNUstepDefaults

/var/lib/sogo/GNUstep/Defaults/.GNUstepDefaults

{
     NSGlobalDomain = {
     };
     gdnc = {
};
 
sogod = {
    NGImap4DisableIMAP4Pooling = YES;
    NGUseUTF8AsURLEncoding = YES;
    OCSFolderInfoURL = "postgresql://sogo:sogopasswd@localhost:5432/sogo/sogo_folder_info";
    SOGoACLsSendEMailNotifications = YES;
    SOGoAppointmentSendEMailNotifications = YES;
    SOGoAuthenticationMethod = LDAP;
    SOGoCalendarDefaultRoles = (
     PublicViewer
);
 
SOGoDefaultLanguage = French;
SOGoDefaultMailDomain = linet.jopa.fr;
SOGoDraftsFolderName = INBOX/Drafts;
SOGoFallbackIMAP4Server = mail.linet.jopa.fr;
SOGoFoldersSendEMailNotifications = YES;
SOGoLDAPSources = (
{
     CNFieldName = cn;
     IDFieldName = uid;
     UIDFieldName = uid;
     baseDN = "dc=linet,dc=jopa,dc=fr";
     bindDN = "cn=guest,dc=linet,dc=jopa,dc=fr";
     bindFields = uid;
     IMAPHostFieldName = site;
     bindPassword = "MotDePasseGuestLDAP";
     canAuthenticate = YES;
     displayName = "Adresses Jopa";
     hostname = localhost;
     id = public;
     isAddressBook = YES;
     port = 389;
     scope = SUB;
}
);
SOGoMailingMechanism = smtp;
SOGoOtherUsersFolderName = "Other Users";
SOGoProfileURL = "postgresql://sogo:sogopasswd@localhost:5432/sogo/sogo_user_profile";
SOGoSMTPServer = mail.linet.jopa.fr;
SOGoSentFolderName = INBOX/Sent;
SOGoServerTimeZone = Europe/Paris;
SOGoSharedFolderName = "Shared Folders";
SOGoTrashFolderName = INBOX/Trash;
WOApplicationRedirectURL = "http://labo.linet.jopa.fr";
WOMessageUseUTF8 = YES;
WOParsersUseUTF8 = YES;
WOPort = 20000;
 
WOUseRelativeURLs = NO;
SOGoSuperUsernames = (joel);
SOGoForceIMAPLoginWithEmail = NO;
 
};
}

Notes :

- J’utilise l’utilisateur Guest pour la lecture de l’annuaire LDAP. C’est utilisateur a des droits en lecture seule sur la branche contenant mes utilisateurs. Si l’annuaire autorise une lecture anonyme, la connexion à l’annuaire sous un utilisateur particulier n’est pas nécessaire.
- labo.linet.jopa.fr est l’url de la machine sur laquelle est installée Sogo.

Apache

Création d’un fichier de configuration : /etc/apache2/conf.d/sogo.conf

Alias /sogo.woa/WebServerResources/ \
        /usr/local/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGo.woa/WebServerResources/ \
        /usr/local/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGO.woa/WebServerResources/ \
        /usr/local/lib/GNUstep/SOGo/WebServerResources/
 
<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*jpg">
  SetHandler default-handler
</LocationMatch>
 
<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*png">
  SetHandler default-handler
</LocationMatch>
 
<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*gif">
  SetHandler default-handler
</LocationMatch>
 
<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*css">
  SetHandler default-handler
</LocationMatch>
 
<LocationMatch "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*js">
  SetHandler default-handler
</LocationMatch>
 
AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \
           /usr/local/lib/GNUstep/SOGo/$1.SOGo/Resources/$2
 
<Proxy balancer://sogocluster>
  RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
  RequestHeader set "x-webobjects-remote-host" "127.0.0.1"
 
  RequestHeader set "x-webobjects-server-port" "80"
  RequestHeader set "x-webobjects-server-name" "labo.linet.jopa.fr"
  RequestHeader set "x-webobjects-server-url" "http://labo.linet.jopa.fr"
 
 
  BalancerMember http://127.0.0.1:20000 retry=1 max=1 timeout=120
  BalancerMember http://127.0.0.1:20001 retry=1 max=1 timeout=120
  BalancerMember http://127.0.0.1:20002 retry=1 max=1 timeout=120
  ProxySet lbmethod=byrequests maxattempts=1
  Order allow,deny
  Allow from all
</Proxy>
 
SetEnv proxy-nokeepalive 1
ProxyRequests Off
ProxyPass /SOGo balancer://sogocluster/SOGo

Activation des modules apache :
# a2enmod proxy
# a2enmod proxy_http
# a2enmod proxy_balancer
# a2enmod headers

Démarrage

# /etc/init.d/apache2 restart
# /etc/init.d/sogo start

Si tout se passe bien, l’interface Web de Sogo est disponible via l’url : http://votre_serveur/SOGo

Sources :

- http://www.scalableogo.org

- http://wiki.auf.org/wikiteki/ZA/Montr%C3%A9al/SOGo/ProcedureInstallation

• Côté Windows Mobile, c’est « ActiveSync » qui va gérer et maintenir la connexion avec le serveur, donc rien à installer, c’est super !
• Côté serveur, nous allons utiliser « Z-Push », une implémentation open source du protocole ActiveSync, écrite par la société Zafara (en PHP).

Avant de commencer, nous aurons besoin :

• D’un serveur Linux avec PHP 5 et Apache 2 installés (et accessible depuis Internet évidemment) – Pour le test, j’ai utilisé une Debian Lenny -,
• Un serveur IMAP (local ou distant),
• Dans l’optique de la configuration d’un VirtualHost Apache, une entrée DNS spécifique, c’est plus propre, mais ce n’est pas obligatoire,
• Les sources de Z-Push,
• Un terminal Windows Mobile (testé avec Windows Mobile 6).

Z-Push

Commençons par décompresser les sources à la racine de notre serveur web :

# tar xvzf  z-push-1.2.2.tar.gz -C /var/www/

Le répertoire /var/www/z-push/state doit être accessible en écriture par l’utilisateur Apache :

# chmod 700 /var/www/z-push/state
# chown www-data:www-data /var/www/z-push/state

Editons ensuite le fichier de configuration  (/var/www/z-push/config.php)

...
// The data providers that we are using (see configuration below)
    $BACKEND_PROVIDER = "BackendIMAP";
...
    // ************************
    //  BackendIMAP settings
    // ************************
 
    // Defines the server to which we want to connect
    // recommended to use local servers only
    define('IMAP_SERVER', 'localhost');
 
    // connecting to default port (143)
    define('IMAP_PORT', 143);
 
    // best cross-platform compatibility (see http://php.net/imap_open for options)
    define('IMAP_OPTIONS', '/notls/norsh/ssl/novalidate-cert');
 
    // overwrite the "from" header if it isn't set when sending emails
    // options: 'username'    - the username will be set (usefull if your login is equal to your emailaddress)
    //        'domain'    - the value of the "domain" field is used
    //        '@mydomain.com' - the username is used and the given string will be appended
    define('IMAP_DEFAULTFROM', 'username');
 
    // copy outgoing mail to this folder. If not set z-push will try the default folders
    define('IMAP_SENTFOLDER', '');
 
...

Les paramètres ci-dessus sont adaptés au serveur imap local. Ils peuvent être ajustés à un autre serveur. Ceci devrait fonctionner avec n’importe quel serveur IMAP.

Par exemple, pour Gmail :

define('IMAP_SERVER', 'localhost');
define('IMAP_PORT', 993);
define('IMAP_OPTIONS', '/notls/norsh/ssl/novalidate-cert');
define('IMAP_DEFAULTFROM', 'username')
define('IMAP_SENTFOLDER', '');

Apache

Nous allons avoir besoin de satisfaire quelques dépendences avant d’attaquer la configuration d’Apache.  Z-Push a en effet besoin de quelques paquets pour pouvoir fonctionner correctement :

#  apt-get install pear php5-imap php5-mail php5-mail-mime php5-pear
# pear install –alldeps Mail

Nous avons ensuite deux alternatives :

• Créer un VirtualHost afin d’accéder au serveur directement par son nom : http://z-push.mondomaine.net, (plus propre à mon sens)
• Ou configurer un répertoire d’un site existant : (http://mon_serveur_ou_son_ip/z-push).

Virtualhost

Pour créer un VirtualHost, il nous faut ajouter un fichier dans /etc/apache2/sites-available. Arbitrairement, nous allons choisir z-push comme nom de fichier.

/etc/apache2/sites-available/z-push

	ServerAlias zpush.mondomaine.net
	ServerAdmin webmaster@mondomaine.net
	DocumentRoot /var/www/z-push
	Alias /Microsoft-Server-ActiveSync /var/www/z-push/index.php
 
		Options -Indexes
		AllowOverride none
		Order allow,deny
		allow from all
		php_flag magic_quotes_gpc off
		php_flag register_globals off
		php_flag magic_quotes_runtime off
		php_flag short_open_tag on
 
	ErrorLog /var/log/apache2/zpush-error.log
	LogLevel warn
	CustomLog /var/log/apache2/zpush-access.log combined
	ServerSignature Off

La commande a2ensite (Apache2 Enable Site) permet de rendre le VirtualHost actif (équivaut à faire un lien symbolique dans /etc/apache2/sites-enabled)

$ sudo a2ensite z-push
$ /etc/init.d/apache2 reload

Config par défaut ou .htaccess

La deuxième technique  consiste à ne configurer que le répertoire z-push, sans création d’un VirtualHost. Pour cela, nous ajouterons simplement les lignes suivantes dans le fichier de configuration du site par défaut (normalement /etc/apache2/sites-avaible/defaut) ou directement dans un fichier un .htaccess à la racine du site :

	Alias /Microsoft-Server-ActiveSync /var/www/z-push/index.php
 
		Options -Indexes
		AllowOverride none
		Order allow,deny
		allow from all
		php_flag magic_quotes_gpc off
		php_flag register_globals off
		php_flag magic_quotes_runtime off
		php_flag short_open_tag on

Le mobile

La configuration du serveur étant terminée, nous pouvons tester sur un terminal. Nous allons configurer ActiveSync pour qu’il se connecte au serveur.

• Dans ActiveSync : Menu -> Configurer le serveur,
  • Adresse du serveur : zpush.mondomaine.net (nom du VirtualHost ou Url complète d’accès à z-push),
  • Décôcher SSL (n’est pas encore configuré sur le serveur Apache),
  • Nom d’utilisateur : L’utilisateur Imap pour lequel nous voulons recevoir les mails,
  • Mot de passe : Mot de passe de l’utilisateur sur le serveur Imap,
  • Domaine : Domaine de messagerie,
  • Ne synchroniser que les mails : nous avons utilisé z-push pour l’Imap uniquement.
• La synchro devrait ensuite fonctionner. L’activation du mode Push peut se faire dans le « Comm Manager » en activant « Microsoft Direct Push« .

La méthode est biensûr perfectible par l’ajout du support SSL. Je ne suis pas arrivé, pour l’instant, à une solution très satisfaisante concernant ce point. A moins qu’ils ne nous soit possible de faire certifier le certificat serveur par un autorithé reconnue, il faudra importer ce cetificat sur le mobile. La chose est plutôt fastidieuse, l’option d’import n’étant pas disponible dans Internet Explorer mobile. Il est nécessaire de passer par un export au format xml, que l’on insère ensuite dans un fichier cab pour l’installer sur le terminal. Bref, du bon gros bricolage !

Références : http://andrew.tj.id.au/activesync-for-gmail/

]]> http://www.jopa.fr/index.php/2009/08/05/push-mail-sur-serveur-imap-gmail/feed/ 4 http://www.jopa.fr/index.php/2009/07/28/alias-forward-postfix-openldap/ http://www.jopa.fr/index.php/2009/07/28/alias-forward-postfix-openldap/#comments Tue, 28 Jul 2009 20:10:23 +0000 Jopa http://www.jopa.fr/?p=1563 En me basant sur l’architecture présentée dans le billet : Installation d’un serveur mail brique par brique… (OpenLDAP, Postfix, Cyrus-imap, TLS, SASL, Spamassassin, Amavis, etc…), je vais chercher, au travers de cet article, à améliorer la distribution des mails entrants. Ce que je souhaite mettre en place est assez simple d’un point de vue fonctionnel :

1. Chaque utilisateur doit pouvoir disposer de plusieurs adresses email pour une même boîte, sans que l’on ait besoin de le créer plusieurs fois dans l’annuaire (notion d’alias) ,
2. Les messages entrants doivent pouvoir être stockés sur le serveur Imap Local, transférés vers d’autres adresses (notion de forward) ou, soyons fous, les deux.

Le serveur Imap utilisé est Cyrus, mais ceci n’a pas vraiment d’importance, n’importe quel gestionnaire Imap fera l’affaire. Il en va de même pour le serveur OpenLDAP qui peut être remplacé par un autre annuaire, pourvu qu’il respecte les standards. Vous l’aurez compris, c’est bel et bien Postfix qui va permettre ces petites galipettes.

Pour l’exemple, je vais une fois de plus solliciter mon utilisateur préféré : Monsieur Dupont (Jean pour les intimes) . Ce Monsieur souhaite recevoir tous les mails adressés à :

• jean@linet.jopa.fr,
• dupont@linet.jopa.fr,
• jean.dupont@linet.jopa.fr.

Il dispose bien entendu d’une boîte Imap sur le serveur, mais souhaite qu’une copie de ses messages soient transférés sur son compte gmail :  jean.dupont@gmail.com.  C’est pas très très joli pour la sécurité de l’entreprise, mais pour l’exemple (et pour Jean), je vais fermer les yeux !

Le serveur  IMAP :

Je vous l’ai dit, sur le serveur IMAP, rien de particulier. Il faut juste s’assurer qu’il est fonctionnel et que l’utilisateur Jean y est bien présent. Dans le cas contraire, je vous invite à consulter l’article précédent pour l’installation et la configuration d’un serveur Cyrus-Imap.

# cyradm –user cyrus localhost
Password:
localhost> lm
user.jean (HasNoChildren) user.jojo (HasNoChildren)
user.joel (HasNoChildren)
localhost> quit

L’annuaire :

Dans l’annuaire, j’ai légèrement modifié le schéma pour y insérer un deuxième attribut « Mail« , nommé « maildrop ». J’ai emprunté cet attribut à la classe CourierMailAlias (fournie par courier-Imap), mais en fait, n’importe quel attribut texte peut faire l’affaire.

L’idée est d’utiliser l’attribut « Mail » pour enregistrer les adresses pour lesquelles la réception de courrier est autorisée pour l’utilisateur :

• jean@linet.jopa.fr,
• dupont@linet.jopa.fr,
• jean.dupont@linet.jopa.fr

Et l’attribut « MailDrop«  pour les adresses auxquelles le courrier va être effectivement distribué. Il faut noter que cet attribut doit correspondre à des boîtes réellement existantes. Dans sa configuration initiale, Cyrus cherche à stocker les messages dans des boîtes identifiées par le préfixe de l’adresse du destinataire (ce qui est avant le @).

• jean@linet.jopa.fr,
• jean.dupont@gmail.com

Dans cet exemple, tout message adressé  à l’une ou l’autre  des 3 adresses définies par l’attribut « Mail » devra  être distribué aux 2 adresses définies par l’attribut « MailDrop« .

Côté ldiff, ça donne ça :

 
# utilisateurs.ldif
dn: uid=jean,dc=linet,dc=jopa,dc=fr
objectClass: top
objectClass: inetOrgPerson
objectClass: CourierMailAlias
uid: jean
cn: Jean DUPONT
sn: Jean
mail: jean@linet.jopa.fr
mail: dupont@linet.jopa.fr
mail: jean.dupont@linet.jopa.fr
maildrop: jean@linet.jopa.fr
maildrop: jean.dupont@gmail.com
userPassword: toto

Pour utiliser l’attribut « Maildrop » de la classe CourierMailAlias, il est nécessaire de récupérer le schéma décrivant la classe et de l’intégrer à l’annuaire. Le fichier s’appelle authldap.schema et vient avec la doc de Courier-Imap. (/usr/share/doc)… Vous pouvez également le récupérer ici :

authldap.schema

Le fichier doit être copié dans le répertoire contenant les schémas ( /etc/ldap/schema logiquement) et intégré à la structure de l’annuaire dans le fichier /etc/ldap/slapd.conf

/etc/ldap/slapd.conf

# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.
 
#######################################################################
# Global Directives:
 
# Features to permit
allow bind_v2
 
# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/authldap.schema
...
...

Postfix :

Le but ici, est de définir Cyrus comme agent de transport local (et virtuel) et de paramétrer les recherches dans l’annuaire LDAP. Cette recherche sera définie dans deux fichiers de configuration externes : ldap-accounts.cf pour la validation des destinataires et ldap-aliases.cf pour la gestion des alias.

/etc/postfix.main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
myorigin = /etc/mailname
...
...
# PARAMETRES LDAP
# Utilisateurs :
virtual_mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf
# Alias :
virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf
...
...
# Agent de transport local : CYRUS
local_transport = cyrus
virtual_transport = cyrus
mailbox_transport = cyrus
...
...
...

/etc/postfix/ldap-accounts.cf

Ce fichier configure la recherche dans l’annuaire pour l’identification et la validation des destinataires. Il spécifie l’adresse email comme critère de recherche et  cas de succès, précise que c’est  l’uid de l’utilisateur qui doit être retourné.

server_host = localhost
server_port = 389
search_base = dc=linet, dc=jopa, dc=fr
query_filter = (& (objectClass=InetOrgPerson)(mail=%s))
result_attribute = uid
bind = yes
bind_dn = cn=admin,dc=linet,dc=jopa,dc=fr
bind_pw = ******************
version = 3

/etc/postfix/ldap-aliases.cf

Ce fichier permet, quant à lui, de gérer les Alias. Il définit lui aussi une recherche sur l‘adresse email (champ mail) mais cette fois, c’est l’attribut « Maildrop » que sera retourné.

server_host = localhost
server_port = 389
search_base = dc=linet, dc=jopa, dc=fr
query_filter = (& (objectClass=InetOrgPerson)(mail=%s))
result_attribute = maildrop
bind = yes
bind_dn = cn=admin,dc=linet,dc=jopa,dc=fr
bind_pw = ******************
version = 3

En résumé, encore une démonstration de la puissance du duo Postfix/Ldap, pour une fonctionnalité très pratique et relativement simple à mettre en oeuvre.

J’ai publié, en début d’année, un billet sur l’installation d’un serveur mail basé sur différentes « briques » :

• OpenLDAP,
• Postfix,
• Cyrus-imap,
• TLS,
• SALS,
• Spamassassin,
• Amavis,
• etc…

En réutilisant ce tuto pour l’installation d’un nouveau serveur, je me suis aperçu de quelques coquilles et de légères différences pour une installation sous Lenny.

L’occasion pour moi de réactualiser l’article, en tenant comptes de vos remarques et commentaires.

Installation d’un serveur mail brique par brique… (OpenLDAP, Postfix, Cyrus-imap, TLS, SASL, Spamassassin, Amavis, etc…)

L’idée est simple : si mon Mir:ror est connecté à l’ordinateur et qu’un fichier contenant mon rfid est présent dans mon répertoire, je veux pouvoir ouvrir ma session à l’aide d’une puce RFID (carte, badge, ztamp:s, laaaaapin…) à la place de saisir mon mot de passe.

Je ne vais pas m’attarder ici à décrire la manière dont est codé le module, je vous laisse le soin de lire les sources… Je vais me contenter d’expliquer son installation et son utilisation.

Mise en garde :

Pour plusieurs raisons dont la simplification du module et mes piètres talents de développeur, il va sans dire que ce petit programme ne doit pas être utilisé en environnement sécurisé. Par contre, pour la maison, c’est plutôt fun !

Nous touchons ici à une partie sensible du système : l’authentification. Les manipulations ci-dessous sont donc à réaliser avec prudence.

Compilation :

Pour pouvoir compiler pam_mir-ror, il nous faut installer un version récente de la librairie de développement pam (libpam-dev). J’ai utilisé la version 1.0.1 proposée par défaut sous Debian Lenny.

$ sudo aptitude install libpam-dev

L’archive contenant les sources est téléchargeable ci-dessous :

• pam_mir-ror.0.2.tar.gz

Une fois téléchargée, il faut la décompresser et tout simplement lancer la commande « make ».

$ tar -xvzf pam_mir-ror.0.2.tar.gz
$ cd pam_mir-ror.0.2
$ make

Si tout se passe bien, nous devrions obtenir deux binaires :

• read_mir-ror : Un petit outil permettant la lecture à partir du Mir:ror,
• pam_mir-ror.so : Le module pam.

read_mir-ror

Le petit outil read_mir-ror va nous permettre de tester le lecteur. Il suffit de l’exécuter et d’approcher une puce rfid.

$ sudo ./read_mirror
0000D0081A025303420200D2

La série de chiffres affichée n’est rien d’autre que l’ID de l’objet détecté.

Il est préférable d’utiliser read_mirror avec les droits root, au moins la première fois, pour l’accès au périphérique mir:ror. Par défaut, le mir:ror n’est accessible que par root. Les droits du handler sont changés à la première utilisation de la fonction de détection (inclue dans l’outil et le module). Il serait certainement plus propre de coder un petit outil qui serait automatiquement lancé par udev ou hotplug au branchement du Mir:ror, mais pour un module PAM, ce n’est pas très important.

Génération du fichier utilisateur

Le même outil (read_mir-ror), va nous permettre de générer le fichier .authtag contenant le rfid propre à chaque utilisateur :

Pour l’utilisateur courant :

$ sudo ./read_mirror > ~/.authtag
$ sudo chmod 400 ~/.authtag

Pour un autre utilisateur  (toto):

$ sudo ./read_mirror > /home/toto/.authtag
$ sudo chmod 400 /home/toto/.authtag

Il faut bien entendu présenter la puce au lecteur juste après la commande ./read_mirror.
Le fichier .authtag doit maintenant contenir le tag :

$ cat ~/.authtag
0000D0081A025303420200D2

Module PAM  :  pam_mir:ror.so

Pour qu’il soit utilisable par PAM, il faut que pam_mir:ror.so soit présent dans /lib/security (lib64/security pour une architecture 64 bits)

$ sudo cp pam_mir-ror.so /lib/security

ou pour un module 64 bits :

$ sudo cp pam_mir-ror.so /lib64/security

La dernière étape va être l’ajout du module à PAM. Pour cela, il nous faut éditer le fichier :
/etc/pam.d/common-auth pour y ajouter, avant les modules pam_unix.so ou pam_unix2.so :

auth             sufficient         pam_mir-ror.so

/etc/pam.d/common-auth

#
# /etc/pam.d/common-auth - authentication settings common to all services
...
auth    sufficient                      pam_mir-ror.so
# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]      pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Avant de rebooter frénétiquement la machine pour voir ce que ça peut donner avec gdm,  je conseille vivement de tester sur une console (crtl-alt-F1 par exemple)… Comme expliqué en début d’article, nous touchons ici à une partie sensible du système et c’est mieux de garder la main pour éviter des pirouettes telles qu’un redémarrage en single user ou à partir d’un liveCD pour réparer.

J’ai fait en sorte que le module loggue un minimum. En fonction du système, ces logs sont visibles dans /var/log/auth.log ou /var/log/syslog.

Dernière version des sources : pam_mir-ror.0.2.tar.gz

]]> http://www.jopa.fr/index.php/2009/07/16/linux-pam-et-mirror-une-authentification-rfid/feed/ 11 http://www.jopa.fr/index.php/2009/07/07/violet-mirror-linux/ http://www.jopa.fr/index.php/2009/07/07/violet-mirror-linux/#comments Tue, 07 Jul 2009 21:57:12 +0000 Jopa http://www.jopa.fr/?p=1354 Vous connaissez certainement la société Violet et plus particulièrement son fameux lapin communicant : le Nabaztag ? Cette même société produit le « mir:ror« , un petit gadget très design qui n’est pas moins qu’un  lecteur RFID.

Question coût, le mir:ror se trouve un peu partout pour un 50ène d’euros. J’ai déniché le mien en solde pour moins de 30 € – Tu vois chérie, moi aussi le fais les soldes  !!! – Dans un joli coffret, sont rangés le lecteur usb, 3 « timbres » autocollants (Ztamp:s) et 2 petits lapins (Nano:Ztag), tous munis d’une puce RFID.

Le lecteur fonctionne biensûr avec les objets commercialisés par Violet, mais aussi avec n’importe quel tags RFID, pourvu qu’il  respecte la norme ISO 14443 A ou B – La carte de bus/métro de Toulouse fonctionne parfaitement par exemple.

En utilisation standard, moyennant l’installation d’un petit logiciel (Mirware) et la création d’un compte (gratuit) sur le site de Violet, nous pourrons enregistrer nos objets RFID et associer une action à leur approche ou leur éloignement du lecteur.

Après tout ce vocabulaire « Nabaztanique« , il faut bien que j’avoue que ce n’est pas pour son utilisation standard que j’ai craqué, mais pour  les  perspectives prometteuses  offertes en terme de bidouillage : Authentification pam, évènements domotiques (X10), clef de chiffrement, on peut imaginer énormément d’usages « non-officiels » … et c’est ça qui est bon !

Néanmoins, dans la suite du billet, je vais balayer une installation classique du « Mirware » sous Linux. Il faut bien commencer par là ! Cette manipulation ne présente pas de difficulté particulière, à part peut-être pour les architectures 64 bits. Dans un prochain article, je m’intéresserai au développements possibles autour du joujou !

Mirware mon beau Mirware…

J’ai réalisé ce test sur deux machines sous Ubuntu (9.04 « Jaunty jackalope » ), l’une en 32 bits, l’autre en 64. Mais Mirware devrait fonctionner sous n’importe quelle distribution, le tout étant de bien installer les librairies nécessaires.

Dans les pré-requis, il faut bien entendu une machine sous Linux, disposant d’une interface graphique et connectée à Internet. En effet, Mirware fonctionne grâce au serveur Violet.net, sur lequel seront enregistrés les tags et les actions qui leurs sont associées.  C’est un peu limitant, mais comment dire….c’est comme ça ! Domage !

L’application est disponible ici en version alpha… On regrettera l’absence des sources, mis à part pour la partie concernant la détection du périphérique, ce qui va sauver l’installation sur une distribution 64 bits.

Je parlais de librairies, il nous faudra satisfaire quelques dépendances à ce sujet et en installer 3 principales :

• Qt 4.4 avec le module webkit,
• QCA 2.0.1,
• SDL 1.2

(cf le README pour plus d’infos)

$ sudo apt-get install   libqt4-webkit   libqca2   libsdl1.2debian

Nous pouvons à présent télécharger et installer le Mirware :

$ wget -c http://broad.violet.net/mirror/mirware.tar.gz
$ tar -xvzf mirware.tar.gz
$ cd mirware-0.9.9-1724
$ sudo ./installer.sh

Le script installer.sh, présent dans l’archive de Mirware, va juste caler les droits pour la détection du périphérique :

installer.sh ( pour information uniquement)

#!/bin/bash
[ "$(id -u)" -eq 0 ] || { echo "This script needs root credentials" ; exit 1 ; }
chown root discover-device || { echo "Could not change owner of discover-device to root. Do you have root credentials ?" ; exit 1 ; }
chmod a+s discover-device || exit 1
touch detected_device
 
echo "All done ! You can now plug a mir:ror and launch mirware-launcher.sh !"

Il ne reste plus qu’à connecter le mir:ror et  lancer mirware :

$ ./mirware-launcher.sh

Une icône dans la barre de notification indique que tout se passe bien. En approchant un objet du capteur, une fenêtre de connexion devrait apparaître, suivie d’un interface permettant d’enregistrer l’objet et de lui associer des actions (applications).

32 bits…C’est bien…mais 64 ?

Si vous utilisez une distribution 64 bits, il vous faudra recompiler le petit programme de détection du mir:ror : discover-device et installer les librairies utilisées par Mirware dans leur version 32 bits. Sans les sources et en l’abscence de version 64 bits, pas le choix…

Concernant la compilation de discover-device, rien de bien sorcier, il faut juste ne pas oublier de lui redonner les bons droits…
$ sudo rm discover-device
$ gcc discover-device.c -o discover-device
$ sudo ./installer.sh

Pour les librairies 32 bits, après avoir pas mal joué de l’apt-get, je suis tombé sur un script qui simplifie bien les choses (merci Cappy). Getlibs prend en paramètre un binaire et télécharge les librairies dépendantes dans leurs versions 32 et 64 bits… Le pied !

$ wget -c http://frozenfox.freehostia.com/cappy/getlibs
$ ./getlibs mirware

Pour clore ce chapitre…

…sur une utilisation classique du mir:ror, je peux ajouter qu’une grande majorité des actions proposées par le serveur sont fonctionnelles sous Linux… L’ouverture d’un dossier, le chargement d’une url, l’accès à la messagerie, à un podcast ou une webradio, la lecture d’un texte en texttospeech et j’en passe…

J’ai tout de même noté un problème gênant sur l’application permettant le lancement de scripts;  En effet, cette dernière ne sait gérer que des scripts Windows/Dos batch (.bat) ou des AppleScripts(MacOsx). Ce n’est pas très gênant pour l’utilisation que je compte en faire et comme promis, je détaillerai, dans le prochain article comment s’affranchir des contraintes du serveur Violet.net pour passer de l’autre côté du mirroir.

]]> http://www.jopa.fr/index.php/2009/07/07/violet-mirror-linux/feed/ 9 http://www.jopa.fr/index.php/2009/04/19/eclipse-pdt-sur-ubuntu-amd-64/ http://www.jopa.fr/index.php/2009/04/19/eclipse-pdt-sur-ubuntu-amd-64/#comments Sun, 19 Apr 2009 10:33:33 +0000 Jopa http://www.jopa.fr/?p=1259 Je suis habitué à développer mes petits projets php grâce à mon éditeur préféré Vi (Vim), via des connexions ssh sur mes serveurs distants – Ah ben oui M’sieur ! C’est de la vielle école ça …d’la vielle école !  – Certains projets prenant de l’importance, ça commence à devenir vraiment sportif de jongler d’un fichier à l’autre et quasi impossible d’avoir un aperçu global de l’architecture. J’ai finalement décidé de franchir le pas et de passer sous Eclipse (Eclipse-PDT plus exactement).

Je me suis prestement rendu sur le site officiel (http://www.eclipse.org/pdt/) et j’ai malheureusement constaté que le framework PDT n’était pas disponible dans les téléchargements, pour l’architecture AMD-64…Pas d’bol !

Heureusement, la version développement (ganymede de son petit nom), semble permettre l’installation de PDT sous forme de plug-in, directement depuis son interface, y compris pour les architectures 64 bits….Je vais détailler par la suite la marche suivie pour arriver au but !

Java

Il me faut commencer par installer le JRE de Sun. Et oui…Eclipse, c’est Java avant tout !
Il est possible d’utiliser l’installation binaire disponible chez Sun : http://java.com/en/download/linux_manual.jsp?locale=en&host=java.com:80, ou tout simplement la commande aptitude d’Ubuntu :

$ sudo aptitude install sun-java6-jre

Si plusieurs environnement java sont installés, il est nécessaire de spécifier l’environnement actif par défaut

$ sudo update-java-alternatives -l
java-1.5.0-sun 53 /usr/lib/jvm/java-1.5.0-sun
java-6-openjdk 1061 /usr/lib/jvm/java-6-openjdk
java-6-sun 63 /usr/lib/jvm/java-6-sun
java-gcj 1042 /usr/lib/jvm/java-gcj

$ sudo update-java-alternatives -s java-6-sun

Eclipse IDE

La version 64 bits est téléchargeable ici : http://www.eclipse.org/downloads/.

Il suffit de télécharger et décompresser l’archive à l’emplacement voulu (/usr/local/eclipse par exemple) et le tour est joué.

$ cd /usr/local
$ sudo tar -xvzf ~/eclipse-jee-ganymede-SR2-linux-gtk-x86_64.tar.gz

Si tout est bon, l’exécutable présent à la racine du répertoire devrait lancer l’application.

$ /usr/local/eclipse/eclipse &

Ben c’est super tout ça ! Me voici doté  d’un bel environnement de développement java…Mais M’sieur, M’sieur, c’est du php que je veux faire moi !

Et pour PHP alors ?

La suite n’est pas plus compliquée, l’installation d’add-ons se fait par le menu « Help->Software Update-> Avaible Software« .  Les boutons Add Sites et Manage Sites vont me permettre d’ajouter des sites de téléchargement supplémentaires.

Pour faire fonctionner PDT, il me faut d’abord installer la dernière version du « Dynamic Language Toolkit » (DLK pour les intimes). Pour cela, j’ajoute le site :

http://download.eclipse.org/technology/dltk/updates-dev/1.0/

et installe : Dynamic Languages Toolkit – Core Frameworks (Incubation) par la liste des logiciels disponibles depuis ce site.

Finalement, j’utilise la même méthode pour installer PDT :

• Ajout du site : http://phpeclipse.sourceforge.net/update/stable/1.2.x/,
• Installation de  : PHPEclipse.

Après redémarrage, le chargement de l’environnement PHP se fait via le menu « Windows->Open Perspectives« .

D’autres plugins bien sympathiques existent, notemment en matière de déboggage, d’accès à des projets, serveurs ou répertoires distants, etc… Ceci feront peut-être l’objet d’un prochain billet.

]]> http://www.jopa.fr/index.php/2009/04/19/eclipse-pdt-sur-ubuntu-amd-64/feed/ 8 http://www.jopa.fr/index.php/2009/04/13/configuration-de-la-connection-usb-et-bluetooth-sur-debian-lenny-dun-telephone-portable-nokia-3600-slide/ http://www.jopa.fr/index.php/2009/04/13/configuration-de-la-connection-usb-et-bluetooth-sur-debian-lenny-dun-telephone-portable-nokia-3600-slide/#comments Mon, 13 Apr 2009 12:03:55 +0000 bm http://www.jopa.fr/?p=1214 J’ai acquis un tel portable Nokia 3600 Slide.

Pourquoi ce modèle ? …Je ne sais pas, j’étais pressé, j’avais tombé mon précédent téléphone dans un torrent et l’eau fraiche et le choc l’ont « espouti » comme on dit à Toulouse.

Ce que je suis arrivé à faire après avoir perdu mon carnet d’adresses de la carte SIM, …et avoir bien failli passer sous Windows pour le récupérer  :

• le connecter sur mon microordiateur portable ASUS W5F sous Debian Lenny en USB:

• le connecter sur mon microordiateur portable ASUS W5F sous Debian Lenny en bluetooth:

Cela permet d’uploader ou downloader des photos, videos, musique, thèmes , ….

• le connecter sur mon ordinateur portable pour sauvegarder et recharger messages, carnet d’adresses etc …

• ressources qui m’ont aidé:

http://www.meeus-d.be/linux/bluetooth.html

http://www.thinkwiki.org/wiki/How_to_setup_Bluetooth

et beaucoup:

http://article.gmane.org/gmane.linux.bluez.devel/12155

http://article.gmane.org/gmane.linux.drivers.gnokii/10729/match=3600

Merci à eux

Connection bluetooth:

J’ai rédigé ceci à partir de ce que j’avais fait et mon bash_history , je n’ai pas retesté …. Il se peut (c’est sûr !) que j’ai oublié quelques éléments …

Je suppose que la carte bluetooth de l’ordinateur portable fonctionne:

# hciconfig

doit renvoyer quelque chose du type:

hci0:    Type: USB
BD Address: 00:17:31:09:95:1C ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:937678 acl:55585 sco:0 events:2501 errors:0
TX bytes:8285 acl:287 sco:0 commands:77 errors:0

Installer les paquets ci dessous:

aptitude search bluez | grep ^i

i A bluez-audio                     - Support audio bluetooth
i A bluez-gnome                     - utilitaires Bluetooth pour GNOME
i A bluez-utils                     - outils et démons Bluetooth
i A python-bluez                    - Python wrappers around BlueZ for rapid b

aptitude search bluet | grep ^i
i   gnome-bluetooth                 - GNOME Bluetooth tools
i A libbluetooth2                   - Bibliothèque pour utiliser la pile BlueZ

 aptitude search obex | grep ^i

i A gnome-vfs-obexftp               - GNOME VFS module for OBEX FTP

i A libopenobex1                    - OBEX protocol library

i A obex-data-server                - D-Bus service for OBEX client and server s

i   obexfs                          - mount filesystem of ObexFTP capable device

i   obexftp                         - file transfer utility for devices that use

Dans /etc/default/bluetooth vérifier que:

BLUETOOTH_ENABLED=1

HID2HCI_ENABLED=1

HIDD_OPTIONS= »–master –server »

J’ai aussi:

DUND_ENABLED=1

DUND_OPTIONS= »–listen –persist »

Le paquet bluez-utils contient la commande hcitool

Allumer le tel portable et electionner Menu ->Paramètres->Connectivité->Bluetooth

et activer le bluetooth sur le tel portable

Si tout va bien:

hcitool scan

renvoie quelque chose comme:

Scanning ...
	00:21:AB:D9:75:25	Telbm

installer l2ping et en root:

#l2ping 00:21:AB:D9:75:25

Ping: 00:21:AB:D9:75:25 from 00:17:31:09:95:1C (data size 44) ...
0 bytes from 00:21:AB:D9:75:25 id 0 time 18.87ms
0 bytes from 00:21:AB:D9:75:25 id 1 time 37.94ms
0 bytes from 00:21:AB:D9:75:25 id 2 time 38.91ms
0 bytes from 00:21:AB:D9:75:25 id 3 time 35.91ms
0 bytes from 00:21:AB:D9:75:25 id 4 time 36.92ms
0 bytes from 00:21:AB:D9:75:25 id 5 time 26.92ms
0 bytes from 00:21:AB:D9:75:25 id 6 time 29.91ms
^C7 sent, 7 received, 0% loss

Dans /usr/share/doc/bluez-utils/examples/

décompresser passkey-agent.c.gz et le compiler

cd /usr/share/doc/bluez-utils/examples/
gunzip passkey-agent.c.gz
make

Lancer dans une fenêtre de terminal

./passkey-agent --default 0000

Editer dans un autre terminal /etc/bluetooth/hcid.conf et y mettre ceci:

options {
autoinit yes;
security auto;
pairing multi;

passkey "0000";
}
device {
name "asusBM";
class 0x3e0100;
iscan enable;
pscan enable;
lm accept;
lp rswitch,hold,sniff,park;
}

Relancer bluetooth

/etc/init.d/bluetooth restart

Dans un autre terminal lancer la commande :

obexftp -b 00:21:AB:D9:75:25 -l

Elle doit renvoyer quelque chose du genre:

# obexftp -b 00:21:AB:D9:75:25 -l
Browsing 00:21:AB:D9:75:25 ...
Channel: 10
Connecting...done
Receiving "(null)"...\<?xml version="1.0"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd"
 [ <!ATTLIST folder mem-type CDATA #IMPLIED> ]>
<folder-listing version="1.0">
    <folder name="Carte mémoire" user-perm="RW" mem-type="MMC"/>
    <folder name="Icônes" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Fichiers audio" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Thèmes" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Tonalités" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Clips vidéo" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Photos" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Enregistremts" created="20070101T000000" user-perm="R" mem-type="DEV"/>
    <folder name="Fichiers reçus" created="20070101T000000" user-perm="R" mem-type="DEV"/>
</folder-listing>
done
Disconnecting...done

Autoriser le téléphone portable a se connecter automatiquement

Si oui c'est gagné, sinon ...

Il ne reste plus qu'a ouvrir le navigateur de fichiers et lui dire :

Aller à : obex://[00:21:AB:D9:75:25] (cf deuxième copie d'écran en haut de l'article)

connection USB

Pour accéder aux fichiers « généraux » (photos, vidéo, musique, ….

Au branchement du téléphone avec le câble USB il suffit de répondre « transfert de données » sur le tel portable.

Pour pouvoir accéder au carnet d’adresse, aux messages et au calendrier (pas testé ce dernier à ce jour) il faut installer xgnokii

aptitude install xgnokii

débrancher et rebrancher le cable USB et sur le téléphone répondre "PCSuite"

puis créer un fichier .gnokiirc

et y mettre:

[global]
port = /dev/ttyACM0
model = AT
initlength = default
connection = serial
use_locking = no
serial_baudrate = 19200
smsc_timeout = 10
[xgnokii]
allow_breakage = 0
[gnokiid]
bindir = /usr/sbin/

Lancer la commande

gnokii --monitor

qui doit renvoyer quelque chose du genre:

gnokiid Version 0.6.27

Entrée en mode surveillance...

Network: France Telecom, France (208 01)

LAC: 4302 (17154), CellID: 00006ea2 (28322)

Niveau RF: 6

Batterie: 68

Source d'energie: Battery

SIM: Utilise 0, Disponible 150

Telephone: Utilise 79, Disponible 1921

DC: Utilise 9, Disponible 11

FD: Utilise 5, Disponible 25

MC: Utilise  0, Disponible 20

RC: Utilise 0, Disponible 20

Appel0: inactif

Appel1: inactif

Niveau RF: 6

Batterie: 68

Source d'energie: Battery

SIM: Utilise 0, Disponible 150

Telephone: Utilise 79, Disponible 1921

DC: Utilise 9, Disponible 11

FD: Utilise 5, Disponible 25

...

Si cela fonctionne  lancer en utilisateur xgnokii (cf troisieme copie d’écran en haut de l’article)

Je ne me souviens plus si j’ai essayé de le connecter en bluetooth avec xgnokii.