TinyMCE et Ruby On Rails autoriser certaines balises html

Sur un projet Rails où vous avez installé un tinyMCE suivant cette méthode, par défaut tinyMCE filtrera un certain nombre de balise HTML.
Si vous souhaitez autoriser la balise script (attention c’est assez dangereux si vous avez des rédacteurs mal formés ou mal intentionnés) il faut modifier le fichier config/tinymce.yml pour ajouter ceci :

Cela permet d’étendre la liste d’éléments valides par défaut de tinyMCE (plus d’infos sur cette liste) avec l’élément script et le « [*] » indique que cet élément peut avoir n’importe quel attribut (plus d’infos ici).

Et voilà, très pratique pour intégrer des tweets ou autres éléments dans la page.

Enjoy 😉

Debian – Apache2 reload vs restart mais pourquoi ?

Bon un petit billet pour expliquer un cas rencontré qui me semble des plus incohérents. Attention sur une ancienne version d’apache2 (la 2.2.16 autant dire une très vieille version).

Le contexte, je suis sur un serveur Debian en train de modifier des virtualhosts apache2, jusqu’ici rien de bien méchant.

Après ma modification (toute petite et n’ayant aucune conséquence sur la suite de l’histoire) je lance un « reload » d’apache2 => tout est ok.

Comme notre bonne pratique le veut (un peu comme chez les électriciens), c’est le dernier qui intervient qui est responsable donc pour éviter au copain de se prendre un restart qui failed à cause de ma modification (et ce potentiellement des mois après) je lance un « restart » d’apache2 et là bam ça failed. Je commente ma modification et je relance un « restart » et au surprise ça failed encore. J’en tire une première conclusion la bonne pratique n’a pas été respecté sur l’intervention précédente, bon cela arrive ce n’est pas le top mais ce n’est pas dramatique, la seconde conclusion que j’en tire et qui me pose beaucoup de souci, c’est là le souci réel c’est que la commande reload autorise des configurations qui ne sont pas bonnes alors que la commande restart elle ne les autorise pas donc à quoi sert d’utiliser une commande qui peu vous entrainer ce genre de soucis des mois après ?

Bon je me creuse la tête et je me dis tiens maintenant que je sais où est l’erreur je désactive le virtualhost concerné, je lance un « restart » => Ok parfait, je vais plus loin je réactive le virtualhost et je lance un « reload » et là devinez quoi bah OK donc la conclusion c’est quand vous avez une configuration qui ne passe pas en restart, commentez là, faites un restart, décommentez là et faites un reload mais oui bien sûr c’est super trivial.

Si certains comprennent ce genre de chose je suis preneur mais personnellement, je trouve ça incohérent surtout quand on sait qu’il y avait bien une erreur dans ma configuration. Donc le reload ne check pas autant que le restart et on ne peut être sûr d’une config qu’après un restart seulement.

Pas top 😉

Certificat ssl et virtualhost en 443 sur apache2 – debian

Si vous rencontrez une erreur de « restart » d’apache2 (attention le « reload » lui passe, ce que je ne comprendrai jamais c’est l’utilité d’une commande qui passe sur des configurations non valides plus d’explication ici) qui mentionne dans le fichier /var/log/apache2/error.log :

Il y a plusieurs points à vérifier le premier d’après ce forum est de vérifier que le chemin d’accès aux différents éléments de votre Virtualhost en 443 sont cohérents dans l’exemple suivant il faut vérifier « /etc/ssl/certs/domaine.fr.crt » et « /etc/ssl/private/domaine.fr.key » :

Dans mon cas cela n’a pas suffit, j’ai donc cherché un peu plus loin en relisant l’erreur qui m’indique que le serveur n’aurait pas de certificat de configurer pour quelque chose et je me suis aperçu que j’avais dans mes Virtualhost en 443, un Virtualhost de redirection comme ci-après :

Et là c’est le drame, oui on veut faire une redirection mais pour que cette redirection fonctionne il faut indiquer au serveur le certificat correspondant à domaine.fr, j’ai donc transformé mon Virtualhost en :

Et un « restart » d’apache2 plus tard tout est rentré dans l’ordre.

Enjoy 😉

Google autocomplete sur la france et les dom-tom

Si vous avez un champs autocomplete fait avec l’api Google maps places vous pouvez restreindre, la zone de recherche à un « territoire » par exemple la France métropolitaine assez facilement avec :

Si vous souhaitez, allez plus loin en ajoutant plusieurs « territoires », comme par exemple ajouter les dom-tom, il vous faut faire comme suit :

Pour comprendre les différents identifiants de territoires vous pouvez consulter la page Wikipédia sur la norme ISO 3166-1

Et voilà la zone de recherche sera plus large.

Enjoy 😉

Sources : https://developers.google.com/maps/documentation/javascript/reference?hl=fr#GeocoderComponentRestrictions, http://codepen.io/fchaussin/pen/VKboYd, https://fr.wikipedia.org/wiki/ISO_3166-1

Environnement d’exécution différents entre l’utilisateur et le cron de l’utilisateur

Une simple brève pour rappeler qu’un utilisateur que ce soit root ou un autre n’a pas le même environnement d’exécution que le cron de cet utilisateur. En d’autres termes ce n’est pas parce qu’une commande s’exécute correctement lorsque que l’on est connecté en tant que l’utilisateur X que cette même commande s’exécutera correctement dans un cron de l’utilisateur X (test fait sous debian).

L’environnement étant différent l’accès à certaines commandes ne se fait pas toujours de la même façon.
Ceux sont souvent des scripts peu classiques, par exemple un script de renouvellement automatique pour let’s encrypt comme proposé ici, s’exécutera très bien en root en ne tapant pas le chemin complet vers le script mais pas via le cron de root si vous n’indiquez pas le chemin complet vers le script. Il faut donc penser à tester ces crons, de manière quasi systématique pour être certains de la bonne exécution de ceux-ci.

Et voilà 😉

Récupérer les dates de début et de fin d’un certificat ssl en ligne de commande

Si vous avez besoin de récupérer rapidement et simplement les dates de début et de fin de certificat ssl pour par exemple vérifier le temps qu’il vous reste avant l’expiration il y a plusieurs solutions :

La solution simple via le navigateur : Vous vous connectez sur l’url à vérifier et vous inspectez votre certificat à travers le navigateur, action simple et visuelle.

Oui mais pas facile à automatiser cela demande une action humaine.

Si vous souhaitez monitorer les dates de manière automatique vous pouvez passer par une ligne de commande qui vous retourne les dates du certificat, la voici :
echo | openssl s_client -showcerts -servername monUrl.fr -connect monUrl.fr:443 2>/dev/null | openssl x509 -inform pem -noout -text | egrep "Not After :|Not Before:"

Cette ligne de commande vous sort ce résultat :

Not Before: Mar 24 07:28:00 2017 GMT
Not After : Jun 22 07:28:00 2017 GMT

Il est simple par la suite de récupérer les 2 dates (Not before : date d’émission du certificat, Not after : date d’expiration du certificat) et de les stocker comme bon vous semble et de faire les calculs qui vont bien pour vous prévenir quand l’échéance du renouvellement arrive.

Et voilà 😉

Source : http://serverfault.com/questions/661978/displaying-a-remote-ssl-certificate-details-using-cli-tools

Google maps Autocomplete déclencher la recherche au chargement de la page

Si vous avez mis en place un champ autocomplete de google maps et que ce champs et prérempli au chargement de la page et que vous souhaitez déclencher la recherche en conséquence, voici une petite astuce.

Cela consiste une fois tous les éléments chargés à simuler flèche du bas puis entrée sur la zone de recherche (souvent un input). Problème comment savoir que tous les éléments sont chargés car faire cette simulation trop rapidement ne fonctionne pas et aucun évènement n’est lancé d’après la doc google.

Du coup l’astuce consiste à attendre que la liste de propositions soit chargés et ensuite simuler la touche flèche bas puis entrée comme suit :

Voilà

Enjoy 😉

Petite astuce sur les encodages de string en Ruby

Si vous rencontrez cette erreur : Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ASCII-8BIT, sur la manipulation de string en Ruby, par exemple en lecture depuis un fichier vous pouvez prendre votre string est l’encodée comme suit :

La string est encodé en utf-8, vous pourrez la manipuler sans erreurs.

Enjoy 😉

Rest Client et téléchargement de fichier

Si vous utilisez la gem Rest Client vue dans plusieurs précédents articles ou même sans cette gem si vous faites des requêtes via Net:HTTP par exemple, sur un projet Ruby, que vous souhaitez télécharger un fichier en streaming depuis une url et que vous rencontrez cette erreur : « \x8E » from ASCII-8BIT to UTF-8, il y a une astuce assez simple.

Le fichier téléchargé est en binaire il faut donc indiquer à l’objet File que nous souhaitons écrire du binaire comment faire ? Comme vu dans l’article sur les zip :

C’est le file.binmode qui permet à l’objet File de comprendre que l’écriture se fera en binaire.

Et voilà

Enjoy 😉

Mysql restart ne fonctionne pas

Bon un petit article sur un cas bien particulier et pas simple à résoudre.

Le contexte vous avez un serveur avec des crons, on va dire beaucoup de crons ou des crons exécutés souvent ainsi qu’une partition racine / assez petite par exemple 10Go, et bien au bout d’un moment cette partition se remplie de manière importante soit dû à un remplissage de votre dossier /tmp comme vu dans un article précédent où nous expliquons comment déplacer le /tmp, soit dû au fonctionnement du service cron comme vu dans un autre article sur le remplissage de /var/mail/utilisateur.

La rencontre du problème :

Et un beau matin, vous n’arrivez plus à vous connecter sur votre PhpMyAdmin ou encore vos applications web sont toutes en rades avec des erreurs comme « Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock' ».

La solution en mode rapide :

Du coup on monte sur le serveur en ssh en root et un df -lh plus tard on s’aperçoit que la partition est pleine, ce qui explique le souci, il ne reste donc plus qu’à utiliser l’un des 2 articles cités ci-dessus pour répondre au problème (en priorité celui sur les mails moins compliqués et plus rapide pour récupérer de la place). Fin… ou pas.

Comment ça s’est passé pour nous ? :

Oui mais forcément si j’écris cet article c’est bien que ce n’est pas ce que nous avons fait. Non en tant que développeur nous on aime bien comprendre les choses et lire des logs avec des messages d’erreurs ça aide souvent à comprendre les choses. Donc on monte sur le serveur en ssh en root et on va faire un tour dans /var/log, on regarde un peu ce qui concerne mysql et on voit des choses comme des .gz au détour d’une extraction on se dit que c’est l’extraction qui a généré un dossier mysql ou pour une raison abstraite l’envie nous prend de supprimer le dossier mysql.
A ce moment là mysql est toujours en rade (car nous n’avons pas encore fait de df -lh et nous ne connaissons pas encore la raison du plantage de mysql) et nous avons fait un rm -rf de /var/log/mysql/ (Oui il y a des fois on prend des risques). Ensuite on fait notre df -lh et oui dans les logs on a vu quelque chose comme « no space left » et là on s’aperçoit que c’est l’espace disque qui manque, on vide les mails dans le fichier /var/mail/utilisateur et on se dit que dans une seconde ça sera ok donc on fait un /etc/init.d/mysql restart et là failed, on insiste et on redémarre la VM et là mysql failed encore.
Impossible on a fait de la place etc. On va voir les logs ? Bonne idée. C’est où déjà ? Dans le dossier /var/log/mysql/. Non tu te trompes ça n’existe pas ce dossier (et oui on a une mémoire de poisson rouge parfois). Et s’en suit une longue recherche sur notre ami Google.
On tombe sur un article de stack overflow. On tente le mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --socket=/var/run/mysqld/mysqld.sock et devinez quoi ça fonctionne mysql ce relance, on est tout content, on fait même un /etc/init.d/mysql restart et encore une fois c’est ok parfait.

Oui mais … :

Oui mais voilà on est au courant que nous n’avons pas relancer mysql dans les règles de l’art et pire que ça on sait qu’on prochain redémarrage de la VM, mysql n’arrivera pas à se lancer donc on veut comprendre. Et comme la loi de Murphy nous l’apprend et bien la vm a redémarré le lendemain pour une raison quelconque sur laquelle nous n’avions pas la main et forcément re-belotte mysql en rade. Il faut qu’on trouve pourquoi et après de longues recherches aussi stupide et intrépide que possible la réponse était simplement dans le fichier de conf qui précise le répertoire des logs d’erreurs mysql et oui dans le fichier /etc/mysql/my.cnf il y a une ligne qui loggue les erreurs : log_error = /var/log/mysql/error.log et ce fichier my.cnf n’est pas appelé lorsque l’on lance la commande mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --socket=/var/run/mysqld/mysqld.sock, c’est pourquoi elle fonctionne alors que la commande /etc/init.d/mysql restart utilise notre fameux fichier my.cnf c’est pourquoi elle ne fonctionnait pas à cause de la non existence du dossier /var/log/mysql/. Vous vous doutez bien que derrière on fait en root un mkdir /var/log/mysql puis on kill le process précédemment lancé en récupérant le process id via ps aux | grep mysql puis kill -9 ProcessID et enfin un /etc/init.d/mysql restart et là bonheur tout refonctionne comme au bon vieux temps.

Enjoy 😉

Source : http://serverfault.com/questions/782725/cant-start-mysql-service