Depuis quelques temps, j'ai en tête un "projet" que j'aimerais bien mettre en place chez moi : un cloud personnel. Ayant un serveur@home avec deux disques durs (avec réplication de l'un sur l'autre), je souhaitais en faire un serveur de stockage de mes données (présentes sur plusieurs PC fixes et portables) via un logiciel de cloud. Au départ, j'ai testé Owncloud (version 5) mais je n'ai pas été convaincu donc j'ai cherché un autre logiciel. Le deuxième plus "connu" est Sparkleshare, j'ai décidé de le tester.

Voici comment j'ai installé le serveur sur une Debian Squezze et le client sur une Ubuntu 10.04 et une 12.04. Je vous donnerai ensuite mes impressions sur cette solution.

I. Serveur

Installation

Nous allons utiliser un assistant très pratique pour installer et configurer le serveur Sparkleshare. Cet assistant s'appelle dazzle. Pour l'obtenir, il suffit de lancer cette commande (en tant que root) :

curl https://raw.github.com/hbons/Dazzle/master/dazzle.sh --output /usr/bin/dazzle && chmod +x /usr/bin/dazzle

Une fois installé, vous devez utiliser la commande dazzle pour configurer le serveur :

dazzle setup

L'assistant effectuera toutes les actions nécessaires pour la mise en place de Sparkleshare :

1. Vérification de la présence de git et installation si nécessaire
2. Création d'un compte utilisateur "storage" qui sera utilisé pour utiliser Sparkleshare
3. Configuration du compte "storage" (en particulier des accès SSH, car tout se fait en SSH)
4. Rechargement du serveur SSH

Note : À ce moment, j'ai eu une erreur avec mon serveur SSH. Il refusait de redémarrer et m'affichait l'erreur suivante :

Il s'agit d'une erreur due aux lignes ajoutées par Sparkleshare à la fin du fichier /etc/ssh/sshd_config (utilisée pour l'accès SSH au compte "storage"). Après pas mal de recherches, je me suis rendu compte que l'erreur était due à la version de mon openssh-server. Sur ma Debian Squeeze, la version installée était la 5.5 (1:5.5p1-6+squeeze3). La configuration ajoutée par Sparkleshare n'est compatible qu'avec la version d'openssh-server 6.x.

Pour remédier à ce problème, j'ai dû mettre à jour mon openssh-server via les dépôts testing de Debian (ce qui a nécessité une mise à jour du paquet libc6-dev) au passage. Cela a installé la version 6 (1:6.0p1-4) d'openssh-server et cela a résolu mon problème.

Configuration

Maintenant que mon serveur est installé, j'ai créé (toujours via dazzle) un répertoire destiné à accueillir mes données à synchroniser. Pour ce faire, il faut utiliser la commande suivante :

dazzle create DOSSIER

ou en crypté :

dazzle create-encrypted DOSSIER_CRYPTE

Voici le résultat de la commande :

Creating encrypted project "DOSSIER_CRYPTE"...
  -> /usr/bin/git init --bare /home/storage/DOSSIER_CRYPTE-crypto
  -> /usr/bin/git config --file /home/storage/DOSSIER_CRYPTE-crypto/config receive.denyNonFastForwards true
  -> echo "*.DMG -delta" >> /home/storage/DOSSIER_CRYPTE-crypto/info/attributes      
  -> chown --recursive storage:storage /home/storage
  -> chmod --recursive o-rwx /home/storage/DOSSIER_CRYPTE-crypto
 
Project "DOSSIER_CRYPTE-crypto" was successfully created.
To link up a SparkleShare client, enter the following
details into the "Add Hosted Project..." dialog:
 
  Address: ssh://storage@mon_ip:mon_port
  Remote Path: /home/storage/DOSSIER_CRYPTE-crypto
 
To link up (more) computers, use the "dazzle link" command.

On voit que le dossier est créé dans le répertoire /home/storage (qui est la homedir de notre utilisateur storage).

Voila, la partie serveur est presque terminée, il faudra faire une dernière action lors de la configuration de notre client mais nous verrons cela plus bas.

II. Client

Installation

Sparkleshare n'est pas officiellement packagé pour Ubuntu dans ses versions 10.04 jusqu'à 11.10. Ceci dit, un dépôt PPA est disponible (compatible avec Ubuntu 10.04 -> 11.10). Il ne s'agit pas des dépôt officiels, aussi, installez-le en connaissance de cause. Vous devez l'ajouter et lancer l'installation grâce à ces commandes :

sudo add-apt-repository ppa:warp10/sparkleshare
sudo apt-get update
sudo apt-get install sparkleshare libwebkit1.1-cil git-core python-nautilus

Depuis la version 12.04, tout est packagé de base, donc cette commande sera suffisante :

sudo apt-get install sparkleshare libwebkit1.1-cil git-core python-nautilus

Configuration

Le premier lancement du client vous permettra de renseigner quelques informations (nom, prénom, adresse mail) et vous affichera un petit tuto. Une fois passé cette présentation, il va falloir "relier" le client avec le serveur. Pour cela, récupérez le contenu du fichier présent dans le répertoire SparkleShare de votre homedir (il s'agit de la clé publique du client). Retournez sur le serveur puis lancez la commande suivante :

dazzle link

Après avoir appuyé sur Entrée, vous n'avez plus qu'à coller la clé publique de votre client, valider une dernière fois et le tour est joué.

Dernière étape, l'ajout du nouveau dépôt (le répertoire que nous avons créé ci-dessus) sur le client. Pour cela, il suffit de cliquer sur l'icône Sparkleshare de votre zone de notification puis "Ajouter un projet hébergé" :

Choisissez ensuite "on my own server" (notez que vous pouvez vous brancher sur des serveurs git publics tels que Github) puis renseignez l'adresse de votre serveur et le répertoire de destination (il s'agit des données que vous avez eu lors de la configuration du répertoire sur le serveur) :

    Address: ssh://storage@mon_ip:mon_port
    Remote Path: /home/storage/DOSSIER_CRYPTE-crypto

Après avoir validé, vous avez accès à votre répertoire (qui sera synchronisé avec tous les clients en temps réel).

Note : Je n'ai pas testé les clients Mac et Windows mais je suppose que l'installation et surtout la configuration sont à peu près identiques.

III. Conclusion

Sparkleshare est un très bon logiciel. Les échanges sont chiffrés (via SSH), rapides, l'installation n'est pas trop difficile et c'est basé sur git. Malheureusement, le gros point noir qui est vraiment rédhibitoire pour moi c'est que je ne peux pas retrouver mes fichiers directement sur le serveur. Dans le fameux répertoire créé sur le serveur, tout est hashé, crypté, bref, complètement inutilisable :

Autrement dit, il faut obligatoirement avoir un client pour accéder aux données. Moi je voulais pouvoir avoir les données disponibles depuis les clients mais également directement sur mon serveur. Sparkleshare ne propose pas cela.

C'est la raison pour laquelle je n'irai pas plus loin dans mon utilisation de cet outil. Il faut que j'en trouve un autre. Si vous avez des idées, faites-moi signe :)

Original post of Génération Linux.Votez pour ce billet sur Planet Libre.

« Movilización social para Ceibal » est LE livre à lire sur le projet OLPC.
Il s’agit d’une compilation d’un collectif de 30 auteurs de différents pays, impliqués dans des activités sociales de soutien de projets « Un ordinateur par enfant » en Uruguay où plus de 600.000 ordinateurs XO sont déployés.

Depuis un an, une équipe de bénévoles d’OLPC France a assurée la traduction de cet ouvrage de référence.

C’est presque le bout du tunnel ! mais nous avons maintenant de besoin d’aide pour la relecture de l’ouvrage.

Il y a une quinzaine de chapitres à relire allant de 1 à 10 pages, de complexité variable. Le travail consiste à faire de la relecture: corriger les erreurs d’orthographe ou de grammaire et s’assurer que cela a un sens et qu’il n’y a pas trop de répétitions d’un paragraphe à l’autre.

Il s’agit donc d’un boulot indispensable mais pas difficile et ne prenant pas beaucoup de temps pour ceux qui ont un bon français et un bon oeil !

Cécile, la chef d’orchestre de ce beau projet a préparé ici un tableau de synthèse du travail à faire. Alors si vous avez un peu de temps pour nous aider tout en découvrant le projet OLPC. Ecrivez à Cécile (cecile.r AT bluewin.ch) qui vous aiguillera en fonction de votre temps et vos capacités.

Merci d’avance !

Original post of OLPC France.Votez pour ce billet sur Planet Libre.

La Haute Disponibilité désigne toutes les techniques permettant d'améliorer la disponibilité d'un système ou de services et d'augmenter la tolérance aux pannes : la redondance matérielle, les clusters, la réplications des données à chaud
physiquement (RAID 1 et RAID 5) ou logiciellement (Snapshots, DRBD), les scénarios de crise (mode dégradés, plan de secours). Dans une grande entreprise, cela peut donner lieu à un poste à responsabilité à plein temps. Mon activité professionnelle m'a amené à mettre en oeuvre une facette de cette problématique : un cluster actif / passif qui assure la disponibilité d'un service applicatif.

Pour GNU/Linux, j'ai expérimenté deux logiciels permettant de gérer une infrastructure de cluster :

• Heartbeat qui a fait ses preuves mais qui est limité : pas de cluster à plus de 2 noeuds, pas de gestion très fine des ressources et des règles pour basculer d'un noeud sur l'autre.
• Corosync et Pacemaker : c'est le choix de la distribution Red Hat et celui que je vais détailler dans la suite de cet article.

J'ai monté une maquette assez représentative composée de deux machines virtuelles Debian Wheezy (en version presque finale) avec 4 interfaces réseaux chacune qui font tourner un service Apache qu'on accède par une adresse IP gérée par le cluster.

Voici un diagramme réseau de la maquette :

Les interfaces eth0 et eth1 font partie d'une agrégation logique de liens et servent au cluster pour vérifier l'état des autres noeuds. Elles constituent un réseau privé avec l'autre noeud dans le réseau 10.20.13.0/255.255.255.252. Les interfaces eth2 et eth3 font partie d'une autre agrégation logique, elles fournissent le service à l'extérieur dans le réseau 192.168.1.0/24.

L'agrégation logique (appelé aussi bonding) fournit une redondance supplémentaire. Si l'adaptateur réseau eth0 grille, le trafic transite encore grâce à eth1. On peut la configurer en mode actif/passif ou bien en mode load-balancing.

Voici la configuration des interfaces sur la machine vm-node1 dans /etc/network/interfaces/ :

auto bond0
iface bond0 inet static 
    address 10.20.13.1
    netmask 255.255.255.252
    bond_mode active-backup
    bond_miimon 100
    bond_downdelay 200
    bond_updelay 200
    slaves eth0 eth1

auto bond1
iface bond1 inet static 
    address 192.168.1.61
    netmask 255.255.255.0
    gateway 192.168.1.1
    bond_mode active-backup
    bond_miimon 100
    bond_downdelay 200
    bond_updelay 200
    slaves eth2 eth3

et la configuration du bonding dans /etc/modprobe.d/bonding :

alias bond0 bonding
alias bond1 bonding

La configuration réseau de la machine vm-node2 est symétrique avec bond0 en 10.20.13.2 et bond1 en 192.168.1.62.

Quand la configuration réseau est ok, on peut s'occuper du cluster. D'abord il faut installer Corosync et Pacemaker, c'est trivial sous Debian :

apt-get install corosync pacemaker

Ensuite il faut configurer Corosync. Il gère l'infrastructure de cluster, c'est à dire l'état des noeuds et leur fonctionnement en groupe. Pour cela, on doit générer une clef d'authenfication qui sera partagée par tous les noeuds du cluster. L'utilitaire corosync-keygen permet de générer cette clef à partir d'entrées clavier pseudo-aléatoires qu'il faut ensuite sécuriser et copier sur les autres noeuds.

# génération de la clef depuis vm-node1
corosync-keygen 
mv authkey /etc/corosync/authkey
chown root:root /etc/corosync/authkey
chmod 400 /etc/corosync/authkey

# copie de la clef sur vm-node2
scp /etc/corosync/authkey root@10.20.13.2:/etc/corosync/authkey

Corosync propose le concept d'anneaux de connexion pour assurer la communication entre noeuds. Dans le cadre de la maquette je définis deux anneaux : ring0, l'anneau de communication par défaut qui utilise le réseau privé et ring1 un anneau de secours qui transite par l'intermédiaire des commutateurs (ou switchs) avec le reste du trafic. C'est une sécurité de plus pour le cas improbable où les deux liens eth0 et eth1 soient cassés. Corosync permet de définir les anneaux en terme de réseau IP / masque réseau plutôt que de définir les adresses IP. C'est appréciable car le même fichier de configuration peut être déployé sur tous les noeuds sans rien changer.

totem {
    version: 2

    # How long before declaring a token lost (ms)
    token: 3000

    # How many token retransmits before forming a new configuration
    token_retransmits_before_loss_const: 10

    # How long to wait for join messages in the membership protocol (ms)
    join: 60

    # How long to wait for consensus to be achieved before starting 
    #a new round of membership configuration (ms)
    consensus: 3600

    # Turn off the virtual synchrony filter
    vsftype: none

    # Number of messages that may be sent by one processor on receipt of the token
    max_messages: 20

    # Limit generated nodeids to 31-bits (positive signed integers)
    clear_node_high_bit: yes

    # Disable encryption
    secauth: off

    # How many threads to use for encryption/decryption
    threads: 0

    # Optionally assign a fixed node id (integer)
    # nodeid: 1234

    # This specifies the mode of redundant ring, which may be none, active, or passive.
    rrp_mode: passive

    interface {
        ringnumber: 0
        bindnetaddr: 10.20.13.0
        mcastaddr: 226.94.1.1
        mcastport: 5405
    }
    interface {
        ringnumber: 1
        bindnetaddr: 192.168.1.0
        mcastaddr: 226.94.1.1
        mcastport: 5407
    }
}

amf {
    mode: disabled
}

service {
    # Load the Pacemaker Cluster Resource Manager
    ver:       0
    name:      pacemaker
}

aisexec {
    user:   root
    group:  root
}

logging {
    fileline: off
    to_stderr: yes
    to_logfile: no
    to_syslog: yes
    syslog_facility: daemon
    debug: off
    timestamp: on
    logger_subsys {
        subsys: AMF
        debug: off
        tags: enter|leave|trace1|trace2|trace3|trace4|trace6
    }
}

A ce stade, l'infrastructure de cluster est en place mais elle ne gère aucune ressource. Ca c'est le rôle de Pacemaker.

On impose les contraintes de fonctionnement suivantes :

1. les ressources (le service Apache et l'adresse IP du cluster) tournent sur le serveur vm-node1 dans le cas normal.
2. le service Apache et l'adresse IP du cluster doivent tourner sur le même serveur sinon notre service est injoignable.
3. si le service Apache se crashe sur le serveur primaire, on bascule sur le serveur secondaire.
4. si le serveur primaire ne joint plus la passerelle Internet, on bascule sur le serveur secondaire.

Pacemaker fournit quelques utilitaires en mode texte pour interagir.

• crm permet de gérer tout l'aspect configuration.
• crm_mon affiche l'état du cluster.

D'abord on définit la configuration globale. On désactive le STONITH (Shoot The Other Node In The Head) et le quorum. Le Stonith est la possibilité de tuer l'autre noeud s'il ne répond plus par l'infra de cluster. C'est faisable sur des vrais serveurs par IPMI par exemple. Quant au quorum, il n'a pas de sens sur un cluster à moins de 3 noeuds.

property stonith-enabled=false
property no-quorum-policy=ignore

On peut maintenant définir notre première ressource : l'adresse IP du cluster attaché au noeud actif.

primitive vip ocf:heartbeat:IPaddr2 params ip=192.168.1.60 cidr_netmask=24 nic="bond1" op monitor interval="10s"

Puis la ressource Apache, le service critique qu'on veut fournir dans cette maquette :

primitive httpd ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf" statusurl="http://localhost/server-status" op start timeout="60s" op stop timeout="60s" op monitor timeout="20s"

Le démarrage et l'arrêt d'Apache sont maintenant gérés par le cluster. Il faut fonc enlever le démarrage automatique du service. Sous Debian c'est avec update-rc.d :

update-rc.d -f remove apache2

Vous remarquerez qu'on va plus loin que la définition d'une ressource Apache. L'attribut statusurl permet à Pacemaker d'utiliser la page de statut d'Apache pour décider d'une bascule. Il ne faut donc pas oublier de configurer cette URL dans Apache pour que cela fonctionne :

 /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1

Comme on a construit la configuration pas à pas, crm_mon remonte peut-être des erreurs sur certaines ressources car elle n'étaient pas opérationnelles. Il y a un compteur d'échec qui lève un message d'avertissement. on peut remettre ce compteur à zéro comme ceci pour la ressource http :

crm resource cleanup httpd

A ce stade on a une adresse de cluster et une ressource HTTP, mais pas forcément sur le même noeud. la ressource vip va basculer si le noeud tombe. La ressource httpd va basculer si le noeud tombe ou si le service apache tombe (surveillance par l'URL /server-status).

C'est sympa mais pas très utile :-) On va aller plus loin et forcer les deux ressources à tourner sur le même noeud C'est faisable grâce au concept de la colocation :

colocation httpd-with-vip inf: httpd vip

Et on voudrait que dans le cas normal, les ressources tournent sur vm-node1, notre noeud primaire :

location preferred-node vip 100: vm-node1

Enfin, on rajoute une condition de bascule. Si le noeud ne joint plus la passerelle Internet, on veut basculer les ressources sur l'autre noeud Pour cela on définit une ressource de type ping qui tourne sur tous les noeuds (grâce au concept de ressource clonée). Puis on rajoute une règle de location pour basculer si le noeud actif ne voit plus la passerelle.

primitive ping-gateway ocf:pacemaker:ping params host_list="192.168.1.1" multiplier="1000" op monitor interval="10s"
clone cloned-ping-gateway ping-gateway
location vip-needs-gateway vip rule -inf: not_defined pingd or pingd lte 0

Voilà notre maquette est opérationnelle.

Original post of Yannic Arnoux.Votez pour ce billet sur Planet Libre.

A l’occasion de la crise entre Chypre et l’euro-système qui prétend ponctionner tous les comptes bancaires, Monnaie Libre reçoit Jean-Baptiste de « Frapper Monnaie » qui nous éclaire sur le point du vue du néo-chartalisme, ainsi que Gérard Foucher le producteur du « Mini-Show » et auteur des « Secrets de la Monnaie » pour un débat enflammé sur les possibilités ou impossibilités de changement des règles qui président la monnaie, du revenu de base, ou de l’émergence des monnaies numériques telles que BitCoin ou OpenUDC. De nouveaux points de vue qui s’affrontent sur ces problématiques explosives !

Jean-Baptiste

Gérard Foucher

- Pause musicale « beauty » Creative Common by sa de Tryad.
- Générique GNUArt « no more dreams » de nighter

Monnaie libre est diffusée sous Licence Creative Commons Attribution 3.0

Original post of Stéphane Laborde.Votez pour ce billet sur Planet Libre.

Aujourd'hui, une petite note permettant de monter un partage NFS. Ca sert toujours de garder ça dans un coin !

Prérequis

Installation du client nfs :

# yum install nfs-utils nfs-utils-lib

Démarrage des services :

# service rpcbind start
# service nfs start

On s'assure de les lancer au démarrage de notre machine :

# chkconfig rpcbind on

Vérifions le bon démarrage des services avec :

# netstat -nlp

Configuration

Ajouter dans /etc/fstab :

ip_du_serveur:/data/mon_rep_nfs  /mnt/mon_rep_nfs   nfs      rw,sync,hard,nointr,_netdev  0     0

Voici quelques explication (Merci à penthium2 ) :

• L’option rw indique que le système de fichier à monter est accessible en lecture et écriture
• L’option sync indique que le système de fichier à monter est synchrone
• L’option hard indique que le s'il y a un problème d'accès au partage NFS, alors la requête est ré-exécutée en boucle
• L’option nointr indique qu'in signal peut interrompre les opérations sur le montage (si hard, éviter intr qui pourrait entrainer une corruption des données
  
• L’option _netdev indique que le système de fichier à monter est un système de fichiers distant et doit donc être monté une fois que le réseau est actif
• En savoir plus : http://linux.die.net/man/5/nfs

Ensuite on recharge le fichier de montage :

# mount -a

Nous voilà avec notre client configuré !

Original post of Slobberbone.Votez pour ce billet sur Planet Libre.