Microblog : A very long article Wikipedia article on the orientation of toilet paper [7 jun à 22:52] [R]

Mercredi, 3 août 2016

Patching a Debian Package

Traduction: [ Google | Babelfish ]

Catégories : [ Informatique ]

I finally found a tutorial that explains how to patch existing Debian packages. I just did that for wmweather that stopped working after NOAA changed the URL where the METAR data is published.

In a nutshell, and in case the original web page disappears, it goes like that:

apt-get source wmweather
cd wmweather-2.4.5
dch --nmu
mkdir debian/patches # because it didn't exist
quilt new update-url.patch
quilt edit src/wmweather.c
quilt refresh
debuild -us -uc

After that I could simply install the new package that had been created.

[ Posté le 3 août 2016 à 22:10 | pas de commentaire | ]

Mardi, 12 juillet 2016

Harmonie et Gamme

Catégories : [ Science ]

Les musiciens et les mathématiciens se sont cassés les dents pendant des milliers d'années sur la définition de la gamme, des notes, des intervalles et des accords. Ce qui suit est le résultat de mes refexions sur la raison dei ces difficultés.

Soit une note, appelée C1, de fréquence f. Lorsqu'on joue cette note sur un instrument, des harmoniques de fréquence 2 f, 3 f… sont produites en même temps. L'octave C2 (de fréquence 2 f) est donc naturellement en harmonie avec C1. Lorsqu'on joue en même temps C1 et C2 de même niveau sonore, les deux fréquences interfèrent et produisent un son de fréquence égal à la moyenne de C1 et C2, donc 3/2 f, que l'on appellera G1. Ce nouveau son est modulé par une fréquence perçue 2 f - f = f, trop élevée dans la pratique pour entendre le battement. L'intervalle de fréquence C1 – G1 est appelé une quinte juste.

De la même manière, lorsqu'on joue en même temps C1 et G1 de même niveau sonore, on obtient une interférence de fréquence égale à la moyenne des fréquences de C1 et G1, soit 5/4 f. On appelle cette nouvelle note E1. L'intervalle C1 – E1 est appelé une tierce majeure, et l'accord C1 – E1 – G1 est appelé accord majeur.

En théorie de la musique, on peut traverser toutes les notes de la gamme en partant de C1 et montant d'une quinte, puis en répétant l'opération. Ainsi, on passe de C1 à G1, puis en montant encore d'une quinte on passe de G1 à D2, puis A2, puis E3 et B3. Enfin, en montant d'une quinte depuis F0, on arrive à C1. On pourrait donc imaginer calculer les fréquences de D, F, A et B de cette manière:

  • En augmentant F0 (fréquence 2/3 f) d'une quinte (donc en multipliant par 3/2) on arrive bien à C1 (fréquence f) ; ceci donne une fréquence de 4/3 f pour F1.
  • G1 (3/2 f) augmenté d'une quinte (multiplié par 3/2) donne D2 (9/4 f), et donc D1, une octave plus bas, a une fréquence de 9/8 f.
  • D1 augmenté d'une quinte donne de la même manière A1 (27/16 f).
  • A1 augmenté d'une quinte donne E2 (81/32 f), donc E1 a une fréquence de 81/64 f.

Mais on a vu plus haut que E1 devait avoir une fréquence de 5/4 f (soit 80/64 f) pour être en harmonie avec C1 et G1 ! C'est donc là que l'édifice commence à s'écrouler : la tierce C1 – E1 n'a pas le même rapport de fréquences que la tierce C2 – E2 ; en d'autres termes, E2 n'est pas exactement une octave au dessus de E1 si on s'en tient à la définition « par quintes ». Les deux définitions de la tierce étant incompatibles, il a fallu trouver une solution.

La manière dont les fréquences des notes sont définies s'appelle le tempérament, et de nombreux tempéraments on été inventés au fil des siècles. La solution retenue depuis le XIXè siècle est le tempérament égal, où tous les demi-tons sont séparés d'un rapport de fréquence égal à 21/12. Ce tempérament donne des accords qui sont tous faux, mais suffisamment peu faux pour que ce ne soit pas gênant.

[ Posté le 12 juillet 2016 à 12:43 | pas de commentaire | ]

Mercredi, 27 avril 2016

DNS 2: DNSSEC

Traduction: [ Google | Babelfish ]

Catégories : [ Informatique ]

Second part of my DNS setup notes, this time about DNSSEC. The following notes assumes there is already a running instance of Bind 9 on a Debian Jessie system for an imaginary domain example.com, served by a name server named ns.example.com.

The version of Bind 9 (9.9.5) on Debian Jessie supports "inline signing" of the zones, meaning that the setup is much easier than in the tutorials mentioning dnssec-tools or opendnssec.

Again these notes are mostly based on the example from the ISC Knowledge Base.

Setting up a signed zone

If you have a delegated zone (like home.example.com from the first part), do the following for both example.com and home.example.com.

Generate the keys
On a machine with enough available entropy in /dev/random (such as a Raspberry Pi with its hardware random number generator ) run
dnssec-keygen example.com
dnssec-keygen -fk example.com

(you can add the -r /dev/urandom option to the command if you dare, if /dev/random is too slow. It can literaly take hours to generate those keys otherwise).

Transfer the keys to the server where Bind is running.

Configure Bind

Create a /etc/bind/keys directory where to put the keys. Ensure the .private files belong to root, are readable by the group bind and not by other users.

In named.conf.options add to the options block:
options {
        …
        dnssec-enable yes;
        dnssec-validation auto;
        dnssec-lookaside auto;
        …
};

Create in /var/cache/bind a symbolic link to /etc/bind/db.example.com.

In named.conf.local, in the zone "example.com" block, add
zone "example.com" {
				…
        #file "/etc/bind/db.example.com";
        file "/var/cache/bind/db.example.com";
        key-directory "/etc/bind/keys";
        auto-dnssec maintain;
        inline-signing yes;
};

Note that the db file must point to a file in /var/cache/bind, not in /etc/bind. This is because bind will create a db.example.com.signed file (among other related journal files), constructed from the path of the "file" entry in the zone declaration, and it will fail doing so if the file is in /etc/bind, because Bind would attempt to create the .signed file in this read-only directory.

Then reload the configuration with
rndc reconfig
Then check that the zone is signed with
rndc signing -list example.com

Linking the zones

Your registrar should provide a tool (most probably Web based) where to put DS records for your domain.

On the DNS server, generate a DS record with
dig @localhost dnskey example.com | /usr/sbin/dnssec-dsfromkey -f - example.com
Copy and paste these lines in the registrar's tool. After a little while, you should be able to query the DS record with
dig @localhost -t ds example.org
If you have a delegated zone such as home.example.com, generate a DS record for that zone with
dig @localhost dnskey home.example.com | /usr/sbin/dnssec-dsfromkey -f - home.example.com
and place these lines in db.example.com (i.e., the db file for the parent zone). Change the serial number of the zone in the same file and run
rndc reload
You should then be able to query the DS record with
dig @localhost -t ds home.example.org

You can use Verisign's DNS debugging tool to check that the signatures are valid and DNSViz to view the chain of signatures from the TLD DNS down to your DNS. This also helped me figure out that my zone delegation was incorrect and caused discrepancies between my primary DNS server and the secondary server.

[ Posté le 27 avril 2016 à 19:21 | pas de commentaire | ]

DNS 1: Dynamic DNS

Traduction: [ Google | Babelfish ]

Catégories : [ Informatique ]

Now that I have my own server, I can finally have my own DNS server and my own domain name for my home computer that has a (single) dynamic IP address.

The following notes assumes there is already a running instance of Bind 9 on a Debian Jessie system for an imaginary domain example.com, served by a name server named ns.example.com and you want to dynamically update the DNS records for home.example.com. This is largely based on the Debian tutorial on the subject, solving the problem that bind cannot modify files in /etc/bind.

On the server

Create a shared key that will allow to remotely update the dynamic zone:
dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DDNS_UPDATE
This creates a pair of files (.key and .private) with names starting with Kddns_update.+157+. Look for the value of Key: entry in the .private file and put that value in a file named /etc/bind/ddns.key with the following content (surrounding it with double quotes):
key DDNS_UPDATE {
        algorithm HMAC-MD5.SIG-ALG.REG.INT;
        secret "THIS IS WHERE YOU PUT THE KEY";
};

You can then delete the two Kddns_update.+157+ files. Ensure that /etc/bind/ddns.key belongs to "root" and to the "bind" group, and is not readable by other users.

Then in named.conf.local, include the key file and declare a new zone:

include "/etc/bind/ddns.key";

zone "home.example.com" { type master; file "/var/cache/bind/db.home.example.com"; allow-update { key DDNS_UPDATE; }; journal "/var/cache/bind/db.home.example.com.jnl"; };

In /var/cache/bind create the file db.home.example.com by copying /etc/bind/db.empty and adapting it to your needs. For convinience, create a db.home.example.com symbolic link in /etc/bind pointing to /var/cache/bind/db.home.example.com.

In db.example.com (that is, the parent zone), add a NS entry to delegate the name home.example.com to the DNS server of the parent zone:
home.example.com NS ns.example.com

You can now reload the bind service to apply the configuration changes.

I also found examples of how to test the dynamic zone with nsupdate.

On the home computer

I decided to use ddclient 3.8.3 because it supports dynamic dns updates using the nsupdate tool. I backported that version of ddclient manually from a Debian Testing package; it's written in Perl and the backporting is trivial.

Copy /etc/bind/ddns.key from the server to /etc/ddns.key on the home computer (the one running ddclient), ensuring only root can read it. Then add the following to /etc/ddclient.conf (be careful with the commas, there is no comma at the end of the second last line):
protocol=nsupdate, \
zone=home.example.com, \
ttl=600, \
server=THE_IP_ADDRESS_OF_THE_DNS_SERVER, \
password=/etc/ddns.key \
home.example.com

You can then try out the new setup.

[ Posté le 27 avril 2016 à 18:15 | 1 commentaire | ]

Mercredi, 13 avril 2016

Minimum Password Entropy

Traduction: [ Google | Babelfish ]

Catégories : [ Informatique ]

What is the minimum entropy for my home computer's password?

In recent (post-2007) Debian (and probably other) Linux distributions, the passwords are stored in /etc/shadow using the sha512crypt algorithm. According to Per Thorsheim, with 2012 hardware, a single Nvidia GTX 580 could make 11,400 attempts at brute-force cracking such a password. This means that a log2 11,400 = 13.5 bit password could be cracked in 1 second.

To have a password that would resist a year to such a brute-force attack, one must multiply the password complexity by 86,400×365 (seconds per year) i.e., add 24.5 bits to the password for a total of 38 bits.

But this password is guaranteed to be cracked in a year. To make the probability of cracking such a password much lower, let's say less than 0.01, one must increase the password's complexity by a hundred times i.e., add 6.7 bits. We now have a minimum of 44.7 bits.

If one does not want to change the password for the next 10 years (because one is lazy), one must again increase the complexity tenfold (that's another 3.3 bits for a total of 48 bits) and account for the increase in processing power in the coming years. Between 2002 and 2011, CPU and GPU computing power has been multiplied by 10 and 100 respectively i.e., +0.37 and +0.74 bits/year. That means that the password's complexity must be increased by 0.74 ×10 = 7.4 bits. We have now reached 55.4 bits.

Now we need to guess who are the password crackers. How many such GPU will they put together? Titan has 18,688 GPUs (add another 14.2 bits to stay ahead of it), and the (more affordable) machine that cracked LinkedIn leaked passwords had 25 GPUs (requiring to add only extra 4.6 bits).

Assuming the crackers have a 25-GPU setup and not a gigantic cluster, 60 bits should be perfectly safe. If they are a government agency with huge resources and your data is worth spending the entirety of that cluster's energy for 10 years, 70 bits is still enough.

The same article also mentions an Intel i7, 6-core CPU would make 1,800 attempts per second i.e., 10.8 bits. For a password that must resist for 10 years, that would mean 49 bits. Titan has 300,000 CPU cores (50,000 times more than the i7), so that makes an extra 15.6 bits for a total of 64.6 bits. The Tianhe-2 has 3,120,000 cores, adding 19 bits to the original 49 bits, leading to 68 bits total.

In summary, 70 bits is enough. If you are lazy and not paranoid, 60 bits are still enough. If you think the crackers will not use more than 32 i7 CPUs for a month to try and break your password (adding 2.4 + 21.3 bits to the original 10.2 bits), 48.5 bits are still enough.

[ Posté le 13 avril 2016 à 19:20 | pas de commentaire | ]

Dimanche, 13 mars 2016

Galettes de Sarrassin

Catégories : [ Cuisine ]

Ingrédients

  • 150g farine de sarrassin
  • 20g farine de froment
  • 1 pincée de sel
  • 1 oeuf
  • 250 mL lait
  • 200 mL cidre

Préparation

Mélanger les farines et de sel. Y ajouter l'oeuf et mélanger pour absorber une partie de la farine et obtenir une pâte épaisse. Délayer progressivement avec le lait, puis avec le cidre. Laisser reposer 1 à 2 heures. Faire cuire chaque galette dans une poële très chaude et huilée.

[ Posté le 13 mars 2016 à 20:27 | pas de commentaire | ]

Samedi, 12 mars 2016

Nouveau serveur

Catégories : [ Informatique ]

Le blog (et le reste de mes pages Web) a déménagé sur un nouveau serveur (une machine virtuelle hébergée chez shellit.org. Après longue réflexion et tergiversations, et afin de continuer la série des machines dont le nom se termine en « kone », j'ai décidé de l'appeler « lentokone », koska se on kone joka on pilvissä.

J'en ai profité pour recommencer à jouer les administrateurs système et j'ai installé des serveurs DNS, SMTP, IMAP, HTTP pour gérer mon domaine moi-même.

[ Posté le 12 mars 2016 à 15:30 | pas de commentaire | ]

Dimanche, 17 janvier 2016

Vue du bureau

Catégories : [ Râleries ]

Il faisait beau vendredi, alors j'ai pris des photos depuis les fenêtres du bureau.

Vue_du_bureau_201601_1 Coté lac.

Vue_du_bureau_201601_2 Coté lac aussi. On peut voir la piste de patin à glace sur le lac.

Vue_du_bureau_201601_3 Coté gare.

[ Posté le 17 janvier 2016 à 14:10 | pas de commentaire | ]