Le temps et PostgreSQL
A force d’utiliser PHP couplé à PostgreSQL, une mauvaise habitude s’est installée : les colonnes censées représenter un timestamp sont systématiquement déclarée TIMESTAMP WITHOUT TIME ZONE, tout simplement parce qu’avec un serveur configuré avec une TimeZone ‘Europe/Paris’ (CEST), celà reste très simple à récupérer depuis PHP pour représenter un horaire légal français.
Celà dit, çà commence à se compliquer quand la donnée doit représenter un horodatage en dehors de la France métropolitaine, et surtout si dans la même table des données horodatées sont censées concerner des lieux différents … Lire la suite de l’article »
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 !!!
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é.
Catégories : humour, sport · Mots-clés: humour
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('étéé');
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 !
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 !
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é !
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.
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 »
Catégories : Shell · Mots-clés: debian edition texte
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à çà …
Catégories : drupal, web, wordpress · Mots-clés: apache
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 »
Catégories : drupal, web
