Bug#707761: pdns-backend-pgsql: IP fields too short for master/slave operation over IPv6

2013-10-16 Thread James Cloos
 PD == Peter van Dijk peter.van.d...@netherlabs.nl writes:

JC The ip column should not be varchar or text.
JC It should be inet.

PD We are happy to consider this change upstream

Pull request sent.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6


signature.asc
Description: PGP signature


Bug#707761: pdns-backend-pgsql: IP fields too short for master/slave operation over IPv6

2013-10-11 Thread Peter van Dijk
Hello James,

On May 30, 2013, at 17:00 , James Cloos wrote:

 The ip column should not be varchar or text.
 
 It should be inet.
 
 The proper fix is:
 
  alter table supermasters alter COLUMN ip type inet using ip::inet;
 
 and change the sql which creates the table during install to use inet
 for that column.
 
 That column is only supposed to hold ipv4 or ipv6 addresses, which is
 exactly what the inet type is for.
 
 As an added bonus, inet stores the address as an integer, so it should
 take up less space than a text/varchar/char column.


We are happy to consider this change upstream - please file your request at 
https://github.com/PowerDNS/pdns/issues

Kind regards,
-- 
Peter van Dijk
Netherlabs Computer Consulting BV - http://www.netherlabs.nl/



signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#707761: pdns-backend-pgsql: IP fields too short for master/slave operation over IPv6

2013-10-02 Thread Marc Haber

On Thu, May 30, 2013 at 11:00:54AM -0400, James Cloos wrote:
 The proper fix is:
 
   alter table supermasters alter COLUMN ip type inet using ip::inet;
 
 and change the sql which creates the table during install to use inet
 for that column.

Can pdns handle that table format?

 As an added bonus, inet stores the address as an integer, so it should
 take up less space than a text/varchar/char column.

The supermasters table will hold only a couple of entries in an
average installation.

Greetings
Marc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#707761:

2013-10-02 Thread Marc Haber
tags #707761 help
thanks

On Wed, Jun 05, 2013 at 12:25:53PM +0200, Philipp Dreimann wrote:
 It seems like all sql backends have weird configurations: See
 https://github.com/dphi/pdns-debian/commit/80405812a940b62882537bb9859f722934b73674
 for a suggestion on how to fix the inital table creation, which would
 be a first step!
 
 (I did not have a look at how updates to existing tables can be integrated.)

Ok. I need help to fix that issue. Most helpful would be somebody
experienced with dbconfig-common and PostgreSQL. I know my way around
MySQL and a bit around sqlite, but PostgreSQL is fully not my world.

Greetings
Marc


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#707761: pdns-backend-pgsql: IP fields too short for master/slave operation over IPv6

2013-10-02 Thread James Cloos
 MH == Marc Haber mh+debian-packa...@zugschlus.de writes:

 alter table supermasters alter COLUMN ip type inet using ip::inet;

 and change the sql which creates the table during install to use inet
 for that column.

MH Can pdns handle that table format?

It is transparent to pdns.  I've been using it in production since
before I posted that.

Were pdns to try to store something in that column which wasn't an ip
address, pg would complain and the transaction would fail.

But pdns only reads that table, and the text returned from a SELECT on
an inet column looks like the normal text notation of an ipv4 or ipv6
address.

Were someone to store a cidr (such as 10.1.2.4/8) then pdns would
complain; but again the result would be no different than if one
were to store such data in a text or varchar field.

The column needs to be either text, varchar(39) or larger, or inet
to support all possible ipv4 and ipv6 addresses.  Inet has the benefit
of documenting the column's intent and rejecting most bogus data before
it can confuse or break pdns.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#707761:

2013-06-05 Thread Philipp Dreimann
It seems like all sql backends have weird configurations: See
https://github.com/dphi/pdns-debian/commit/80405812a940b62882537bb9859f722934b73674
for a suggestion on how to fix the inital table creation, which would
be a first step!

(I did not have a look at how updates to existing tables can be integrated.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#707761: pdns-backend-pgsql: IP fields too short for master/slave operation over IPv6

2013-05-30 Thread James Cloos
The ip column should not be varchar or text.

It should be inet.

The proper fix is:

  alter table supermasters alter COLUMN ip type inet using ip::inet;

and change the sql which creates the table during install to use inet
for that column.

That column is only supposed to hold ipv4 or ipv6 addresses, which is
exactly what the inet type is for.

As an added bonus, inet stores the address as an integer, so it should
take up less space than a text/varchar/char column.

-JimC
-- 
James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#707761: pdns-backend-pgsql: IP fields too short for master/slave operation over IPv6

2013-05-11 Thread Marc Haber
tags #707761 confirmed

Hi,

On Fri, May 10, 2013 at 10:11:01PM -0300, mar...@marcosdumay.com wrote:
 The PowerDNS master/slave synchronization does not work over IPv6
 because the database schema can not hold the addresses.
 
 A supermaster can not be configured, because the column supermaster.ip
 holds a maxumim of 25 characters, and the domain replication fails
 because the column domain.master holds a maximum of 20 characters.
 Increasing those limits to 39 characters, the maximum length of an
 IPv6 address, solves the problem.

this bug report is entirely reasonable. Unfortunately, the pgsql
schemes were not updated for wheezy, while they should.

A possible local fix is of course to adapt the database scheme to
whatever is suitable for the present PowerDNS version.

Are you in a position to provide a patch for this issue to fix the
package? If not, I regret that there won't be a speedy fix available
as I would need to brush up my PostgreSQL first, which I almost never
use.

Greetings
Marc

-- 
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things.Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#707761: pdns-backend-pgsql: IP fields too short for master/slave operation over IPv6

2013-05-10 Thread marcos
Package: pdns-backend-pgsql
Version: 3.1-4
Severity: normal

Dear Maintainer,

The PowerDNS master/slave synchronization does not work over IPv6 because the 
database schema can not hold the addresses.

A supermaster can not be configured, because the column supermaster.ip holds a 
maxumim of 25 characters, and the domain replication fails because the column 
domain.master holds a maximum of 20 characters. Increasing those limits to 39 
characters, the maximum length of an IPv6 address, solves the problem.


-- System Information:
Debian Release: 7.0
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.8.4-linode50 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages pdns-backend-pgsql depends on:
ii  dbconfig-common1.8.47+nmu1
ii  debconf [debconf-2.0]  1.5.49
ii  libc6  2.13-38
ii  libgcc11:4.7.2-5
ii  libpolarssl0   1.1.4-2
ii  libpq5 9.1.9-1
ii  libssl1.0.01.0.1e-2
ii  libstdc++6 4.7.2-5
ii  pdns-server3.1-4
ii  zlib1g 1:1.2.7.dfsg-13

Versions of packages pdns-backend-pgsql recommends:
ii  postgresql-client  9.1+134wheezy3
ii  postgresql-client-8.4 [postgresql-client]  8.4.17-0squeeze1
ii  postgresql-client-9.1 [postgresql-client]  9.1.9-1

Versions of packages pdns-backend-pgsql suggests:
ii  postgresql  9.1+134wheezy3

-- debconf information:
  pdns-backend-pgsql/pgsql/authmethod-admin: ident
  pdns-backend-pgsql/internal/skip-preseed: false
* pdns-backend-pgsql/dbconfig-install: true
  pdns-backend-pgsql/upgrade-error: abort
  pdns-backend-pgsql/upgrade-backup: true
  pdns-backend-pgsql/pgsql/authmethod-user: ident
  pdns-backend-pgsql/dbconfig-remove:
  pdns-backend-pgsql/db/dbname: pdns
  pdns-backend-pgsql/remote/port:
  pdns-backend-pgsql/pgsql/manualconf:
  pdns-backend-pgsql/pgsql/method: unix socket
  pdns-backend-pgsql/remote/newhost:
  pdns-backend-pgsql/remove-error: abort
  pdns-backend-pgsql/db/app-user: pdns
  pdns-backend-pgsql/missing-db-package-error: abort
  pdns-backend-pgsql/install-error: abort
  pdns-backend-pgsql/pgsql/no-empty-passwords:
  pdns-backend-pgsql/pgsql/admin-user: postgres
  pdns-backend-pgsql/remote/host:
  pdns-backend-pgsql/pgsql/changeconf: false
  pdns-backend-pgsql/database-type: pgsql
  pdns-backend-pgsql/internal/reconfiguring: false
  pdns-backend-pgsql/passwords-do-not-match:
  pdns-backend-pgsql/dbconfig-upgrade: true
  pdns-backend-pgsql/dbconfig-reinstall: false
  pdns-backend-pgsql/purge: false


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org