1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
PostgreSQL Automatic Mirror Management
--------------------------------------
Concepts
--------
The automatic mirror systems works like this, in a few short points:
* All mirrors are managed in the zone "mirrors.postgresql.org".
The actual records (e.g. www.postgresql.org) are just CNAMEs pointing
to this zone.
* This zone has a TTL of 10-15 minutes max, to make sure we get a
fairly fast failover while still maintaining cache effects
* This zone is served by several nameservers located on different providers
(just as the main zone)
* On a machine that *must not* be one of the web- or DNS servers, a script
runs every 5 minutes (at least) to verify the currentness of the different
mirrors. This machine should also *not* be on the same network as a static
mirror.
* This script connects to the master server and fetches /web_sync_timestamp. If
it cannot do this (master is down) it will send an error message and skip
any further processing. This means that if the master goes down, we no longer
update the other servers. In the future, we might want to keep scanning
for servers that are down, but skip checking the actual timestamp.
* After this, it connects in sequence to each listed web server, and fetches
/web_sync_timestamp. If this fails, or if web_sync_timestamp is too far off from
the master servers, the server will be disabled (in the database). Likewise,
if the server was down and is now current, it will be re-enabled.
* A very simple flap detection algorithm is run after all servers have been
scanned. If a server has changed state too many times in a specified interval,
the server is listed as flapping. In this case, it will not be included in the
zone and it will be automatically re-enabled aafter 24 hours.
* If any data has changed due to this, the zone is reloaded in the nameserver,
and propagates to all the clients based on DNS NOTIFY messages.
* If the zone has not been updated in 24 hours, the zone will be reloaded anyway.
This is done to make it possible to monitor the DNS servers themselves for
update issues.
* The zone serial number is the unix timestamp (seconds since epoch) at the time
the zone is built.
* There is a perlscript to check that the DNS zones are updated. This shuold not
run on the same machine as the checker script. This script is not currently
made for running automated, but that should be easy to fix.
Requirements
------------
* A sqlite database called mirror.db.
* PHP is used to run the queries. Naturally, it needs to be compiled with
sqlite support.
* The zones are generated in BIND format. It's been tested with BIND 9.3.
* Perl is used by the DNS checking script. It uses the Net::DNS CPAN module.
* Sendmail (or a replacement) must be working on the box for the script to
send it's reports out.
* Scripts are configged by variables as the top. No big surprise there.
|
