À la une de SQLPAC en 2019

La mise en route de la réplication en continu (streaming replication) avec PostgreSQL 9.6 sur des serveurs Linux Ubuntu 18.04 est très simple. Dans la réplication en continu, le serveur de standby se connecte au serveur primaire, lequel diffuse les enregistrements WAL (Write Ahead Log) au serveur de standby au fur et à mesure qu’ils sont générés, sans attendre que le fichier WAL soit rempli. La réplication en continu permet à un serveur de standby de rester plus à jour que ce qui est possible avec le transfert des journaux. Le serveur de standby peut être en lecture seule (read only) pour le reporting par exemple. Un point de replication (replication slot) garantit que les fichiers WAL nécessaires au serveur de standby ne sont pas supprimés dans le serveur primaire avant leur traitement par le serveur de standby. Plusieurs points de réplication peuvent être définis en fonction du nombre de serveurs standby.

Un guide rapide pour construire une base de données PostgreSQL 9.6 sur Ubuntu 18.04, guide incluant normalisation et personnalisation (port, répertoires des fichiers de configuration et de bases de données…). L’utilitaire historique pg_ctl demeure en charge de la gestion d’une base PostgreSQL (démarrage, arrêt, redémarrage…).

Une nouvelle fonctionnalité a été introduite avec SQL Server 2012 : dbcc clonedatabase. Cette nouveauté a été améliorée depuis SQL Server 2016 (objets supportés). Comment cela fonctionne et quel est le but de cette nouvelle fonctionnalité ? dbcc clonedatabase est très utile pour diagnostiquer l’impact du niveau de compatibilité (compatibility level) sur les requêtes dans un environnement de production avec des statistiques temps réel sans modifier directement et immédiatement le niveau de compatibilité de la base de données source, modification qui peut générer des effets de bord et qui doit être menée prudemment. Cette commande s’avère bien pratique aussi pour dupliquer une base de données avec uniquement les objets.

Modifier le port de SQL Server installé dans une zone WAN/DMZ n’est pas suffisant d’un point de vue sécurité, cela diminue les attaques potentielles mais n’empêche pas des outils de "snif" de lire les paquets TCP. Comment encrypter les paquets avec SSL / TLS 1.2 pour SQL Server sous Linux ? Les étapes sont faciles avec openssl et l’utilitaire mssql-conf. L’encryption est initiée et forcée par le serveur SQL Server avec un certificat auto-signé (self-signed certificate).

Microsoft SQL Server installé dans une zone WAN/DMZ et utilisant son port par défaut 1433 est vulnérable aux attaques. Le port d’un serveur SQL Server 2019 installé sur Linux est modifiable avec l’utilitaire mssql-conf. Le déploiement (automatisé) d’alias SQL Server sur les machines clientes lors du changement du port d’un serveur réduit considérablement les impacts négatifs.

TOUJOURS démarrer le moteur SQL Server sur Linux avec le compte mssql. NE JAMAIS EXÉCUTER directement le binaire sqlservr en tant que root. En effet, le moteur ne peut pas alors être ensuite redémarré normalement avec le compte mssql. Le diagnostic n’est pas aussi simple qu’à l’accoutumée dans ce genre de problème, des permissions sont altérées pour des fichiers systèmes binaires cachés de SQL Server (security.hiv…).

Dans l’architecture par défaut, SQL Server 2019 s’exécute avec le compte mssql. Lors de l’arrêt/démarrage/redémarrage du service mssql-server avec systemctl, le mot de passe est demandé. On souhaite autoriser mssql à gérer son propre service sans invites de saisie du mot de passe. 2 solutions sont possibles : définir mssql-server en tant que service utilisateur du compte mssql ou donner les droits avec aucun mot de passe sur le service système mssql-server au user mssql via sudo.

Et l’agent SQL Server sur Linux ? Oui il est présent, MAIS… Si la configuration et l’activation de l’agent SQL Server sont très simples avec mssql-conf, contrôler celui-ci l’est en revanche beaucoup moins. Sur Linux, l’agent SQL Server n’est pas associé à un service dédié comme sur Windows avec des conséquences non négligeables.

Qui l’eût cru en 2009, 10 ans plus tôt, Microsoft SQL Server 2019 sur les plateformes Linux ! Sur Ubuntu 18.04, une instance SQL Server 2019 est installée et configurée avec mssql-conf. Comme la majorité des entreprises implémentent des parefeux pour empêcher les serveurs de communiquer avec l’extérieur, les installations sont faites en mode hors ligne (offline) avec les packages *.deb fournis par Microsoft. Les fichiers de bases de données ne sont pas créés dans le répertoire par défaut. Après l’installation, 2 premiers tests sont réalisés : restauration sur SQL Server 2019 / Linux d’une base de données à partir de sa sauvegarde SQL Server 2016 / Windows et export/import d’une table avec bcp en mode natif de SQL Server 2016 / Windows vers SQL Server 2019 / Linux. Ces 2 tests montreront s’il est facile ou non, dans ce contexte cross-plateformes, de migrer des bases de données de SQL Server 2016 sous Windows vers SQL Server 2019 sous Linux.

Les trois premières étapes à réaliser pour sécuriser son nouveau serveur Ubuntu, dans le cloud ou pas :

• Modifier le port par défaut pour les connexions SSH.
• Désactiver les accès directs en SSH avec le compte root.
• Activer le parefeu ufw (Ubuntu Uncomplicated Firewall) en autorisant les connexions entrantes SSH.

Dans un contexte où SSH s’exécute sur un port différent de celui par défaut, comment activer pour la première fois ufw en toute sécurité en autorisant les connexions SSH ? Dans de nombreux articles, le lecteur est averti d’être prudent lors de l’activation d’ufw mais sans mentionner la commande ufw show added, cette commande garantissant qu’il n’y a pas d’erreur humaine avant l’activation d’ufw, erreur humaine qui peut couper les connexions SSH existantes sans possibilité d’en établir de nouvelles autrement qu’en sollicitant le fournisseur (cloud) ou en accédant physiquement au serveur.

Pour coder, vim est un excellent outil sur les systèmes Linux, mais quand on est habitué à utiliser sur Windows l’outil Active State Komodo Edit notamment pour ses fonctionnalités de définitions de projets, workspaces… on peut vouloir exécuter Komodo Edit sur Ubuntu et transférer l’interface graphique sur son client Windows 10. Active State Komodo Edit peut être installé et exécuté sur un système Ubuntu et l’interface graphique transféré vers un client Windows 10 grâce au "X11 forwarding". Les prérequis et l’installation sont assez simples.

Lorsque les bureaux graphiques ne sont pas installés sur un serveur Ubuntu, les interfaces graphiques sont cependant parfois nécessaires et doivent être transmises et affichées sur les machines clientes. On peut citer en exemples :

• Les programmes d’installation assez complexes (Oracle…), la version graphique étant souvent préférée aux installations en mode console et/ou installations silencieuses.
• Exécuter Android studio sur le serveur Ubuntu, plus puissant, plutôt que sur la machine cliente qui ne possède pas les pré-requis matériels (mémoire, CPU…) nécessaires à son installation.

Très peu d’étapes à suivre sur Ubuntu 18.04 et le client Windows 10 pour la mise en œuvre de cette mécanique.

Si il n’y avait jusqu’à maintenant aucune justification pour migrer un site Web du protocole HTTP vers le protocole sécurisé HTTPS avec SSL (Secure Socket Layer), ce n’est désormais plus le cas. Même si un site web ne délivre que du contenu (pas de e-commerce, de sessions…), Google et son moteur de recherche adoptent désormais la position du "HTTPS everywhere by default !". Les conséquences peuvent être très pénalisantes sur l’indexation d’un site en conservant le protocole HTTP. Au cours de la migration d’un site en HTTPS, divers aspects à aborder : l’environnement de développement en local avec HTTPS/SSL, les outils de développement pour détecter et corriger les "Mixed Content", les redirections des adresses HTTP vers les adresses HTTPS ainsi que la "check list" des actions à mener post migration (Google Analytics, Google Search Console, sitemaps, liens canoniques…).

C’est à présent incontournable, bien au delà des gains en performances possibles et des nouvelles fonctionnalités avec le protocole HTTP 2, exploitable uniquement en HTTPS/SSL (Secure Socket Layer), Google l’a annoncé : HTTPS Everywhere ! Les robots de Google, Google Analytics… délaisseront petit à petit les sites Web qui tournent encore avec le protocole non sécurisé HTTP. Comment simuler la mécanique HTTPS / SSL avec certificats en local sur son PC pour ses domaines virtuels afin de réaliser la migration ? Avec OpenSSL (Open Secure Socket Layer) et les certificats auto-signés (self signed certificates), le module des macros d’Apache 2.4 apporte une souplesse appréciable pour automatiser la définition de ses hôtes virtuels en HTTPS/SSL. Et c’est parti pour le debug et la chasse au "Mixed Content" grâce aux outils de développement des navigateurs afin de finaliser le 100% HTTPS /SSL de son site.

Pour administrer les serveurs Apache version 2.2, des scripts shell, awk… ont été d’un grand secours pour générer les fichiers de configurations nécessaires à la définition de multiples hôtes virtuels (virtual hosts…). Avec Apache 2.4 et son nouveau module mod_macro, les virtual hosts peuvent être définis de façon bien plus industrielle d’un point de vue administration. Cas pratique : 3 hôtes virtuels sont définis par macro et pour chacun d’eux la version de PHP diffère.

En 2019, c’est la fin de vie de deux produits Google qui attire l'attention : Google+ et Google URL Shortener (goo.gl). À vos claviers, il faut retirer toutes les portions de code qui implémentent le bouton Google +1 ou exploitent les API Google+ pour publier, partager... Google+ avait l’ambition de se mesurer au géant Facebook. Le flop a été monumental, très probablement parce que Facebook est désormais trop ancré dans les habitudes des internautes. Initialement prévue pour Août 2019, la fin de vie de Google+ est précipitée et avancée à avril 2019 après la découverte d’une nouvelle faille de sécurité (Expediting changes to Google+). Les données existantes (photos, vidéos, commentaires...) seront tout simplement supprimées, à charge pour l’internaute de s’occuper des sauvegardes (Procédure de téléchargement du contenu Google+). Goo.gl, l’outil de création de raccourcis de liens, raccourcis bien pratiques pour Twitter, et qui fournit les statistiques associées, disparaît également. À compter du 30 mars 2019, la création de nouveaux liens goo.gl ne sera plus possible, toutefois les liens créés avant cette date continueront de fonctionner. Google propose en alternative une migration vers son produit Firebase Dynamic Links (Transitioning Google URL Shortener to Firebase Dynamic Links), mais comme le dit le proverbe, chat échaudé craint l’eau froide, mieux vaut partir vers Bit.ly, bien plus simple. Même punition que pour Google+, tous les développements avec les API de goo.gl sont à revoir pour migrer vers les API du nouveau fournisseur de raccourcis de liens.