Posts Tagged ‘debian’

Add missing GPG public key to Debian’s apt

Monday, June 8th, 2009

Just a quick post, because I always have to look it up: If you get a message like this while installing a new package through apt

  1. W: GPG error: http://ppa.launchpad.net intrepid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C514AF8E4BA401C3

… you can do the following to get rid of it:

  1. gpg --keyserver pgpkeys.mit.edu --recv-key C514AF8E4BA401C3
  2. gpg -a --export C514AF8E4BA401C3 | apt-key add -

Works on Ubuntu and other derivatives of Debian all the same, of course. Hope this post will safe me some time the next time I run into this.

PowerDNS on Debian Lenny, Sarge or Woody (2)

Thursday, April 23rd, 2009

This post is the second part of a workshop on the PowerDNS DNS server. In the first part of this workshop, we set up the PowerDNS server and it’s MySQL database backend. In this part of the workshop, I will show you how to add some domain data to your database and how to synchronize this data to other PowerDNS servers automatically by using the so-called supermaster concept of PowerDNS. I will also show you how to enable AXFR transfers to ensure compatibility with remote Bind slave servers.

Prerequisites

For the rest of this workshop it is assumed that you’ve got two PowerDNS installations on two separate physical hosts with the IP addresses 192.168.0.1 and 192.168.1.2, respectively. The first server has the host name dns.example.net and the second server has the host name dns2.example.net.

Configure Master and Slave

You probably want one DNS server to act as the master server and a number of additional servers to act as slaves. PowerDNS supports multiple master servers for one domain and it can be slave and master at the same time.

We will now configure dns.example.net as the master and dns2.example.net as the slave. To do this, add master to the configuration file of the first server and slave to the configuration file of the second server.

In a traditional setup, you would configure a domain name both on the master and the slave server. Additionally, you would specify record data for the domain name on the master server. The slave would then query the master server and download the record data. Whenever you change the record data on the master server, it would notify the slave server and the slave server would refresh the record data by downloading the new record data from the master server. In fact, you can do this with PowerDNS and it will work just fine. But PowerDNS can do more: If you tell your slave(s), that your master is a so-called supermaster, you do not need to setup new domain names on the slave. All you need to do is to setup the new domain name and its record data on the master server. If the domain has a SOA record and your slave is listed as one of the authoritative name servers for the domain, the master will notify your slave of the new domain name. Your slave recognizes, that your master is a supermaster server and adds the domain name to its configuration automatically. It works like magic.

To tell your slave, that your master server is a supermaster server, execute the following SQL statement on your slave’s MySQL server.

  1. INSERT INTO pdns.supermasters (`ip`, `nameserver`, `account`) VALUES ('192.168.0.1', 'dns2.example.net', 'test');

This tells your slave, that your PowerDNS server with the IP address 192.168.0.1 is a supermaster server. As you will see later, PowerDNS supports the concept of accounts. These do not have any influence on the operation of PowerDNS. You can specify account information for each domain name, which might be useful, if you want to find all domain names of a certain customer. If PowerDNS sets up a new domain name of a supermaster, it uses account information specified in the supermasters table for that supermaster server. In our case, all domains of the supermaster server dns.example.net will be added with the account information test. Note, that the nameserver column of the supermasters table is not the host name of the supermaster server. It is the host name of the slave server. Before the slave adds a new domain name from our supermaster server, it checks that the host name you specify in the the nameserver column is listed as one of the authoritative DNS servers for that domain name. Thus, we need to add the name of our slave there.

Enable AXFR

To exchange domain name and record data, your PowerDNS servers will use a method that is called AXFR. For security reasons, AXFR is disabled by default. Edit the configuration files of your PowerDNS master server:

  1. allow-axfr-ips=192.168.2.1
  2. disable-axfr=no

This will enable AXFR for the IP address of your slave server. Do not allow AXFR for any server. This would pose a security risk. If you’ve got multiple slave servers, add all the IP addresses of the slave servers separated by a comma. AXFR is compatible with other name server software (e.g. Bind).

Running PowerDNS

PowerDNS should be in a state now, where it can start and connect to the MySQL database with no problems. For now, we will start PowerDNS in monitoring mode. That way we can follow everything that happens live on the console. To start up PowerDNS in monitoring mode, use the following command.

  1. /etc/init.d/pdns monitor

Later, you may want to run PowerDNS in the background. To do this just run the following command.

  1. /etc/init.d/pdns start

Once you have started up both the master and the slave PowerDNS server we can start adding domain names.

Adding your first domain name

To add a new domain name, you need to add a new entry to the domains table of your database. To do so, execute the following SQL query on the master server:

  1. INSERT INTO `pdns.domains` (`id`, `name`, `type`, `account`) VALUES (1, 'example.com', 'MASTER', 'test');

This will add the example.com domain name to the database. The type MASTER indicates, that our master server will be the master for this domain. The account name is optional, it is for your information only. It is important to note, that the id of our new domain name is 1. We’ll need this in a second.

Next, we need to add some records, i.e. some zone data, to the database for PowerDNS to serve. The records need to be added to the records table of the database. PowerDNS supports a number of different records. Depending on the type of the record, you need to provide different values for the type, content and prio columns. Check the PowerDNS documentation on supported record types and their storage to get an idea of what you need. For your convenience, I’ll give you a few examples of common record types.

The first thing you want to add is a SOA record. A typical SOA record would look like this:

  1. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, 'example.com','SOA', 'dns.example.net. hostmaster.example.net. 2009042301 10800 3600 604800 3600', 3600);

Note the domain_id, which is set to the id value of our example.com domain. Then there is the fully qualified domain name, that this record is valid for. You are probably familiar with the values of the type, content and ttl columns. If not, check the documentation.

Next, let’s add a few name servers. It is important that your master and all your slaves are listed here, of course.

  1. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, 'example.com','NS', 'dns.example.net', 3600);
  2. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, 'example.com','NS', 'dns2.example.net', 3600);

You probably want some A records:

  1. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, 'example.com','A', '192.168.0.3', 3600);
  2. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, 'sales.example.com','A', '192.168.0.4', 3600);
  3. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`) VALUES (1, '*.example.com','A', '192.168.0.2', 3600);

The first of these records is for the example.com domain name. The second is for a subdomain, i.e. sales.example.com. The third A record is special. It is a wildcard record. It matches any subdomain, that is not already specified, i.e. everything except example.com and sales.example.com.

Let’s finish by adding some MX records:

  1. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`, `prio`) VALUES (1, 'example.com', 'MX','mail.example.net', 3600, 10);
  2. INSERT INTO `pdns.records` (`domain_id`, `name`, `type`, `content`, `ttl`, `prio`) VALUES (1, 'example.com', 'MX','mailbackup.example.net', 3600, 20);

Within a short time you will see the following information showing up in the log file of your slave server. Don’t be impatient, it takes some time. You should see something within a minute, though.

  1. Feb 07 21:43:26 Received NOTIFY for example.com from 192.168.0.1 for which we are not authoritative
  2. Feb 07 21:43:26 Created new slave zone 'example.com' from supermaster 192.168.0.1, queued axfr
  3. Feb 07 21:43:27 gmysql Connection succesful
  4. Feb 07 21:43:27 No serial for 'example.com' found - zone is missing?
  5. Feb 07 21:43:27 AXFR started for 'example.com', transaction started
  6. Feb 07 21:43:27 AXFR done for 'example.com', zone committed

And the equivalent on the master server:

  1. Feb 7 21:43:20 1 domain for which we are master needs notifications
  2. Feb 7 21:43:20 Queued notification of domain 'example.com' to 192.168.1.2
  3. Feb 7 21:43:21 AXFR of domain 'example.com' initiated by 192.168.1.2
  4. Feb 7 21:43:21 Removed from notification list: 'example.com' to 192.168.1.2 (was acknowledged)
  5. Feb 7 21:43:21 gmysql Connection succesful
  6. Feb 7 21:43:21 AXFR of domain ‘example.com’ to 192.168.1.2 finished
  7. Feb 7 21:43:23 No master domains need notifications

This looks like a successful AXFR of the example.com domain name. Let’s see, if the domain was really added to the MySQL database on the slave server:

  1. mysql> SELECT * FROM pdns.domains WHERE name='example.com';
  2. +----+--------------+---------------+------------+-------+-----------------+---------+
  3. | id | name | master | last_check | type | notified_serial | account |
  4. +----+--------------+---------------+------------+-------+-----------------+---------+
  5. | 1 | example.com | 192.168.0.2 | 1234039407 | SLAVE | NULL | test |
  6. +----+--------------+---------------+------------+-------+-----------------+---------+
  7. 1 row in set (0.00 sec)

Quite cool, isn’t it? You can also query the records table. All your records will be there. Every time you add a new record and raise the serial number, PowerDNS will notify your slave and the record data will be updated automatically.

Adding slave domains

Sometimes, you might want to add a slave domain to one of your servers manually. Suppose your master server acts as a slave server for the domain example.org. Say, the master server of the example.org domain is a remote Bind server with the IP address 192.168.2.34. First, make sure that AXFR with that server is allowed (see above). Then, execute the following SQL query on your server.

  1. INSERT INTO `pdns.domains` (`id`, `name`, `master`, `type`, `account`) VALUES (2, 'example.org', '192.168.2.34', 'SLAVE', 'test');

VoilĂ . That’s it. PowerDNS will take care of the rest.

Limitations of the supermaster mode

Unfortunately, supermaster mode is not equivalent to database synchronization. Automatic set up of new domain names and record data works like a charm. What doesn’t work, though, is the automatic deletion of domain names. If you delete your domain name on the master server, you need to delete it on all slaves manually.

Remove pages from PDF files on Linux

Sunday, December 24th, 2006

Today I needed to remove some pages from a bunch of PDF files. In search of a tool, I came across the article Manipulating PDFs with the PDF Toolkit. To cut out pages 10-25 from a PDF type:

  1. pdftk old.pdf cat 1-9 26-end output new.pdf

If you don’t have it already, you need to install the Ubuntu/Debian package pdftk first.

In related news: It’s Christmas. So merry Christmas to everyone. I will be quite busy between the years (a translation of zwischen den Jahren, an expression used in Germany to describe the time between Christmas and the first day of the new year). I will participate in a bunch of Christmas-related events today and tomorrow and will be at the 23rd Chaos Comminication Congress in Berlin from December 26. See you there!

PowerDNS on Debian Lenny, Sarge or Woody (1) [Update3]

Saturday, June 4th, 2005

PowerDNS is an extremly powerful DNS server. It supports a number of relational database backends, loadbalancing and failover algorithms.

Deploying PowerDNS on all our servers has a few major advantages over our current Bind based setup.

  • PowerDNS has native MySQL database backend support and is therefore easier to integrate with our customer control panel. Also changes to the MySQL database are discovered automatically, eliminating the need for periodical restarts. All changes are applied almost instantly.
  • PowerDNS can act as a so-called supermaster, synchronizing itsself automatically with slave servers. Zone transfers occur even without adding a domain name to all of the slaves beforehand. It is enough if the domain is added to the database of the master server.

I will now describe how to setup PowerDNS on a Linux box running Debian Woody or Debian Sarge or Debian Lenny and utilizing the MySQL database backend.

Initial Setup

Official Debian packages for PowerDNS are availlable since Debian Sarge, but you can download Woody packages from http://www.powerdns.com/downloads/, if you use Woody. There is no apt repository availlable, however.

After downloading the most recent package with wget, you can install it on your system with dpkg.

  1. wget http://downloads.powerdns.com/releases/deb/stable/pdns-static_2.9.17-1_i386.deb
  2. dpkg -i pdns-static_2.9.17-1*

If you’ve got a Sarge or newer installation of Debian just run apt-get as follows and the necessary packages will be installed automatically.

  1. apt-get install pdns-recursor pdns-backend-mysql

You’ll notice that PowerDNS will not start up directly after installing the package. That’s because the standard configuration file does not come preconfigured for a specific backend; we have to configure PowerDNS for a backend of our choice first. See below for a sample output of a fresh PowerDNS installation.

  1. /etc/init.d/pdns monitor
  2. Jun 04 10:13:56 Unable to launch, no backends configured for querying.

Gerneal Settings

Before we will begin to configure the database backend, we’ll have a look at some basic settings first. If you use Sarge, you can skip this part. You will be asked for the information below during configuration of the package. If you use Lenny or Woody, you need to specify an IP address and a port, to which PowerDNS should bind. You should specify an alternate port for non-production use. That allows you to run PowerDNS in parallel to an existing nameserver installation during the initial setup period.

On Woddy and Sarge, edit /etc/powerdns/pdns.conf directly. In Lenny, do edit the file /etc/powerdns/pdns.d/pdns.local file instead. This way it will be easier to update the package later.

  1. vi /etc/powerdns/pdns.d/pdns.local
  2. local-address=192.168.0.2
  3. local-port=5300

If you want to bind PowerDNS to multiple IP addresses change the local-address setting as follows.

  1. local-address=192.168.0.2,192.168.0.3

If your server has multiple IP addresses configured, you should also set the IP address, which PowerDNS will use as the source address when sending out answers to queries from clients or remote servers.

  1. query-local-address=192.168.0.2

MySQL

Before we start to configure PowerDNS to use the MySQL backend, we need to setup the required database and tables.

  1. CREATE DATABASE pdns;
  2. USE pdns;
  3. CREATE TABLE domains (
  4. id INT auto_increment,
  5. name VARCHAR(255) NOT NULL,
  6. master VARCHAR(20) DEFAULT NULL,
  7. last_check INT DEFAULT NULL,
  8. type VARCHAR(6) NOT NULL,
  9. notified_serial INT DEFAULT NULL,
  10. account VARCHAR(40) DEFAULT NULL,
  11. primary key (id)
  12. )type=InnoDB;
  13. CREATE UNIQUE INDEX name_index ON domains(name);
  14. CREATE TABLE records (
  15. id INT auto_increment,
  16. domain_id INT DEFAULT NULL,
  17. name VARCHAR(255) DEFAULT NULL,
  18. type VARCHAR(6) DEFAULT NULL,
  19. content VARCHAR(255) DEFAULT NULL,
  20. ttl INT DEFAULT NULL,
  21. prio INT DEFAULT NULL,
  22. change_date INT DEFAULT NULL,
  23. primary key(id)
  24. )type=InnoDB;
  25. CREATE INDEX rec_name_index ON records(name);
  26. CREATE INDEX nametype_index ON records(name,type);
  27. CREATE INDEX domain_id ON records(domain_id);
  28. CREATE TABLE supermasters (
  29. ip VARCHAR(25) NOT NULL,
  30. nameserver VARCHAR(255) NOT NULL,
  31. account VARCHAR(40) DEFAULT NULL
  32. );

We also have to create a new MySQL user account exclusively for PowerDNS and need to set the rights accordingly.

  1. GRANT USAGE ON *.* TO `pdns`@localhost IDENTIFIED BY "********"
  2. WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0
  3. MAX_UPDATES_PER_HOUR 0;
  4. GRANT ALL PRIVILEGES ON `pdns`.`domains` TO `pdns`@localhost;
  5. GRANT ALL PRIVILEGES ON `pdns`.`records` TO `pdns`@localhost;
  6. GRANT SELECT ON `pdns`.`supermasters`
  7. TO `pdns`@localhost;

The neccessary database is now setup and the empty tables await our data. Because PowerDNS is unable to connect using sockets, we have to modify the MySQL configuration and make it bind itsself to localhost.

  1. vi /etc/mysql/my.cnf
  2. #skip-networking
  3. bind-address = 127.0.0.1

All we need to do now is to make another change to the PowerDNS configuration.

  1. vi /etc/powerdns/pdns.d/pdns.local
  2. launch=gmysql
  3. gmysql-host=127.0.0.1
  4. gmysql-user=pdns
  5. gmysql-password=********
  6. gmysql-dbname=pdns

Let's have a little test of the installation.

  1. /etc/init.d/pdns monitor
  2. Jun 04 16:46:34 gmysql Connection successful

Perfect. PowerDNS is setup successfully. The initial setup is completed. See you later for part two of this workshop, in which we will insert some random domain data into our new database and setup a typical superserver/slave framework.

Update1: Recently Debian 3.1 Sarge was released. I changed this tutorial a bit to accommodate some differences between Woody and Sarge.

Update2: Actually, PowerDNS is perfectly able to use MySQL sockets, if you omit the gmysql-host option. Lesson learned. Post changed.

Update3: Debian Lenny will be released shortly. I changed this tutorial a bit to accommodate some differences between Woody, Sarge and Lenny.