Octopuce

Octopuce SARL recherche un développeur PHP/MySQL

Benjamin Sonntag, Saïd Bouaïssi — 2011-11-17T14:34:53Z

Notre société, à taille humaine, sert des clients de premier plan dans les secteurs des nouveaux médias, des agences web et de la vidéo sur Internet. Pour participer à la poursuite de son développement, elle recherche un collaborateur motivé, répondant au profil ci-après :

Descriptif du poste

Développement, déploiement et maintenance de sites web de contenus, d'applications web métier ou de diffusion vidéo en direct/à la demande.

Compétences requises

Maitrise des principaux langages du web PHP, Mysql, HTML et CSS.
Connaissance du JavaScript
Connaissance du framework officiel de PHP : Zend Framework
Connaissance du système d'exploitation GNU/Linux
Intérêt pour l'univers des logiciels libres et OpenSource

Compétences appréciées facultatives

Connaissance des langages d'administration système : bash, perl, python
Bases d'administration système Linux
Connaissance du CMS SPIP

Type de contrat : CDI
Lieu : 75011
Période d'essai : 1 mois renouvelable
Date de début : Décembre 2011
Salaire : selon expérience
Niveau : Bac +2 en informatique ou scientifique
Qualités requises : Grande Autonomie, Rapidité d'exécution

Envoyer CV et lettre de motivation à contact@octopuce.fr

PRESTATAIRE OU SOCIETE DE RECRUTEMENT S'ABSTENIR

Octopuce à Metz (Libre et Entreprises)

Chantal Bernard-Putz — 2011-10-23T08:18:47Z

Octopuce sera présent à la journée "Entreprises et Logiciels Libres" organisée par Moselle Numérique, le 28 octobre 2011.

Notre entreprise Octopuce sera présente à la journée "Entreprises et Logiciels Libres" organisée à Metz par Moselle Numérique, le 28 octobre 2011.

Chantal Bernard-Putz animera deux échanges :

Les logiciels libres : leur place (quels domaines ? quels usages ?) dans les entreprises. Leurs avantages dans un environnement professionnel. Pourquoi, à qualité égale opter pour le libre ?
Comment et où puis-je trouver de l'information sur le libre et me faire aider pour le déploiement dans mon entreprise (en collaboration avec les acteurs du Libre de Lorlibre)

Elle animera également un atelier :

Authentifier et chiffrer ses échanges sur internet avec des outils libres et légaux

Et présentera nos offres sur un stand, toute la journée.

Télécharger le programme de la journée

Comment utiliser les hooks de GIT pour mettre à jour automatiquement un site de développement

Benjamin Sonntag — 2011-01-19T17:50:00Z

Après avoir vu comment utiliser Gitosis sur un serveur pour y centraliser ses dépôts de source pour vos projets, nous allons voir comment mettre à jour automatiquement votre serveur de développement via les hooks de Git.

En effet, il nous est souvent demandé de pouvoir mettre à jour automatiquement les sources de la version de développement à chaque push d'un développeur. Pour cela, nous allons utiliser 2 outils très utiles : sudo (qui permet à Git de se faire passer pour votre compte web) et les hooks de Git (qui permettent de déclencher une action à chaque push.)

Pour cela, on procède ainsi :

Créer un script /usr/local/bin/pullhere comme suit :

#!/bin/sh
 cd "$1" 
 git pull

rendez-le exécutable via

chmod a+x /usr/local/bin/pullhere

modifier sudo pour permettre à l'utilisateur de gitosis d'utiliser cette commande en tant que www-data.

Pour cela, en lançant "visudo" ajoutez la ligne :

git ALL = (www-data) NOPASSWD: /usr/local/bin/pullhere

ensuite, dans chaque dépot où cela est nécessaire, ajoutez le hook suivant dans un fichier post-receive :

sudo -u www-data /usr/local/bin/pullhere /html/u/user/here

par exemple : dans /home/git/repositories/projet1.git/hooks/post-receive

attention : ce dossier (hooks) contient un exemple nommé "post-receive.sample" ce n'est pas ici qu'il faut créer votre ligne sudo, mais bien dans post-receive tout court (créez-le si besoin)

Enfin, rendez ce fichier exécutable comme suit :

chmod a+x /home/git/repositories/projet1.git/hooks/post-receive

ainsi, à chaque fois qu'un utilisateur effectuera un push sur ce dépôt git dans gitosis, un pull sera automatiquement effectué dans le dossier web de votre site de développement.

Dernière étape, il faut effectuer le clonage de votre git à l'endroit du site de développement (ici /html/u/user/here) pour cela, on procède ainsi :

cd /html/u/user/here
 git clone /home/git/repositories/projet1.git

Hébergement de dépôts GIT sur un serveur via Gitosis

Benjamin Sonntag — 2011-01-18T10:48:00Z

Octopuce hébergeant de nombreuses agences web, leurs clients et les projets de développement de tout ce petit monde, il nous est souvent demandé d'installer des systèmes de contrôle de version.

Nous utilisions jusque là subversion (svn) mais certains de nos clients utilisent maintenant GIT, le nouveau système de gestion de source distribué, visiblement plus léger et rapide que svn.

Nous avons donc dû nous poser la question de l'hébergement de ces dépôts GIT. Rapidement, nous sommes tombés sur le logiciel Gitosis, qui permet de gérer facilement ses dépôts git avec un accès SSH, mais sans nécessité de disposer d'un accès shell au serveur !

Voici donc comment utiliser gitosis sous Debian pour créer des dépôts

Gitosis, mode d'emploi

gitosis est facile à utiliser notamment par le fait qu'un package pour Debian existe, qui nous pose les 3 questions nécessaires au bon fonctionnement de gitosis : le nom du compte de gitosis (je conseille "git", court est explicite), le chemin dans lequel on stockera les sources (je conseille /home/git) et la première clé qui sera autorisée à utiliser le dépôt principal. Donc pour l'installer, il faut lancer sur le serveur de sources :

aptitude install gitosis git-core

Un dépôt "principal", nommé "gitosis-admin.git", permet d'administrer les droits d'accès aux dépôts sur le serveur. En effet, c'est via un dépôt GIT que Gitosis gère la liste des clés autorisées et la liste des autorisations d'accès en lecture ou en écriture aux dépôts.

Une fois gitosis installé (avec votre clé ssh personnelle) utilisez la commande suivante pour obtenir une copie locale du dépôt gitosis-admin :

git clone git@votreserveur.fr:gitosis-admin.git

vous obtiendrez un dossier gitosis-admin/ contenant un fichier gitosis.conf (dans lequel on définit les droits d'accès aux dépôts pour chaque liste d'utilisateur) et un dossier keydir/ dans lequel on créera un fichier au nom d'un utilisateur contenant la clé SSH publique de cet utilisateur.

Une fois cela fait, on envoie ces nouveaux fichiers sur le serveur gitosis via

git add . 
 git commit -a -m "ajout clefs et projets"
 git push

Par exemple, j'ai créé un groupe "octopuce" dans mon gitosis.conf, dans lequel les utilisateurs (listés dans la directive "members") ont droit d'accès en écriture (via la directive "writable") à des dépôts particuliers :

[gitosis]
 
 [gitosis-octopuce]
 writable = gitosis-admin projet1 projet2
 members = benjamin said

ainsi, dans keydir, j'aurais créé les fichiers "benjamin" et "said" contenant les clés de Saïd et Benjamin.

Une fois cela fait, on peut créer le dépôt, par exemple pour le projet1. pour créer le dépôt, sur votre ordinateur, créez vos premiers fichiers source, et tapez :

# On crée le dépôt local quelque part sur sa station de travail : 
 mkdir projet1
 cd projet1
 git init
 # On signale à git qu'il sera envoyé sur le serveur :
 git remote add origin git@votreserveur.fr:projet1.git
 # On lui ajoute les premiers fichiers : 
 touch README
 echo "Premier fichier d'initialisation" > README
 git add . 
 # Que l'on valide : 
 git commit -am "initialisation du projet1"
 # Enfin, on envoie tout cela sur le serveur.
 git push origin master:refs/heads/master

Et voilà, votre premier dépôt a été créé sur git.

Dans l'article suivant, nous verrons comment utiliser les hooks de git pour mettre à jour automatiquement un site de développement

112. Mondomix

Saïd Bouaïssi — 2011-01-11T16:08:42Z

Mondomix est un media numérique dédié à l'actualité et à la découverte des cultures et musiques du monde entier. Octopuce gère l'infrastructure d'hébergement web de ses sites propres (dont la plateforme de mp3) et des créations de l'Atelier 144.

Voir en ligne : http://www.mondomix.com

110. Price Water House Coopers France

Saïd Bouaïssi — 2011-01-11T15:52:56Z

PricewaterhouseCoopers (« PwC ») développe en France des missions d'audit, d'expertise comptable et de conseil pour des entreprises de toutes tailles, publiques et privées. Octopuce est en charge de l'administration système des serveurs Linux de PWC France.

Voir en ligne : http://www.pwc.fr

apt-mirror : BADSIG on security.debian.org (with solution)

Benjamin Sonntag — 2010-11-26T11:08:18Z

At Octopuce, we are Debian professional and are using Debian everywhere we can. For one of our customers, we maintained a mirror of Debian repositories, which are used by internal Linux servers.

This mirror is using apt-mirror since we cannot access the Internet by rsync or ftp protocol : we have to use http to mirror the repositories.

A few days ago, I saw the following error message on a Linux Debian server using this internal mirror :

 W: GPG error: http://fr-debianmirror lenny/updates Release: The following signatures were invalid: BADSIG 9AA38DCD55BE302B Debian Archive Automatic Signing Key (5.0/lenny) 
 W: You may want to run apt-get update to correct these problems

This issue was critical : the GPG signature of debian security repository was incorrect !! There were 3 places were this could happen :

At the Debian repository security.debian.org : I don't think so, or google would have told me ;)
During the mirroring process : maybe ...
At the final server location : each Debian machine have a GPG keyring of allowed keys for repository signature. The apt-key tool is used to manage this keyring, located at /etc/apt/trusted.gpg and /etc/apt/trustdb.gpg

chack apt-key configuration

First, check if the command "apt-key list" tell you that the faulty key is allowed. If it is not, you may add it by installing the proper debian package, for example :

aptitude install debian-archive-keyring

some people in the Internet tell you to use gpg —keyserver keyserver.fr —recv-key 0x9AA38DCD55BE302B | apt-key add -

but using the debian package should work "the right way" :)

Check the mirror

Of course, our Debian servers where properly installed, so we already had the ftpmaster Debian archive GPG key in our servers.

Next step: I checked the faulty file : it was located at /var/spool/apt-mirror/mirror/security.debian.org/debian-security/dists/lenny/updates/Release.gpg

This file should be a GPG signature of the Release file, located in the same directory.

There, I saw this :

.../debian-security/dists/lenny/updates/$ ls -l
 -rw-r--r-- 1 apt-mirror 835 2010-10-20 10:13 Release.gpg
 -rw-r--r-- 1 apt-mirror 40K 2010-11-22 21:12 Release

And here it looks obvious to me we have a problem: a signature cannot be older than the file it is signing !

In fact, our apt-mirror (which is using wget to download files) is using a proxy server to connect to the officials Debian mirrors. As such, I put the following in /etc/wgetrc :

http_proxy = http://10.42.12.12:8080/

and here is the problem: this proxy is unable to detect when the release.gpg file has been modified, and as such, he often returns an old version of this file !

To check this theory, I used wget with -S to see the HTTP headers returned by the server and the proxy :

fr-debianmirror:/tmp# wget http://security.debian.org/debian-security/dists/lenny/updates/Release.gpg -S
 --2010-11-26 12:08:43-- http://security.debian.org/debian-security/dists/lenny/updates/Release.gpg
 Connecting to 10.42.12.12:8080... connected.
 Proxy request sent, awaiting response...
 HTTP/1.1 200 OK
 Date: Fri, 26 Nov 2010 10:57:06 GMT
 Server: Apache
 Last-Modified: Mon, 20 Oct 2010 10:13:36 GMT
 ETag: "343-e08fc449a1532"
 Accept-Ranges: bytes
 Content-Type: text/plain
 Content-Length: 835
 Connection: close
 Age: 855
 Length: 835 [text/plain]

the lines in bold are the guilty one : the last modified date is not the right one, and the Age header tells us how old in the proxy cache is this entry.

Our solution

So, the solution was to tell wget to ask the proxy for a fresh version by using the —no-cache directive. A better way to use this is to add this line to /etc/wgetrc :

cache = off

and here we are :

wget http://security.debian.org/debian-security/dists/lenny/updates/Release.gpg -S
 --2010-11-26 12:17:39-- http://security.debian.org/debian-security/dists/lenny/updates/Release.gpg
 Connecting to 10.42.12.12:8080... connected.
 Proxy request sent, awaiting response...
 HTTP/1.1 200 OK
 Date: Fri, 26 Nov 2010 11:05:58 GMT
 Server: Apache
 Last-Modified: Mon, 22 Nov 2010 20:12:36 GMT
 ETag: "343-495a9e08a1500"
 Accept-Ranges: bytes
 Content-Type: text/plain
 Content-Length: 835
 Connection: close
 Age: 0
 Length: 835 [text/plain]

SFTP pour Openssh : comment logguer qui a fait quoi ?

Benjamin Sonntag — 2010-08-27T13:49:04Z

Dans la série truc & astuces, nous avons du récemment ouvrir des accès SFTP à certains de nos clients ou partenaires.

Étant très pointilleux sur la sécurité de nos infrastructures et celle de nos clients, nous avons souhaité pouvoir logguer qui effectuait quel transfert en SFTP sur le serveur correspondant (en plus d'y mettre un chroot...)

Or, par défaut, openssh et son serveur sftp-server ne loggue pas qui transfère (en lecture, écriture ou effacement) quel fichier.

Cependant, depuis la version 4.2, sfp-server sait logguer ce type d'action. Pour cela, il suffit de configurer votre sshd comme suit :

La ligne du sftp:

Subsystem sftp /usr/lib/openssh/sftp-server

doit être remplacée par la ligne ci-dessous :

Subsystem sftp /usr/lib/openssh/sftp-server -l INFO -f LOCAL0

Après redémarrage de ssh par /etc/init.d/ssh restart, on obtient, dans /var/log/syslog :

Aug 27 15:29:15 mg sftp-server[12]: session opened for local user admin from [91.194.61.194]
 Aug 27 15:29:15 mg sftp-server[12]: opendir "/home/admin"
 Aug 27 15:29:15 mg sftp-server[12]: closedir "/home/admin"
 Aug 27 15:29:24 mg sftp-server[12]: open "/home/admin/test.txt" flags READ mode 0666
 Aug 27 15:29:24 mg sftp-server[12]: close "/home/admin/test.txt" bytes read 5069 written 0
 Aug 27 15:29:31 mg sftp-server[12]: open "/home/admin/test.txt" flags WRITE,CREATE,TRUNCATE,EXCL mode 0666
 Aug 27 15:29:31 mg sftp-server[12]: close "/home/admin/test.txt" bytes read 0 written 184
 Aug 27 15:29:31 mg sftp-server[12]: set "/home/admin/test.txt" modtime 20100528-12:11:29
 Aug 27 15:29:31 mg sftp-server[12]: opendir "/home/admin"
 Aug 27 15:29:31 mg sftp-server[12]: closedir "/home/admin"
 Aug 27 15:29:34 mg sftp-server[12]: remove name "/home/admin/test.txt"
 Aug 27 15:29:34 mg sftp-server[12]: opendir "/home/admin"
 Aug 27 15:29:34 mg sftp-server[12]: closedir "/home/admin"
 Aug 27 15:29:39 mg sftp-server[12]: session closed for local user admin from [91.194.61.194]

IPv6 à Octopuce, une réalité

Benjamin Sonntag — 2010-07-27T06:21:50Z

Après près de un an à y réfléchir et à voir comment intégrer une dual stack (le mélange de IPv4 et IPv6 au sein de nos serveurs) et à tester diverses configurations, Octopuce a enfin obtenu et commence à déployer des adresses IPv6 sur son backbone d'hébergement !

Nous avons, le 14 juillet dernier, obtenu de l'autorité européenne de régulation de l'Internet (le RIPE, pour "Réseau IP Européen") un bloc d'IPv6 destiné à Octopuce, appellé bloc PI (pour Provider Independent) qui a pour joli préfixe 2001:67c:288 ::/48.

Nous disposons donc de la bagatelle de 1 208 925 819 614 629 174 706 176 adresses IPv6 disponibles pour nos hébergés.

Les premiers serveurs utilisant à la fois IPv4 et IPv6 sont installés et commencent à servir les pages web ou email indifféremment en v4 ou v6.

Si vous êtes un de nos clients et que vous souhaitez disposer de ces nouvelles possibilités, n'hésitez pas à nous contacter, nous nous ferons un plaisir de vous aider dans votre déploiement IPv6 sur vos infrastructures !

DManager : Nouvelle version du porte document en ligne

Chantal Bernard-Putz — 2010-02-06T12:05:55Z

La version 4.0 du DManager, porte-documents en ligne vient de sortir.

Réalisé en PHP / MySQL, placé sous licence GNU/GPL, DManager est un programme qui permet à chacun de partager des documents en ligne, via une interface web conviviale et configurable.
L'administrateur du porte-documents peut créer des comptes utilisateurs et définir finement les droits d'accès aux documents.

Depuis février 2003 (sortie de la première version), DManager a été téléchargé près de 80 000 fois !

Voici une copie d'écran de l'affichage des fichiers/répertoires

La version 4.0
conserve le moteur de recherche de la v3 et la possibilité d'alimentation par FTP pour les gros fichiers,
intègre quelques nouvelles fonctionnalités : gestion des droits plus fine, affichage du nom des utilisateurs qui envoient les fichiers, corrige quelques bugs de la version 3.

Elle permet une procédure de mise à jour très simple depuis la V3 vers cette nouvelle version.
Un installeur automatique de la V4.0 est disponible.
Une aide en ligne avec procédures expliquées "pas à pas" et copies d'écran est incluse dans DManager.

Pour le tester et/ou le télécharger :
Connectez-vous au site du DManager