Catégorie : Informatique

Articles traitant d’informatique, du sujet général au plus particulier.

Optimisation et SSD sous GNU/Linux

Depuis quelques mois, je dispose d’un SSD d’une centaine de giga sur lequel se trouve mes partitions systèmes. Le gain de performance est évidemment très appréciable. Mon Arch Linux démarre en quelques secondes; revenir en arrière serait bien difficile. Afin d’améliorer la durée de vie du SSD, intéressons-nous donc aux paramètres de configuration disponible.

Dans le fichier /etc/fstab, nous allons ajouter différents paramètres sur la partition ext4 située sur le SSD.

On ajoute en premier lieu, l’option noatime, permettant de ne pas écrire la date du dernier accès à un fichier si celui-ci n’a pas été modifié lors de cet accès. Ce qui nous donne:

UUID=865bc945-8437-25c6-df1b-ac3fe08bf901 / ext4 rw,noatime 0 1

Le second paramètre consiste à activer l’utilisation de la technologie TRIM. Cette technologie consiste à indiquer au SSD quels blocs de données ne sont plus utilisés et peuvent donc être effacés, améliorant ainsi les performances d’accès au disque. Pour l’utiliser, même démarche que précédemment mais en ajoutant cette fois l’option discard, ce qui nous donne:

UUID=865bc945-8437-25c6-df1b-ac3fe08bf901 / ext4 rw,noatime,discard 0 1

Avant d’activer l’option, il est bon de vérifier que notre SSD supporte cette technologie avec la commande:

# hdparm -I /dev/sda | grep TRIM
        *    Data Set Management TRIM supported (limit 1 block)
        *    Deterministic read data after TRIM

Pour plus d’informations sur le sujet, on pourra regarder du côté du wiki Arch Linux.

Vider le cache de pacman

En premier lieu, on utilise :

paccache -r

Cette commande a pour effet de supprimer toutes les versions d’un paquet, sauf la plus récente. Néanmoins, les paquets désinstallés resteront dans le cache, pour s’en débarrasser, on exécute donc:

paccache -ruk0

Toutes les versions des paquets désinstallés seront ainsi supprimées.

D’après pacman – ArchWiki.

Firefox: Url du serveur de synchronisation

Pour utiliser son propre serveur de synchronisation dans Firefox, il est nécessaire d’effectuer une petite modification dans about:config. Chercher la propriété nommée services.sync.tokenServerURI et la remplacer par l’url du serveur en faisant attention à ajouter token/1.0/sync/1.5 comme chemin.

Ce qui nous donne par exemple:

services.sync.tokenServerURI: http://sync.exmpl.com/token/1.0/sync/1.5

Source: Documentation Sync-1.5 Server.

Dubitatif

C’est le sentiment qui ressort après un petit test de Diaspora*.

J’ai installé une instance il y a quelques jours, un pod comme on dit. Côté wiki et documentation d’installation, rien à redire, une fois que l’on a la bonne configuration apache, tout fonctionne comme sur des roulettes. Diaspora* fait mieux que Movim sur ce point et j’arrêterai la comparaison ici pour me concentrer sur Diaspora*.

Le projet me plaît bien, l’interface est agréable… mais alors qu’est-ce donc qui assombrit le tableau? La découverte d’autres utilisateurs! Si vous connaissez quelqu’un présent sur un autre pod et êtes en possession de son identifiant (de la forme identifiant@autre-pod.org), aucun problème, vous pourrez ajouter cette personne à votre liste de contact et voir ses messages dans votre flux.

En revanche, impossible de suivre une personne postant des tags #photography sur un autre pod que le votre, sauf à priori par partage dans son flux de la part d’un contact présent sur le pod en question. Dans le cas d’un pod avec une faible population, les possibilités de découvrir une autre personne avec laquelle on aurait des intérêts communs semblent plus que jamais limitées.

Un dilemme se présente alors à l’utilisateur technophile. Commencer ou continuer à héberger un pod avec peu d’utilisateurs et ainsi, contribuer à une vision décentralisée du web, où chaque petite instance fait partie d’un ensemble plus grand. Ou céder à la facilité et rejoindre un pod avec une communauté plus grande, ou disposant de plus de visibilité donc attirant plus de monde. On pourra alors partager plus simplement ses dernières prises de vues, pensées,  opinions politiques, recettes de grand-mère et j’en passe. On repasserait alors à un système centralisé. Certes moins que les silos de données comme Facebook et Twitter.

Ce « problème » fait d’ailleurs l’objet d’une issue Github. A ce sujet, je vous conseille donc la lecture de cet article de Flaburgan qui résume bien le pourquoi du comment.

Sur ces considérations, j’ai donc pris la décision de tenter le coup et de continuer à faire fonctionner une instance de Diaspora* sur ce serveur. J’affinerai encore la configuration dans les semaines à venir et nous verrons bien ce que cela donnera. Alors, à bientôt sur Diaspora*!

[Apache] Redirection vers https

Exemple de redirection générale de http vers https avec Apache et mod_rewrite:

<VirtualHost *:80>
  RewriteEngine On
  RewriteCond %{SERVER_PORT} ^80$
  RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
</VirtualHost>
<VirtualHost *:443>
  # Configuration!
</VirtualHost>

Cette manière de rediriger me semble particulièrement intéressante dans le cas où l’on a besoin de déployer simplement une configuration Apache valable pour différents environnements ayant des noms de domaine différents. On évite ainsi d’avoir à définir explicitement l’url vers laquelle on redirige avec :

RedirectPermanent / https://demo.monprojet.org/

Avec la redirection par réécriture d’url, nous allons pouvoir déployer indifféremment le même fichier de configuration Apache sur les machines de pré-production, démo et test par exemple.

Le seul point qui pourrait poser problème concerne le certificat. Soit nous disposons d’un certificat wildcard valable sur tous les sous-domaines et dans ce cas là, cela devrait rester relativement simple. Dans le cas contraire, nous pourrions envisager de stocker les fichiers de certificats au même endroit et avec le même nom sur chaque machine.

  SSLEngine On
  SSLCertificateKeyFile /path/to/projet.key
  SSLCertificateFile /path/to/projet-cert.pem