Génération de certificats SSL

A priori un nouveau service permettant de générer gratuitement des certificats SSL devrait voir le jour : Let’s Encrypt.

Cette organisation, principalement sponsorisée par la Fondation Mozilla, Akamaï et Cisco, a pour but de permettre à tout un chacun de basculer ses sites en HTTPS à moindre coût, en fournissant un outil capable de gérer les certificats (création /renouvellement / révocation) voire même d’automatiser la configuration du serveur web (apache2).

D’après les dernières nouvelles du site, une première phase de génération de certificats à destination de bêta-testeurs devrait s’ouvrir à compter du 7 septembre prochain.
A suivre …

 

TRES BIENTOT !!!

posté le 17. août 2015 à 6:49 par francois · Permalink · Commenter le sujet
Catégories : Administration système, web

Finale Top 14 2015

N’étant supporter d’aucune des 2 équipes, le meilleur moment du match – que j’ai suivi sur France 2 – est un magnifique commentaire de l’ineffable Fabien Galthié, parlant du demi d’ouverture du S.F. :

« Cette fin de saison, il a porté son équipe à bout de bras … avec son pied droit ! »

J’adore !

Merci M. Galthié.

posté le 14. juin 2015 à 6:10 par francois · Permalink · Commenter le sujet
Catégories : humour, sport · Mots-clés: 

PostgreSQL et contenu HTML

J’ai rencontré dernièrement la problématique d’avoir à traiter dans une BDD PostgreSQL du contenu provenant d’une application Web qui renseignait certaines colonnes avec du contenu HTML. Si on n’a aucun problème à enregistrer et restituer ce type de contenu, les ennuis arrivent dès que l’on veut indexer ces textes ou récupérer les texte débarrassé des tags HTML.
De prime abord, la première idée est de chercher à faire le job via des expressions régulières pour ce qui est de se débarrasser des tags ; et effectivement après quelques recherches sur le net, on arrive à trouver des expressions qui semblent fonctionner.
Par contre, çà se complique au niveau de la transformation des éventuelles entités HTML par de jolis caractères accentués encodés en UTF-8 : faire une table de correspondances et rechercher / remplacer tout çà dans le contenu … Houlà, c’est sûr, je vais sûrement en oublier, bien probablement me tromper, et çà finira tôt ou tard par un loupé !

La seconde voie, et celle qui me semble à priori la moins coûteuse en temps et la plus fiable, consisterait à faire appel à l’un des langages de script embarqués (ou embarquables) dans PostgreSQL : plpgsql ne comporte pas ce genre de fonction, reste à utiliser un langage généraliste embarqué plperl ou plpython, d’autant qu’il sera alors possible d’utiliser une librairie couramment utilisée et bien testée écrite pour ces langages !

Au final, ce sera du Perl pour lequel la librairie HTML est disponible et semble pouvoir fournir l’ensemble des fonctionnalités requises.
Pour ce faire, il faudra me installer dans ma Debian les dépendances nécessaires :
apt-get install postgresql-plperl-9.4 pour l’extension Perl de PostgreSQL
apt-get install libhtml-strip-perl
apt-get install libhtml-parser-perl pour les librairies Perl que je souhaite utiliser.

puis activer l’extention plperl dans PostgreSQL :
CREATE EXTENSION plperlu;

(il faudra bien activer plperlu car plperl n’aurait pas accès aux librairies externes) et finir par créer mes 2 fonctions :


CREATE OR REPLACE FUNCTION pl_strip_tags(html text)
RETURNS text AS
$BODY$
use HTML::Strip;

my $hs = HTML::Strip->new();
my $clean = $hs->parse($_[0]);
$hs->eof;
return $clean;
$BODY$
LANGUAGE plperlu VOLATILE
COST 100;

pour réaliser la suppression des tags HTML

et


CREATE OR REPLACE FUNCTION pl_entity2char(html text)
RETURNS text AS
$BODY$
use HTML::Entities;
return decode_entities($_[0]);
$BODY$
LANGUAGE plperlu VOLATILE
COST 100;

Pour le décodage des entités HTML

qui s’utilisent facilement :
SELECT * FROM pl_strip_tags('<p>TEST</p>’);

retourne TEST en ayant bien supprimé les balises <p>
SELECT * FROM pl_entity2char('&eacute;té&eacute;');

retourne ‘été’

Au final, même s’il est possible qu’on perde un peu en performances (bien que çà reste encore à démontrer …) je pense que cette méthode permet de gagner en fiabilité et surtout en facilité de mise en œuvre !

posté le 20. mars 2015 à 10:20 par francois · Permalink · Commenter le sujet
Catégories : postgresql, web

Mise à jour rapide d’une version majeure de postgresql

Dans ce cas précis, la problématique se présentant étant de mettre à jour une base de données contenant près d’un gigaoctet d’objets géographiqes (postgis) sur une petite machine Atom tournant sous Debian Wheezy depuis PostgreSQL 9.2 vers PostgreSQL 9.4 … le principal écueil auquel j’ai précédemment été confronté lors de la migration 8.4 vers 9.2 étant que le dump/restore avait duré pratiquement une journée entière (surtout la phase de restauration, d’ailleurs qui avait poussé la machine dans ses derniers retranchements en termes de temps de calcul).
C’est bien pourquoi, cette fois-ci j’envisageai l’utilisation de pg_upgrade (non sans avoir toutefois généré un dump complet de ma BDD) !

Cet utilitaire doit être lancé par l’utilisateur postgres, toutes instances arrêtées, et doit pouvoir écrire des journaux de logs : il faut donc se positionner dans un répertoire où il aura les droits en écriture.

/etc/init.d/postgresql stop
cd /var/lib/postgresql

Une première exécution de la commande pg_upgrade

su postgres -c "/usr/lib/postgresql/9.4/bin/pg_upgrade --check --old-datadir=/var/lib/postgresql/9.2/main/ --new-datadir=/var/lib/postgresql/9.4/main/ --old-bindir=/usr/lib/postgresql/9.2/bin/ --new-bindir=/usr/lib/postgresql/9.4/bin/ -o ' -c config_file=/etc/postgresql/9.2/main/postgresql.conf' -O ' -c config_file=/etc/postgresql/9.4/main/postgresql.conf'"
2068 su postgres -c "/usr/lib/postgresql/9.4/bin/pg_upgrade --old-datadir=/var/lib/postgresql/9.2/main/ --new-datadir=/var/lib/postgresql/9.4/main/ --old-bindir=/usr/lib/postgresql/9.2/bin/ --new-bindir=/usr/lib/postgresql/9.4/bin/ -o ' -c config_file=/etc/postgresql/9.2/main/postgresql.conf' -O ' -c config_file=/etc/postgresql/9.4/main/postgresql.conf'"

échoue indiquant qu’il manque la librairie dynamique postgis-2.0 !

En effet, depuis la version 9.3, le dépôt pg_apt fournit l’extension Postgis en version 2.1 ; un simple lien symbolique permettra de tromper pg_upgrade, et pourra être en fin de procédure supprimé sans toutefois porter atteinte au bon fonctionnement de la BDD dans la mesure où l’extension est maintenant installée via un CREATE EXTENSION …

Donc

cd /usr/lib/postgresql/9.4/lib/ && ln -s postgis-2.1.so postgis-2.0.so

suivi d’une nouvelle exécution de la commande pg_upgrade précédente.
Et le quasi-miracle survient : au bout de quelques 5 minutes l’opération se termine avec juste un avertissement indiquant que les statistiques n’ont pas été mise à jour durant le processus, et qu’il faudra y procéder manuellement.

Au final, après relancement du daemon 9.4, la commande :

/usr/lib/postgresql/9.4/bin/vacuumdb -h localhost -U postgres -p 5434 --all --analyze-only

est lancée et dure quelques minutes supplémentaires afin de recueillir les données statistiques nécessaires au bon fonctionnement du planificateur.

Conclusion, une journée pour le précédent passage 8.4 vers 9.2, et une petite demi-heure pour la migration 9.2 vers 9.4 : chapeau bas pour les développeurs PostgreSQL !

posté le 23. décembre 2014 à 7:03 par francois · Permalink · Commenter le sujet
Catégories : Administration système, postgresql

Cacher un site wordpress derrière le proxy cache Varnish

Petite recette afin de mettre en place un proxy-cache Varnish pour un site wordpress pour Debian Wheezy … Pour ce cas d’espèce, toute la configuration nécessaire impacte le fichier /etc/varnish/default.vcl :

a/ Définir le « backend » correspondant au site à cacher :

backend wordpress {
.host = "192.168.0.1";    # IP du serveur Web à cacher
.port = "80";
}

b/ Définir la liste des adresse autorisées à purger le cache :

acl purge_wordpress {
"192.168.0.1";                    # C'est généralement le serveur Web qui est autorisé à purger le cache
}

c/ Définir les règles nécessaires au bon fonctionnement du site :

# Penser à bien tester l'ensemble des alias du site
if (req.http.host == "www.site-wordpress.local" || req.http.host == "site-wordpress.local"  || req.http.host == "alias-site-wordpress.local"  || req.http.host == "www.alias-site-wordpress.local") {
set req.backend = wordpress;
set req.grace = 2m;

# Ajuster l'en-tête X-Forwarded-For
remove req.http.X-Forwarded-For;
set req.http.X-Forwarded-For = client.ip;

# Supprimes les cookies has_js, CloudFlare/Google Analytics __* et statcounter is_unique
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_[_a-z]+|has_js|is_unique)=[^;]*", "");
# Supprimer le préfixe ";", si présent.
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", "");

# Les pages d'aministration et de login ne doivent pas être cachées mains retransmises au site.
if (req.url ~ "/wp-(login|admin|cron)") {
return (pass);
}

# Supprimer le cookie wp-settings-1
set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-1=[^;]+(; )?", "");

# Supprimer le cookie wp-settings-time-1
set req.http.Cookie = regsuball(req.http.Cookie, "wp-settings-time-1=[^;]+(; )?", "");

# Supprimer le cookie wp test
set req.http.Cookie = regsuball(req.http.Cookie, "wordpress_test_cookie=[^;]+(;)?", "");

# Ne stocker dans le cache que que contenu statique du thème (pas les images téléchargées par les utilisateurs)
# dans la mesure où le contenu des répertoires wp-content/uploads pourrait s'avérer très lours sur de gros sites et
# saturer rapidement le cache
if (req.url ~ "wp-content/themes/" && req.url ~ "\.(css|js|png|gif|jp(e)?g)") {
unset req.http.cookie;
}

# Même si aucun cookie n'est présent, le répertoire uploads ne sera pas caché en raison de sa taille potentielle
if (req.url ~ "/wp-content/uploads/") {
return (pass);
}

# Toutes les pages contenant un captcha doivent également être exclues du cache (à personnaliser au cas par cas)
if (req.url ~ "^/contact/" || req.url ~ "^/links/domains-for-sale/") {
return(pass);
}

# Vérifier les cookies spécifiques à wordpress et dans ce cas passer directement au backend
if (req.http.Cookie ~ "wordpress_" || req.http.Cookie ~ "comment_") {
return (pass);
}
# Autoriser la PURGE du cache depuis la liste d'adresses précédemment définie
if (req.request == "PURGE") {
if (!client.ip ~ purge_wordpress) {
error 405 "Not allowed.";
}
return (lookup);
}

# Ne pas cacher les requêtes comportant l'en-tête no-cache
if (req.http.Cache-Control ~ "no-cache") {
return (pass);
}

# Cacher tout le reste ...
return (lookup);
}

Un petit rechargement de Varnish, et le tour est joué !

posté le 14. octobre 2014 à 11:30 par francois · Permalink · Commenter le sujet
Catégories : Administration système, web, wordpress

Debian 6 (squeeze) LTS

Le projet Debian vient d’annoncer la prise en charge des mises à jour de sécurité pour la distribution squeeze (version 6) LTS, jusqu’en février 2016 (en fait, uniquement pour les plateformes i386 et amd64).

Pour en bénéficier, il faut rajouter la ligne suivante :

deb http://http.debian.net/debian/ squeeze-lts main contrib non-free

dans le fichier /etc/apt/sources.list/ (au moins pour les binaires).

Pour plus de détails, une page dédiée a été créée sur le WIKI DEBIAN.

posté le 21. juin 2014 à 5:25 par francois · Permalink · Commenter le sujet
Catégories : Administration système

recherche arborescente et remplacement de texte en ligne de commande

Juste pour mémoire, et fatigué de pratiquer des find | grep | sed …

Un petit utilitaire qui fait çà très bien : rpl !!!
Pour l’installer sous debian : apt-get install rpl, et le tour est joué.
Lire la suite de l’article »

posté le 9. janvier 2014 à 5:01 par francois · Permalink · Commenter le sujet
Catégories : Shell · Mots-clés: 

empêcher l’exécution de scripts PHP malveillants

Bien trop souvent, il arrive que des failles de sécurité dans des CMS web majeurs (wordpress, drupal, etc..) soient exploitées pour uploader sur le site des scripts PHP malveillants (généralement pour envoyer du spam ou faire télécharges des malwares).

Veiller à appliquer les les mises à jour de sécurité est donc un mal nécessaire, mais au delà il vaut mieux prévoir une mécanique pour se prémunir de l’exécution de ces scripts.
Dans ce premier temps, il faut déterminer les répertoires où les CMS vont stocker leurs données (c’est généralement les dossiers d’upload) et typiquement :
– pour Drupal : /sites/XXX/files/
– pour WordPress : /wp-content/uploads/

Pour y créer (ou modifier) le fichier .htaccess contenant le nécessaire empêchant l’exécution du PHP :
RemoveHandler .php .phtml .php3
RemoveType .php .phtml .php3
php_flag engine off

Bien sûr, ce c’est pas la panacée, çà ne fonctionne qu’avec Apache, et ne remplacera en aucun cas les mises à jours de sécurité ni empêchera les autres types d’attaques (injection SQL, XSS, etc…) mais c’est déjà çà …

posté le 6. août 2013 à 12:47 par francois · Permalink · Un commentaire
Catégories : drupal, web, wordpress · Mots-clés: 

Configuration de la recherche Solr pour Drupal 7

Le précédent billet concernait la mise en place d’un serveur virtuel dédié à l’hébergement d’un servlet d’indexation Solr 4.x ; c’est maintenant l’utilisation de ce service avec Drupal 7 qui va nous occuper …
Lire la suite de l’article »

posté le 3. juillet 2013 à 8:23 par francois · Permalink · Commenter le sujet
Catégories : drupal, web

Debian Wheezy : installation Solr pour l’indexation drupal7

Sous ce titre pompeux, il s’agira de détailler l’installation du service d’indexation Solr à l’effet de l’utiliser via un site web Drupal7 pour lui permettre d’indexer ses contenus (articles et fichiers attachés) grâce à l’utilisation des modules apachesolr et apachesolr_attachments.
Comme je n’aime guère Java (doux euphémisme pour rester politiquement correct !!!), l’installation se fera dans une machine virtuelle dédiée à cette utilisation, ce qui évitera de polluer un serveur web avec une machine virtuelle Java…
Lire la suite de l’article »

posté le 27. juin 2013 à 3:28 par francois · Permalink · 15 commentaires
Catégories : Administration système, web · Mots-clés: , ,