YetI

Ma carte mère est ainsi faite que la prise HDMI (télévision) est considérée comme affichage primaire, et la prise DVI (moniteur) est considérée comme affichage secondaire.

Tous les environnements de bureau proposent à l’utilisateur de paramétrer précisément les écrans : activés ou non, emplacements relatifs, etc. Encore faut-il s’être identifié ; avant cela, il y a l’écran de login.

Mon problème est que la télévision est hors de mon champ de vision lorsque je suis à l’ordinateur et que l’écran de login s’affiche dessus. Heureusement, la solution est simple !

This article has been translated to English.

I first heard of BitTorrent when Mandriva began encouraging its users to download the Linux distribution’s ISO files using BitTorrent, in order to lessen the load on Mandriva’s servers. Yet it is somewhat recently that I began to actually use it. To this end, I installed the transmission-daemon package from Debian.

Lacking experience and expectations regarding the BitTorrent protocol and Transmission, I simply set the latter up with /data/partial as the directory for the temporary files, and /data/share as the final destination for completed downloads; the latter is the place where I put all my shared files (LAN-wide). I thought that I would move the completed downloads to the right subdirectories as they appear…

There is a problem with this configuration: the BitTorrent protocol expects you to share (“seed”) what you have downloaded from other users, thus preventing you from removing the files once you have them. Of course, I wish to keep these files, but elsewhere!

Je vous conseille vivement de suivre les recommandations de la page de stribika sur le « Secure Secure Shell », ou « Secure SSH », qui visent à rendre le serveur SSH suffisamment sécurisé pour résister à la NSA, disent-ils…

This article has been translated to English.

La nouvelle version d’OpenSSH vient de sortir et sera rapidement intégrée à nos distributions Linux préférées ; excellente nouvelle ! Mais…

sshd(8): Support for tcpwrappers/libwrap has been removed.

Cela peut, à première vue, sembler inoffensif. Mais concrètement, cela signifie que le serveur SSH ne va plus consulter les fichiers /etc/hosts.allow et /etc/hosts.deny pour autoriser ou interdire l’accès au serveur en fonction de l’adresse IP de la machine qui se connecte.

Or DenyHosts utilise ce mécanisme pour protéger le port SSH du serveur. Cela marque, je le crains, la mort du projet DenyHosts. La distribution Debian l’a d’ailleurs retiré de sa logithèque. Il faut donc trouver une alternative.

Deux propositions reviennent régulièrement lorsqu’il s’agit de remplacer DenyHosts : Fail2ban et Sshguard. J’ai choisi Fail2ban car la dernière version de Sshguard date de quelques années (2011) et que Fail2ban est plus souple dans ses options de configuration.

This article has been translated to English.

I want to allow both SSH and HTTPS on port 443 of my server, because port 22 is often blocked by firewalls. The usual tool for this task is the excellent sslh tool, which can recognize SSH and HTTPS connections, but also HTTP, OpenVPN, tinc, and XMPP! Besides, sslh does not rely only on the “who speaks first, server or client?” technique, which makes it compatible with more SSH clients; an excellent port multiplexer indeed!

There is one drawback, though: sslh listens to a port on the server, receives an incoming connection from a remote client, detects the protocol, and then forwards packets for this connection to the adequate service; the problem is that the latter is seeing packets coming from the server itself (usually localhost), not from the IP address of the remote client.

J’utilisais auparavant un nom de domaine gratuit enregistré chez Dyn. Tout fonctionnait bien. Pourquoi changer ?

Après un premier billet sur la messagerie, puis un autre sur le web, je vais maintenant me pencher sur Jabber, qui permet davantage que la simple messagerie instantanée, en particulier lorsqu’on dispose d’un « vrai » nom de domaine.

This article has been translated to English.

Quand j’ai voulu mettre à jour Prosody sur mon serveur sous Debian, j’ai eu des erreurs, pas forcément prévisibles en lisant les notes de versions. La correction a heureusement été très simple.

This article has been translated to English.

J’utilisais auparavant un nom de domaine gratuit enregistré chez Dyn. Tout fonctionnait bien. Pourquoi changer ?

Après un premier billet sur la messagerie, je vais donner cette fois-ci l’exemple du web sécurisé (HTTPS), qui ne fonctionne vraiment bien dans les navigateurs qu’avec un « vrai » nom de domaine. J'en profiterai aussi pour aborder un aspect complémentaire lié à la messagerie.

This article has been translated to English.

In an older post, I inquired about the management of a domain name, in the context of a dynamic IP address. I concluded that such a configuration could be handled, notwithstanding the impossibility of a suitable handling of the DNS “PTR” record.

Now that I do have a domain name, let me use it…

Cet article est aussi disponible en français.

Dans un précédent billet, j’ai « enquêté » sur les tenants et aboutissants de la gestion d’un nom de domaine avec la contrainte d’une adresse IP dynamique. Ma conclusion fut que cette configuration serait gérable, avec pour seule réserve qu’il serait probablement impossible de paramétrer l’enregistrement DNS « PTR » de manière idéale.

J’ai maintenant un nom de domaine, voyons comment l’utiliser…

This article has been translated to English.