26 décembre 2014

Lien sur Google Drive

La question du jour est: Comment obtenir le lien permettant de télécharger  directement un fichier depuis Google Drive ?

Avec Google Drive on peut partager un document en envoyant le lien sur ce document. Mais quand la personne clique sur le lien, Google Drive essaye de visualiser le document dans le browser et, s’il n’y arrive pas, propose de télécharger le fichier.  Ceci n’est pas élégant quand on veut que la personne télécharge le fichier immédiatement, sans passer explicitement par Google Drive.


ANALYSE

1. Quand vous demandez le lien de partage depuis la fenêtre de gestion du partage vous obtenez ce premier type de lien :
https://drive.google.com/file/d/0BxQ8UK7BXmDtSXNEQlFVTUd2S1E/view?usp=sharing




2. Quand vous demandez le lien avec bouton droit sur le fichier partagé vous obtenez ce deuxième type de lien :
https://drive.google.com/open?id=0BxQ8UK7BXmDtSXNEQlFVTUd2S1E&authuser=0

On obtient le même lien en sélectionnant un fichier et en cliquant sur la barre d'outils


Dans tous les cas, si on  clique sur l’un ou l’autre de ces liens on obtient ce message !



Mais si on clique sur "Télécharger", et que l’on à l’œil vif, on notera que pendant le téléchargement le lien est d’un troisième type :

https://docs.google.com/uc?id=0BxQ8UK7BXmDtSXNEQlFVTUd2S1E&export=download

nb: Le changement d'url est visible avec Chrome et IE 10+, pas avec FireFox.


Vous l'avez notez le point commun à ces 3 url est :  0BxQ8UK7BXmDtSXNEQlFVTUd2S1E

SOLUTION

Extraite du lien de type1 ou de type2 l’ID du document
    Type1 : https://drive.google.com/file/d/..........ID........../view?usp=sharing
    Type2 : https://drive.google.com/open?id=..........ID..........&authuser=0

Et construite un lien de type3:
    Type3 : https://docs.google.com/uc?id=..........ID...........&export=download

Ce lien de Type3 provoque un téléchargement immédiat du document

On peut envoyer ce lien par mail ou l'utiliser sur un site web, ou un blog ;-)

Canon 5Dmk2 Firmware History

Historique des Firmwares du
Canon EOS 5D Mark II 


Afin de ne pas être soupçonné de distribuer des virus les liens ci-dessous ne pointent pas vers des exe auto dé-compactables, mais directement vers les fichiers 5d200xxx.fir, où xxx est la version du firmware.

nb: Il ne sert à rien de les compresser puisque les fichiers .fir sont déjà compressés. Tous ces fichiers .fir ont une taille d'environ 9Mo (Ils en font environ 17Mo pour le EOS 5D Mark III)

Le date indiqué n'est pas celle de publications sut les sites de Canon, mais la date de création du fichier chez Canon (en général quelques semaines avant la publication officielle).

2.1.2 (01/fev/2012) : 5d200212.fir- Une version de Magic Lantern existe pour cette version.

1. Optimise les performances quand l'appareil est utilisé avec certaines cartes CF UDMA 7.

2.1.1 (12/oct/2011) : 5d200211.fir

1. Correction du phénomène d'arrêt de la prise de vue après la capture d'une image en prise de vue continue ou en prise de vue continue avec la fonction de bracketing automatique d'exposition (AEB).

2. Correction dans le menu en Néerlandais.

2.0.9 (17/mai/2011) : 5d200209.fir

1. Les vitesses d'écriture et de lecture lors de l'utilisation de cartes CF compatibles UDMA 7 ont été améliorées.

2. Correction du phénomène de non-fonctionnement de la stabilisation d'image (IS) lorsque la fonction personnalisée C.Fn III-2 est réglée sur [5: IS start] et que l'objectif fixé n'est pas doté d'un bouton d'arrêt de l'autofocus. C'est parce que la fonction personnalisée C.Fn III-2 permet à l'utilisateur d'attribuer l'activation de la stabilisation d'image au bouton d'arrêt de l'autofocus de l'objectif.

3. Correction dans les menus en Arabe, Portugais, Espagnol et Thaïlandais.

2.0.8 (28/sept/2010) : 5d200208.fir

1. Corrige le phénomène pour lequel les vidéos ne sont pas enregistrées dans le mode de prise de vue sélectionné dans les paramètres de l'utilisateur, si le mode de prise de vue priorité à l'ouverture (ou priorité à la vitesse) est choisi dans n'importe lequel des paramètres de l'utilisateur de l'appareil photo (C1, C2, C3) et que l'utilisateur essaie d'enregistrer une vidéo (Ce phénomène survient avec les appareils photo sur lesquels sont installés les versions 2.0.3 / 2.0.4 / 2.0.7 du micro logiciel).

2. Corrige le phénomène du non-déclenchement de l'obturateur lorsque vous appuyez sur le déclencheur et que la fonction d'arrêt automatique est réglée sur « activé ». Cela se produit à cause de la communication entre l'appareil photo et l'objectif ou le flash, ou à cause de la carte CF.

3. Corrige le phénomène  de surexposition survenant lors de la prise de vue en mode de simulation de visée par l'écran avec la vitesse ISO réglée sur L.
Ce phénomène survient uniquement lorsque le multiplicateur EF 2x est utilisé, que la vitesse ISO de l'appareil photo est réglée sur L (Basse) et que le mode de prise de vue est réglé sur P (programme d'exposition automatique).

4. Corrige le phénomène de retour aux paramètres par défaut du transmetteur de flash ST-E2 lorsque l'appareil photo ainsi que le ST-E2 sont réglés sur l'arrêt automatique. 5. Corrige un phénomène lors duquel le flash macro annulaire (MR-14EX, MT-24EX) et le flash esclave ne se synchronisent pas durant la prise de vue sans fil.

2.0.7 (11/mai/2010) : 5d200207.fir

1. Corrige un phénomène lors duquel le diaphragme bouge anormalement lors d'un enregistrement vidéo en mode d'exposition manuel et en mode priorité ouverture AE (mode Av) en utilisant certains objectifs Canon (tels que les objectives macros). Information supplémentaire : Ce phénomène implique un mouvement anormal du diaphragme de l'objectif lorsque la bague de mise au point se déplace (durant la mise au point). Pour les objectifs-zoom à ouvertures maximales variables, l'ouverture change lorsque la bague de zoom est utilisée (pendant l'action du zoom), mais il s'agit d'un comportement normal, et l'ouverture réelle change en fonction de la longueur de focale (la position du zoom).

2. Corrige le phénomène lors duquel le niveau d'exposition indiqué sur l'écran à cristaux liquides est différent de ce qui est affiché dans le viseur lors de la prise de vue d'images fixes en mode d'exposition manuel. 3. Corrige le phénomène au cours duquel le transmetteur de fichier sans fil (WFT-E4 ou WFT-E4 II) peut ne pas s'arrêter automatiquement lors de son utilisation pour des transferts FTP.

2.0.4 (18/mars/2010) : 5d200204.fir

La version 2.0.4 du micro logiciel incorpore cinq améliorations de la fonction vidéo et une correction de la fonction de nettoyage manuel du capteur de l'appareil photo EOS 5D Mark II.

1. Ajout ou changement des taux de trame d'image suivants.

a) NTSC

Version 2.0.4 ou ultérieure
Taille d'enregistrement / Listé / Réel ...
    1920 X 1080 / 30 / 29,97
    1920 X 1080 / 24 / 23,976    (nouveau)
    640 X 480 / 30 / 29,97

Version 1.2.4 ou antérieure
Taille d'enregistrement / Listé / Réel
    1920 x 1080 / 30 / 30,00
    640 x 480 / 30 / 30,00 .

b)  PAL

Version 2.0.4 ou ultérieure
Taille d'enregistrement / Listé / Réel
    1920 x 1080 / 25 / 25,00
    1920 x 1080 / 24 / 23,976    (nouveau)
    640 x 480 / 25 / 25,0

Version 1.2.4 ou antérieure.
Taille d'enregistrement / Listé / Réel
    1920 x 1080 / 30 / 30,00
    640 x 480 / 30 / 30,00

2. Ajout d'une fonction d'ajustement manuel du niveau sonore d'enregistrement (64 niveaux).

3. Ajout de l'affichage d'un histogramme (luminosité ou RVB) pour l'enregistrement de vidéos en mode d'exposition manuel. 4. Ajout des modes priorité vitesse AE (Tv) et priorité ouverture AE (Av) aux modes d'exposition pour l'enregistrement vidéo.

5. Changement de la fréquence d'échantillonnage audio de 44,1 kHz pat 48 kHz.

6. Corrige le phénomène d'interruption de la communication entre l'appareil photo et l'objectif survenant parfois après un nettoyage manuel du capteur. (Ce phénomène affecte uniquement les appareils dotés de la version 1.2.4 du micro logiciel.)

2.0.3 (Fev/2010) : 5d200203.fir

Les info de mise à jour ont été reprises dans la 2.0.4 (voir ci-dessus) mais dans la 2.0.3 la partie vidéo ne marche pas comme annoncée ! Cette version très attendue par les vidéastes avait été annoncée par Canon fin 2009.

Mode d'emploi v2 (jan/2010) : 5d2-fr-2.pdf (252 pages)

Mise à jour de la documentation pour intégrer les nouveautés du firmware 2.0.x


~ ~ ~  ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~

1.2.4 (02/dec/2009) : 5d200124.fir

1. Prise en charge du transmetteur de fichier sans fil WFT-E4 II qui était sorti en décembre 2009. Après la mise à jour du micro logiciel, si le transmetteur de fichier sans fil WFT-E4 ou WFT-E4 II est utilisé avec l'appareil photo, les indications apparaissant dans [Mode de communication] du menu [Paramètres WFT] changent comme suit : FTP -> trans FTP PTP(PC) -> EOSUtility HTTP -> serveur WFT Compte HTTP -> Compte WFT

2. Corrige le phénomène d'apparition possible de bruit apparent sur les images enregistrées en prise de vue continue Bulb. Cette mise à jour du micro logiciel corrige le phénomène de bruit qui peut apparaître sur les images enregistrées alors que l'image précédente est toujours en cours de génération, lorsque le paramètre [C.Fn II-1 Réduction du bruit pour longue exposition] est réglé sur [2: Activé].

1.1.0 (19/mai/2009): 5d200110.fir

1. Inclusion d'une fonction permettant le réglage manuel de l'exposition lors de l'enregistrement de vidéo. *Lors de l'enregistrement vidéo en mode manuel (M), la vitesse d'obturation *1), la valeur d'ouverture de l'objectif *2) et la vitesse ISO *3 peuvent être librement réglées pour permettre une plus grande flexibilité. Remarques : *1 Plage de la vitesse d'obturation : 1/30 sec. à 1/4000 sec. *2 Plage d'ouverture de l'objectif : valeur d'ouverture maximale à minimale de l'objectif utilisé *3 Plage de vitesse ISO : Auto : 100 à 6400 ISO réglé automatiquement Manuel : 100 à 6400 ISO, H1

2. Désactivation de la fonction du bouton d'aperçu de profondeur de champs lorsque les images sont visionnées ou que l'écran de menu est affiché sur l'écran à cristaux liquides. *Les images en cours de visionnage ou l'écran de menu pourrait disparaitre soudainement de l'écran à cristaux liquides. Comme ce phénomène pourrait être provoqué par une pression accidentelle sur le bouton d'aperçu de profondeur de champs, cette mise à jour du micrologiciel désactive la fonction d'aperçu de profondeur de champs pour résoudre ce problème.

3. Corrige le phénomène pour lequel le vignetage des images ne peut être correctement corrigé, même si les images ont été photographiées avec la fonction Correction du Vignetage de l'objectif activée. *La version 1.1.0 du micrologiciel corrige le phénomène lors duquel le vignetage de l'image pourrait ne pas être correctement corrigé à cause de l'objectif utilisé et des conditions de prise de vue.

4. Corrige l'algorithme de la fonction Auto Lighting Optimizer (correction automatique de la luminosité) lorsque la fonction personnalisée C.Fn II-3 Highlight tone priority est activée. 5. Corrige les indications incorrectes des écrans de menus en arabe, roumain, espagnol et ukrainien. 6. Modification des informations de batterie affichées sur l'appareil photo lors de l'utilisation de la poignée d'alimentation optionnelle BG-E6. *S'iln'y a qu'une batterie LP-E6 installée dans la poignée d'alimentation BG-E6, un message d'erreur est affiché en guise d'information de batterie concernant l'emplacement de batterie vide : Communication avec la batterie impossible. Cependant, avec cette mise à jour du micro logiciel, ce message d'erreur n'apparaît plus, même s'il n'y a qu'une seule batterie LP-E6 installée.

1.0.7 (18/dec/2008) : 5d200107.fir


1. Le phénomène de « point noir » (le côté droit de sources lumineuses en forme de point devient noir) Lors de prises de vues nocturnes, le côté droit de sources lumineuses en forme de point (comme les lumières provenant de fenêtres d'un bâtiment) peut devenir noir. Le phénomène peut devenir visible si les images sont grossies à 100 % ou plus sur un écran, ou si de grandes impressions des images sont réalisées. Ce micro logiciel corrige et atténue ce phénomène.

2. Bruit en bandes verticales Si le format d'enregistrement est réglé sur sRAW1, du bruit en bandes verticales pourrait devenir apparent en fonction des réglages de l'appareil photo, du sujet et de l'arrière-plan. Le micro logiciel corrige et atténue ce phénomène.

Remarques : Lors de la mise à jour à la version 1.0.7 du micro logiciel, mettez également à jour les logiciels Digital Photo Professional et Picture Style Editor aux versions suivantes ou ultérieures.
   - Digital Photo Professional : Version 3.5.2 ou ultérieure (pour Windows et Macintosh)
   - Picture Style Editor : Version 1.4.2 ou ultérieure (pour Windows et Macintosh)

Si les anciennes versions des logiciels sont utilisées pour afficher des images sRAW1 et sRAW2 qui ont été prises par un appareil photo doté de la version 1.0.7 du micro logiciel, les zones noires et de faible contraste des images pourraient apparaître légèrement magenta. Si les logiciels mis à jour sont utilisés pour afficher des images sRAW1 et sRAW2, les couleurs des images apparaitront normalement, indépendamment de la version du micro logiciel de l'appareil photo.

1.0.6 (sep/2008)

C'est la version qui était installée sur les premiers 5D Mk2 vendus à l'automne 2008.

Mode d'emploi v1 (sep/2008) 5d2-fr-1.pdf  (228 pages)

17/sept/2008: Canon annonce le EOS 5D Mark II.

25 octobre 2014

pg_hba + SSL



Dans les deux précédentes parties (pg_hba part1 et pg_hba part2) nous avons vu comment accepter les connections à un serveur Postgresql en local sans mot de passe, puis avec mot de passe, puis via le réseau. Le point faible de l’accès via le réseau est qu’il n’était pas obligatoirement crypté. Pourtant dans les environnements où le serveur n’est pas dans un réseau totalement sous contrôle (comme dans les hébergements  cloud) le cryptage s’impose.  C’est donc ce que nous allons faire maintenant : configurer et activer  l’authentification et le cryptage (via SSL) de notre serveur Postgresql  ET de notre client pgAdmin.

1) pg_hba.conf

Il n’y a qu'un seul mot à changer dans le fichier pg_hba.conf !
Il suffit de remplacer « host » par « hostssl » et on obtient une ligne du type :

hostssl     all    all    xx.xx.xx.xx/nn     md5

NOTES:
-    On parle ici de SSL, pas du SSH. Un tunnel  SSH est une autre technique utilisée quand le serveur et/ou le client ne supportent pas le cryptage de manière native.
-    Une ligne avec « host » accepte à la fois les connexions cryptées et non cryptées. Notre but étant de forcer le cryptage on ne doit pas garder de ligne « host » (sauf si elle est associée à des ip dont le chemin entre les clients et le serveur est totalement sous contrôle)


2) postgresql.conf

Là aussi pas grand-chose à faire. Il faut juste avoir la ligne « ssl = on » (et pas de ligne ssl =off !)

NB: Quand tout sera finit il faudra redémarrer le service postgresql.


3) Clés SSL coté serveur

Postgresql a besoin d’au moins 2 fichiers (server.crt et server.key) dans son répertoire data (PGDATA) pour pouvoir accepter les connexions SSL.  Comme le certificat du serveur sera signé par nous-même il n’y a pas besoin d’autres fichiers.
Le fichier server.key contient la clé privée du serveur. Ce fichier est secret et doit appartenir au daemon postgres et n’être lisible que par lui. Sinon ça ne marche pas !
Le fichier server.crt n’est pas secret, il contient le certificat du serveur. Il sera envoyé au client pour prouver l’identité du serveur. Il contient le nom du host où s’exécute Postgresql.

(voir plus bas le script bash genSrvKeyCrt qui génère automatiquement ces deux fichiers)


4) Clés SLL coté client

pgAdmin (ou autre client de Postgresql acceptant SSL) a besoin d’au moins 3 fichiers (root.crt, user-name.key user-name.crt).
Là aussi, le fichier user-name.key est une clé privée qui doit rester secrète et n’être lisible que par le client.
Le fichier user-name.crt est le certificat de l’utilisateur coté Postgresql. Il sera envoyé au serveur pour prouver l’identité de l’utilisateur. Il contient le nom de l’utilisateur coté Postgresql qui n’est pas forcément le même que l’utilisateur Unix ou Windows)
Le fichier root.crt est en fait exactement le même fichier que server.crt que l’on a déjà vu coté serveur.

(voir plus bas le script bash genCliKeyCrt qui génère automatiquement ces deux fichiers)


5) scripts + openssl

(ce qui suit est moins long qu'il ne parait ...)

Les deux fichiers coté serveur (server.crt et server.key) sont à générer en premier, et  une fois pour toute. Le fichier server.crt coté serveur servant de root.crt coté client pour tous les utilisateurs, si on régénère les fichiers coté serveur il faut régénérer tous les certificats des utilisateurs.

Les deux fichiers coté client (user-name.key  et user-name.crt) sont générés à la demande pour chaque utilisateur accepté par le serveur Postgresql. Ces fichiers étant associés à l’utilisateur de Postgresql ils peuvent être partagés par plusieurs utilisateurs Unix accédant à Postgresql de la même manière.

Pour simplifier la création de ces clés et certificats on va utiliser deux scripts shell qui enchaineront les commandes openssl nécessaires pour générer tous ces fichiers.

On suppose que les deux scripts sont quelque part dans le PATH et que l'on travaille dans cette arborescence :

...
  |
  +--> server/
  |     +--> server.key
  |     +--> server.crt
  |
  +-- clients/
       +--> user-name.key
       +--> user-name.crt
       +--> root.crt

En copiant les deux scripts ci-dessous attention à ne pas insérer d'espaces après les \ en fin de ligne.
 

======================
==== genSrvKeyCrt ====
======================
#!/bin/bash

HOST=$(hostname)

# Coté serveur on a besoin de deux fichiers.
#  1) server.key  (clé privée du serveur)
#  2) server.crt  (certificat/identité du serveur)

# 1.1) Création de la clé privé du serveur
openssl genrsa             \
        -des3              \
        -out server.key    \
        -passout pass:1234 \
        1024

# 1.2) Supprime la passphrase (1234) de la clé privé
openssl rsa             \
        -in server.key  \
        -out server.key \
        -passin pass:1234

# 1.3) Vérification
openssl rsa -in server.key -check -noout

# 2.1) Création d'un certificat auto certifié d'une validité de 10 ans
openssl req             \
        -new            \
        -x509           \
        -days 3650      \
        -key server.key \
        -out server.crt \
        -subj "/OU=pgserver/CN=$HOST"

# 2.2) Vérification
openssl verify -CAfile server.crt server.crt

# Afficher le certificat (facultatif)
# openssl x509 -in server.crt -text -noout


### end ###

L’exécution donne ceci :

    > cd /path/to/server
    > GenSrvKeyCrt.sh
    Generating RSA private key, 1024 bit long modulus
    ..................++++++
    ...++++++
    e is 65537 (0x10001)
    writing RSA key
    RSA key ok
    server.crt: OK


Copier server.crt et server.key dans le répertoire PGDATA du serveur Postgresql.
Veiller à ce qu'ils appartiennent à 'postgres' et qu'ils ne soit lisibles que par 'postgres'.

> ls -l /path/to/postgres/data/server.*
-rw------- 1 postgres postgres 769 Oct 24 19:56 /home/postgres/data/server.crt
-rw------- 1 postgres postgres 887 Oct 24 19:56 /home/postgres/data/server.key


REDEMARRER le service postgresql avec : systemctl reload postgresql


======================
==== GenCliKeyCrt ====
======================
#!/bin/bash

if [ "$1" == "" ]; then
  echo
  echo "   Usage: $0 pgUserName"
  echo "Exemples: $0 jean"
  echo "          $0 postgres"
  echo
  exit
fi

PGUSER=$1

echo
echo "Création de la clé et du certificat pour $PGUSER"
echo

# Coté client on a besoin de 3 fichiers
#  1) root.crt   (l’autorité de certification (nous!))
#  2) .key (clé privée de l'utilisateur)
#  3) .crt (certificat/identité de l'utilisateur)


# 1) importer root.crt du répertoire frère 'server'
cp ../server/server.crt root.crt

# 2.1) Création de la clé privée user-name.key pour le client
openssl genrsa             \
        -des3              \
        -out $PGUSER.key   \
        -passout pass:1234 \
        1024

# 2.2) Supprime la passphrase (1234) de la clé privée
openssl rsa                \
        -in  $PGUSER.key   \
        -out $PGUSER.key   \
        -passin pass:1234

# 2.3) Vérification
openssl rsa -in $PGUSER.key -check -noout

 

# 3.1) Création du certificat user-name.crt pour le client
openssl req                \
        -new               \
        -key $PGUSER.key   \
        -out $PGUSER.csr   \
        -subj "/OU=pgclient/CN=$PGUSER"

# 3.2) Signature par le serveur du certificat du client
openssl x509               \
       -req                \
       -CAcreateserial     \
       -in    $PGUSER.csr  \
       -out   $PGUSER.crt  \
       -CA    root.crt     \
       -CAkey ../server/server.key



#fichier maintenant inutile

rm $PGUSER.csr

# 3.3) Vérifications
openssl verify -CAfile root.crt $PGUSER.crt
openssl verify -CAfile root.crt ../server/server.crt

# Affiche le certificat (facultatif)
# openssl x509 -in $PGUSER.crt -text -noout


### end ###

L’exécution donne ceci :

    > cd /path/to/client
    > GenCliKeyCrt.sh  bidule

    Création de la clé et du certificat pour bidule

    Generating RSA private key, 1024 bit long modulus
    ...........................................++++++
    ..++++++
    e is 65537 (0x10001)
    writing RSA key
    RSA key ok
    Signature ok
    subject=/OU=client/CN=bidule
    Getting CA Private Key
    bidule.crt: OK
    ../server/server.crt: OK



Copier les trois fichiers (bidule.csrbidule.keyroot.crt) sur la machine client.
Puis configurer la partie SSL de pgAdmin comme indiqué ci-dessous.


La partie "Properties" est configurée comme d’habitude avec le nom du user (bidule) et son password. Mais maintenant tout sera crypté et le serveur comme le client se seront authentifié car partageant le même root.crt.

Le premier utilisateur pour le quel on fait tout cela est en général 'postgres'  et non 'bidule' ;-)


24 octobre 2014

Repository EPEL & REMI

Les packages de certaines applications ne sont pas disponibles sur les repositories configurés par défaut avec la distribution. Il faut alors aller les cherche sur d'autres repositories qu'il faut configurer soit même.

Par exemple, avec Centos / EL, le repository "EPEL" (Extra Packages for Enterprise Linux) ou les repositories de Remi Collet ne sont pas connus. Pour les installer il y a deux méthodes :  la facile et la moins facile !

Version facile (que pour EPEL)
On va essayer de voir si dans les repositories déjà configurés il y en a un qui contient la définition du repository EPEL.
On tape la commande :   yum search epel
On regarde dans ce qui s'affiche si le package existe et si oui, son nom exact.
Si le package existe on l'installe en général avec :  yum install epel-release
Si rien n’est trouvé passer à la version moins facile.

Version moins facile
Si la définition de EPEL n'est pas dans un package disponible il faut la télécharger puis l'installer à la main.
On va sur http://dl.fedoraproject.org/pub/epel
On choisit la version centos/el : 4, 5, 6, 7
On choisit l'architecture : i386, x86_64, ppc64
Si une liste de répertoires (a, b, c…) se présente on va dans le répertoire "e"
On cherche un package avec un nom du type  epel-release-X-Y.noarch.rpm  (le X et le Y étant variables)
On le télécharge sur la machine à configurer avec une commande du type (ici pour centos 7, 64 bits)
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpmEnfin on l'installe avec la commande : yum install epel-release-X-Y.rpm


Pour les repositories de Remy Collet il n'y a que la version moins facile qui marche, sachant qu'avec centos il faut déjà avoir installer EPEL. Le processus reste le même :
- trouver le rpm d'auto configuration (détails pour centos, fedora ici: http://rpms.famillecollet.com/)
- le télécharger (wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm)
- l'installer (yum install remi-release-7.rpm)


ATTENTION: Quand on a beaucoup de repositories configurés il peut y avoir des conflits. Quand on fait un yum update ou un yum install il faut bien vérifier le repository source.

Par défaut les repositories de Remi sont désactivés. Deux méthodes pour les activer :

- Editer le fichier /etc/yum.repos.d/remi.repo et y mettre le/les "enable=0" à "enable=1".


- Activer le bon repository au cas par cas. Par exemple :
yum --enablerepo=remi install nom-du-package 
yum --enablerepo=remi update  nom-du-package 
 
Pour voir les repositories actifs : yum repolist
Pour voir les repositories desactivés : yum repolist disabled




01 octobre 2014

mod_perl startup

Une fois que l'on a un couple {Apache2 + mod_perl2} adapté il faut faire une peu de configuration. Voici comment mettre en place mod_perl2  et verifier que tout marche.

Rappel: il faut au minimum mod_perl 2.0.9 pour Apache 2.4.x

1) Configurer Apache normalement pour qu'il affiche le fichier index.html de votre répertoire htdocs. Ceci est toujours utile de pouvoir servir des pages statiques sans faire appel à Perl.
NB: Inutile de configurer la partie cgi-bin, ou php ;-)


2) Quand l’étape #1 fonctionne ajouter cette simple ligne à la fin du fichier de configuration principale de apache (httpd.conf)

    Include conf/mod_perl2.conf

Ainsi on ne touchera plus au fichier de configuration principal, on travaillera sur mod_perl2.conf, dont voici le contenu de départ :

LoadModule perl_module modules/mod_perl.so

# la ligne suivante n'est utile que si on a installé le module
# Apache2::Request qui utilise APR::Request qui utilise libapreq2
#   yum install libapreq2
#   cpanm       APR::Request
#   cpanm       Apache2::Request
# (le but étant de ne plus utiliser CGI.pm)
LoadModule apreq_module modules/mod_apreq2.so

PerlPostConfigRequire /path/to/myCode/startup.pl
PerlOptions -SetupEnv
 

<Location /hello>
   SetHandler perl-script
   PerlResponseHandler Hello
   PerlOptions +ParseHeaders

</Location>

a) On charge le module mod_perl (c'est lui qui importe Perl dans Apache)
b) On désigne un script Perl à exécuter au démarrage de Perl (voir plus bas)
c) On désactive l'importation de l'environnement dans le contexte de chaque requête (plus sûr et plus rapide)
d) On annonce que l'url /hello sera traitée par le module Perl Hello.pm
Ce module gèrera lui-même les headers et il sera exécuté en tant que "perl-script" (bien que ce soit forcement un module)


3) Le module Hello.pm est très simple à écrire et à comprendre :

package Hello;
use strict;
use warnings;

sub handler {  # Le nom de la fonction est imposé
    print "Content-type: text/plain\n\n";
    print "Hello at : ". localtime . "\n";
    return Apache2::Const::OK;
}
1;


On le stocke dans /path/to/myCode/Hello.pm



4) Le script startup.pl ressemble à ceci

use lib qw(/path/to/myCode);   # voir "Attention #2" plus bas

use ModPerl::Util ();
use ModPerl::Registry ();
 
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::RequestUtil ();
use Apache2::ServerRec ();
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Log ();

use Apache2::Const -compile => ':common';

use APR::Table ();
use APR::Const -compile => ':common';

1;


Le plus important dans ce fichier est la première ligne car elle indique où seront vos modules Perl chargés de réponde aux requêtes. Les autres "use" préchargent des modules d'usage courant ce qui evitera de répéter ces "use" dans chaque module Perl.


Si vous devez ouvrir un accès à une base de donnée ce sera aussi dans ce script en utilisant Apache::DBI Exemple pour Postgresql

use Apache::DBI;
Apache::DBI->connect_on_init("dbi:Pg:dbname=myDB", 

  "myUSR", 
  "myPASS",
  {AutoCommit => 1, RaiseError => 1, PrintError => 1} 

);
Apache::DBI->setPingTimeOut("dbi:Pg:dbname=myDB", 30);


ATTENTION #1: Pour accéder à la base de donnée dans un module (handler) il faudra utiliser le classique $dbh = DBI->connect(...) Mais il faudra que tous les paramètres de connect() soit exactement les mêmes que ceux passé à connect_on_init();


ATTENTION #2: Dans le contexte de mod_perl2 "use FindBin;" ne marche pas comme espéré.
En effet $FindBin::Bin donne le point de démarrage du serveur Apache, pas celui de startup.pl.

A la place il faudra faire ce genre de gymnastique:

use File::Basename;
our $PERLBASE;
BEGIN {
  $PERLBASE = dirname( __FILE__ );
}
use lib $PERLBASE;



Dans tous les modules (handlers) vous pourrez accéder simplement à $::PERLBASE



25 septembre 2014

proxy ssh

Il arrive souvent que les machines d’un réseau de développement  ne soit pas accessibles depuis l’extérieur à l’exception d’une machine jouant le rôle de porte d’entrée (frontdoor.mydomain.com).

Pour accéder depuis l’extérieur aux machines internes on établit depuis son poste externe une première connexion ssh avec  frontdoor.mydomain.com puis, de là, on établit une seconde connexion ssh vers la machine interne sur laquelle on veut travailler. Donc une opération en deux temps.

On peut simplifier ceci en établissant des ‘tunnels’ entre le frontdoor et les machines internes qui vont faire en sorte qu’une connexion sur le port 8001 du frontdoor donne directement accès à dev1, qu’une connexion sur le port 8002 du frontdoor donne directement accès à dev2 etc…

On établit donc un tunnel entre le port 8001 du frontdoor et le port 22 de dev,
puis un tunnel entre le port 8002 du frontdoor et le port 22 de dev2 etc…

Pour cela on se connecte sur le frontdoor et on exécute par exemple ces 2  commandes pour établir deux tunnels :

ssh -N -f -L 8001:localhost:22 devusr1@dev1.mydomain.com

ssh -N -f -L 8002:localhost:22 devusr2@dev2.mydomain.com

Chaque commande va  demander le mot passe pour se connecter  avec le user voulu à la machine interne qui sera l’extrémité ‘22’ du tunnel. Si la clé publique du user de frontdoor  est acceptée par le devusr coté machine de développement aucun mot de passe n’est demandé.  (Cette possibilité est très utilise si on veut automatiser l’établissement et la supervision de ces tunnels)

Ceci fait on peut fermer la session avec le frontdoor, les tunnels resteront actifs.

Maintenant, pour se connecter sur dev1 depuis l’extérieur on tape
    ssh –p 8001 usr@frontdoor.mydomaine.com
et bien sur la commande suivante vous loguera sur dev2
    ssh –p 8002 usr@frontdoor.mydomaine.com
La demande de mot de passe sera pour l'utilisateur 'usr' sur frontdoor. Là aussi on peut aussi utiliser un système de clés.

NOTE
Du point de vue de la machine interne (dev1 ou dev2) vous êtes un utilisateur connecté depuis 127.0.0.1 pas depuis frontdoor. Facile à vérifier avec la commande ‘who ‘

Il y a plein d'autre utilisations de cette technique du 'Local Port Forwarding'. Mais attention au firewall qui peut se trouver devant le frontdoor et qui pourrait bloquer l’accès aux ports d'entré du tunnel (8001, 8002 dans notre exemple)

Il y aussi des variantes de cette technique :
- Remote port forwarding (on établit le tunnel dans l'autre sens en utilisant ssh -R à la place de ssh -L)
- Dynamic port forwarding (plus complexe et nécessite la configuration SOCKS)


18 septembre 2014

pg_hba.conf (part2)

(Dans la première partie on a vu comment configurer l'accès local à un serveur Postgresql)

Sachant que pour se connecter à distance (via le réseaux) à un serveur Postgresql il faut utiliser la commande
    psql -h host  database  username

On va essayer d’accéder à notre nouvelle installation de Postgresql se situant sur le serveur avec l'ip 192.168.0.3

> psql -h 192.168.0.3  postgres  postgres
psql: n'a pas pu se connecter au serveur : Connection refused
      Le serveur est-il actif sur l'hôte « 192.168.0.3 » 
      et accepte-t-il les connexions TCP/IP sur le port 5432 ?

Effectivement la première chose à faire est d’autoriser les connections venant du réseau.
Pour cela il faut éditer le fichier /var/lib/pgsql/data/postgresql.conf et y ajouter la ligne
    listen_addresses = '*'

puis redémarrer le serveur Postgresql
    systemctl restart postgresql

On ré-essaye :
    psql  -h 192.168.0.3  postgres  postgres
    psql: FATAL:  no pg_hba.conf entry for host "192.168.0.59",

    user "postgres", database "postgres", SSL off

Maintenant il faut autoriser les connections sur la base du triplet : (data-base, user, ip-client)

Pour faire simple on va ajouter cette ligne à pg_hba.conf
    host   all   all   all   md5
Ce qui signifie que s'il connait le password n'importe quel utilisateur de Postgresql peut se connecter à n'importe quelle base de données depuis n'importe où sur internet. C'est un peut trop ouvert !

En utilisant cette ligne
    host   all   all   samenet   md5
les clients devront être sur des machines du même réseau local que le serveur Postgresql.

En utilisant cette ligne
    host   sameuser   all   samenet   md5
Un user ne pourra se connecter qu'a la base de données qui porte son nom et seulement depuis une machine du réseau local. (config typique d'un environnement de développement dédié. Ne pas utilisé si le réseau local est trop ouvert, ni dans un environnement cloud)

En utilisant ces deux lignes en même temps
    host   webapp    webapp  w.x.y.z/32  md5
    host   sameuser  all     a.b.c.0/24  md5

Le serveur web situé à l'adresse w.x.y.z pourra se connecter à la base webapp avec le user webapp
et les développeurs du sous réseau a.b.c.0/24 pourront utiliser la base qui à le même nom que d'utilisateur.
Par exemple : postgres/postgres, webapp/webapp, webbackup/webbackup  jean/jean


Si vous avez pigez cela vous pigerez la petite doc qui se trouve au début du fichier pg_hba.conf


RAPPEL: Pour que les changements dans le fichier pg_hba.conf prennent effet il faut redémarrer le serveur Postgresl.

Info sur le codage md5 des mots de passe dans la table pg_shadow de Postgresql;
http://code18.blogspot.fr/2010/01/cracker-un-md5-de-postgresql.html




 

17 septembre 2014

pg_hba.conf (part1)

Dans cette première partie on va voir comment sécuriser Postgresql  juste après son installation.


1) Vous venez donc d'installer Posgresql 9.x et voulez vous connectez en tapant psql.

> psql
psql: FATAL:  role "bidule" does not exist


En fait, en absence d'information, psql utilise le nom de l'utilisateur coté Unix et essaye de s'en servir pour se connecter à la base de données du même nom.

En fait, pour l'utilisateur 'bidule'
    > psql
est équivalant de
    > psql bidule bidule

Le premier 'bidule' est le nom de la base de données et le second le nom de l'utilisateur coté postgresql.


2) Dans toute installation par défaut de Postgresql il y a une base de données nommée postgres et un utilisateur nommé postgres. Donc ceci doit marcher :

> psql postgres postgres
psql (9.2.7)
Type "help" for help.

postgres=# _


Effectivement, on a bien le prompt du serveur Posgresql.


3) QUOI ?! Pas besoin de mot de passe !!!
Incroyable : Sur la machine où s’exécute le serveur Postgresql aucun utilisateur local n'a besoin de mot de passe pour y accéder. Ceci est dû à cette ligne dans le fichier pg_hba.conf

    local   all   all  trust

Elle signifie qu'en 'local', toutes  les bases de données (premier 'all') sont accessibles par tous les utilisateurs (deuxième 'all') à qui l'OS a déjà fait confiance ('trust') en acceptant qu'ils se connectent sur la machine.

Bien sur ceci est un véritable problème sur une machine multi-utilisateurs.

Notez que cette méthode très libérale pose exactement les mêmes problèmes que le mot de passe par défaut connu de tout le monde ou que l'utilisateur par défaut sans mot de passe.


4) Les trois premières choses à faire sont, dans cet ordre :
- attribuer un password au user 'postgres'  (coté Postgresql, pas coté Unix)
- changer la ligne de pg_hba en: "local   all   all  md5"
- mettre en commentaire toute les autres lignes utilisant la méthode 'trust'

En remplaçant la méthode 'trust' par la méthode 'md5' on force tout utilisateur local à donner le mot de passe de l'utilisateur coté base de données. Encore faut-il qu'il en ait un...

4.1) Donc on se connecte à Posgresql avec:

    > psql postgres postgres

puis on tape ces deux commandes pour attribuer un mot de passe à l'utilisateur postgres :

    ALTER USER postgres WITH PASSWORD 'Secr3tPassW0rd';
    \q



4.2) Dans le fichier pg_hba on remplace sur la ligne local la methode 'trust' par 'md5'
et on met en commentaire les deux lignes host utilisant aussi trust
# host    all  all  127.0.0.1/32   trust
# host    all  all  ::1/128        trust
On sauve, puis on redémarre le serveur Postgresql :

    systemctl restart postgresql


4.3) Maintenant si on utilise la commande  psql on doit taper le mot de passe

    > psql postgres postgres
    Password for user postgres: xxxxxxxxxxxx
    psql (9.2.7)
    Type "help" for help.
   
    postgres=# _


Ouf !

Notez qu'en remettant la méthode d'authentification pour 'local' à 'trust' pour pourrez vous connecter à nouveau (en local) sans mot de passe, ce qui est bien pratique si vous l'avez oublié.

Ce qui signifie que le 'root' Unix a tous pouvoirs sur le serveur Postgresql puisque il peut outre passer l’authentification en modifiant le fichier pg_hba.conf

Passons à l’accès via le réseaux ...

15 septembre 2014

Postgresql 9 + Centos 7



Un rapide mémo sur l'installation de Postgresql 9.x sur centos7 avec un PGDATA personnalisé.


1: Installer postgresql
yum install postgresql postgresql-server


2: Créer le home directory de postgresql
mkdir /home/postgres
chown postgres:postgres /home/postgres


3: Initialiser le repertoire où postgresql va stocker ses bases de données et autres meta-data
su postgres
cd
initdb /home/postgres/data
exit


4: Configuration systemd
Ce qui suit a pour but de ne pas modifier la version d'origine de  /usr/lib/systemd/system/postgresql.service
La solution proposé par postgresql est d'utiliser .include mais il faut savoir que cette méthode  est obsolète (https://lists.fedoraproject.org/pipermail/devel/2014-July/200804.html)

Créer le fichier  /etc/systemd/system/postgresql.service
avec ces 3 lignes (respectez la case)

.include /usr/lib/systemd/system/postgresql.service
[Service]
Environment=PGDATA=/home/postgres/data

Si nécessaire ajouter la ligne suivante pour aussi changer le port
Environment=PGPORT=2345


5: Démarrer le serveur postgresql à la main

systemctl daemon-reload                (important)
systemctl start postgresql

verifier les log

systemctl status postgresql


6: Si tout va bien activer le démarrage automatique
systemctl enable postgresql 

Reste à configurer /home/postgres/pg_hba.conf
Voir ces 3 posts:

7: Installer les extensions

yum install postgresql-contrib

Toutes les extensions vont dans /usr/share/pgsql/extension
Pour installer une extension (par exemple adminpack) dans une base il faut se se connecter à cette base avec le user postgres et taper

CREATE EXTENSION adminpack;



8: Installer les .h


yum install postgresql-devel

Necessaire si on veut compiler un driver pour perl php ruby etc...
Par exemple quand un programme d’installation a besoin de libpq-fe.h


12 septembre 2014

APACHE 2.2 et Centos 7

Il y a de nombreuses raisons pour vouloir encore utiliser Apache 2.2 et de ne pas migrer vers Apache 2.4. L'une d'entre elles est l'utilisation de mod_perl2 qui ne fonctionne toujours pas correctement avec Apache 2.4.
Malheureusement l’installation d’Apache 2.2 sur centos 7 ne peut pas se faire avec yum car seule la version 2.4 est disponible. Voici comment procéder pour compiler Apache 2.2 et mod_perl2 sur centos 7 et mettre en place les fichiers nécessaires au  démarrage de httpd 2.2 avec systemctl (aka systemd).


1) Il faut avoir les outils de développements


yum group install "Development Tools"



2) Puis on va sur http://www.us.apache.org/dist/httpd/ et on repère la version la plus récente de httpd-2.2
puis on la télécharge et on la décompresse :


wget http://www.us.apache.org/dist/httpd/httpd-2.2.29.tar.gz
tar xvf httpd-2.2.29.tar.gz



On compile et installe apache 2.2.x

On utilise --prefix pour ne pas installer apache par dessus l’éventuelle version 'officielle'.

cd httpd-2.2.29
./configure --prefix=/path/to/apache22
make
make install


On démarre  apache (risque de conflit si une autre version utilise le port 80)


/path/to/apache22/bin/apachectl -k start


Et avec le browser ont doit avoir le classique « It works »


3) Pour compiler mod_perl et tester il y a plus de préparatifs ET une correction de bug:
(peut être certains des packages ci-dessous sont déjà sur votre machine)


yum install perl-ExtUtils-Embed
yum install perl-libwww-perl

yum install perl-CGI
yum install perl-Test-Simple
yum install perl-Linux-Pid
yum install expat

cd /usr/lib64
ln -s libexpat.so.1.x.0 libexpat.so.0


(Adaptez le version de libexpat à votre cas. Pour moi c'est 1.6.0)


4) On va sur http://apache.org/dist/perl/ repérer la dernière version de mod_perl2
puis on la télécharge et on la décompresse :

wget http://apache.org/dist/perl/mod_perl-2.0.8.tar.gz
tar xvf mod_perl-2.0.8.tar.gz
cd mod_perl-2.0.8


 
ATTENTION #1: Dans le fichier t/api/err_headers_out.t il faut remplacer à deux endroits:


     if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION==6.00;
par
  if defined HTTP::Headers->VERSION and HTTP::Headers->VERSION>=6.00;

Enfin on peut exécuter la séquence standard :


perl Makefile.PL MP_APXS=/path/to/apache22/bin/apxs
make
make test
make install



NB: Le fait d'avoir installé apache 2.2.x dans un répertoire spécifique n'implique pas que toute la partie mod_perl aille aussi dans ce répertoire. Une partie ira dans apache/include et apache/module mais les modules perl iront dans /usr/local/lib64/perl5


5) Quand on compile soit même Apache on ne bénéficie pas des petits plus apportés par un package comme par exemple la mise en place du script de démarrage. Voici donc comment installer cela avec un Linux, comme centos os 7, qui utilise systemd (sytemctrl) à la place les scripts init.d. On va créer deux fichiers :

a) Le premier est /etc/sysconfig/httpd22 
Il sert à configurer l’environnement et les paramètres à passer au daemon httpd.


OPTIONS="-f /path/to/conf/httpd22.conf"
LANG=C



b) Le second /etc/systemd/system/httpd22.service
Il est utilisé par systemd pour exécuter les commandes start/reload/stop et il fait référence au fichier créé ci-dessus.

[Unit]
Description=The Apache HTTP Server 2.2.x
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
KillMode=none
PIDFile=/path/to/apache22/logs/httpd.pid



EnvironmentFile=/etc/sysconfig/httpd22

ExecStart=/path/to/apache22/bin/httpd  -DFOREGROUND  $OPTIONS
ExecStop=/path/to/apache22/bin/httpd   -k stop       $OPTIONS
ExecReload=/path/to/apache22/bin/httpd -k restart    $OPTIONS

[Install]
WantedBy=multi-user.target



NB: C'est apache qui gère le fichier .pid. Par défaut il est avec les logs de apache, mais on peut changer sa position avec la directive PidFile. Dans ce cas il faut adapter le PIDFile=... dans notre fichier httpd22.service


Après avoir créé ces deux fichiers (et avoir un fichier httpd.conf correct) faire


systemctl daemon-reload
systemctl start httpd22
systemctl status httpd22


Si tout est ok rendre le démarrage automatique

systemctl enable httpd22

Ces 2 fichiers cohabitent très bien avec ceux de httpd 2.4. Si les eux doivent s’exécuter en même temps il faut faire en sorte qu'ils n'utilisent pas le même port en changeant le paramètre "listen 80" dans la config de l'un ou de l'autre.



ATTENTION #2: Quand on se compile un programme (comme ici Apache 2.2) avec ses propres répertoires d'installation on se retrouve avec des fichiers .h ou des librairies à des endroits non standards. Ceci peut poser problèmes par la suite.
Par exemple, si pour utiliser mod_perl on veut installer la librairies Apache2::Request, qui utilise APR::Request, qui est une interface avec la librairie C libapreq2.so, il faudra que le programme d'installation de APR::Request trouve libapreq2.so dans le répertoire ou on a installé notre version d'Apache.
La solution la plus élégante est d'ajouter un fichier apache22.conf dans le répertoire /etc/ld.so.conf.d/ . Ce fichier contiendra juste une ligne du type:

/path/to/apache22/lib

Après quoi on exécute ldconfig pour que ce nouveau chemin soit pris en compte.


Enjoy  2.2 ;-)