Hello... I've been following the recent IPv6 threads with interest. I decided to test the M in LAMP for IPv6 support (Although it was really a FreeBSD server not Linux). It seems than only newer versions (5.5 rc) of MySQL support IPv6 network connections. Worse is that although it will accept a network connection via IPv6, the grant tables do not work. To successfully get data out of the database, the grants would have to be open to the world. After a few google searches, it seems that PostgreSQL is in a similar situation. Network operations content: Will "We're running MySQL and Postgress servers that do not support IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or hosting providers? Have any hosting providers network people talked the the DBA people to tell them that they might have a problem soon? With RedHat, CentOS, Ubuntu all shipping databases that will not work correctly with IPv6, I suspect some people are in for a rude awakening next year. Furthermore, why would Oracle want to 'fix' MySQL? It seems to me that for medium to large content providers IPv6 would be great. Have racks and racks of LAMP servers on IPv6, only a few hosts and load balancers would need to be dual stack. But if the database servers must be IPv4 only, then there is zero benefit to add IPv6 anywhere else. note: by LAMP I really mean Linux/FreeBSD/Solaris , Apache/nginx/etc, MySQL/PostgressSQL/etc, and php/perl/python/ruby. And thanks to the FreeBSD people for making 6to4 so easy to setup for initial IPv6 testing. -- Christopher McCrory To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be.
On Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote:
Network operations content:
Will "We're running MySQL and Postgress servers that do not support IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or hosting providers?
First, it's not like the flag day is tomorrow. And then, I think if you're running SQL over the public Internet, you have bigger problems than whether or not you're going to be able to get v4 addressing and transit. --msa
On 10/21/10 2:00 PM, Majdi S. Abbas wrote:
On Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote:
Network operations content:
Will "We're running MySQL and Postgress servers that do not support IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or hosting providers?
First, it's not like the flag day is tomorrow.
And then, I think if you're running SQL over the public Internet, you have bigger problems than whether or not you're going to be able to get v4 addressing and transit.
patches were available to do it as early as 2005 the work to do it in and official way was done back in 2008 leading up to the death of mysql6, it was in 5.5beta...
--msa
On 10/21/2010 3:53 PM, Christopher McCrory wrote:
Network operations content:
Will "We're running MySQL and Postgress servers that do not support IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or hosting providers?
Why not have v4 and v6? There's never a reason to reject v6, only the possible need for v4. That being said, MySQL and Postgres often reside close enough to the node that needs them that they should have v4 connectivity (or run v4 over v6 ipsec tunnels).
Have any hosting providers network people talked the the DBA people to tell them that they might have a problem soon?
Many hosting providers have db on the same server as the web server until they reach a certain size, in which case it is on a private network behind the content servers and not visible from global routing anyways.
With RedHat, CentOS, Ubuntu all shipping databases that will not work correctly with IPv6, I suspect some people are in for a rude awakening next year. Furthermore, why would Oracle want to 'fix' MySQL?
It seems to me that for medium to large content providers IPv6 would be great. Have racks and racks of LAMP servers on IPv6, only a few hosts and load balancers would need to be dual stack. But if the database servers must be IPv4 only, then there is zero benefit to add IPv6 anywhere else. Only need v4 on the private network behind the content hosts. Even geographically distributed applications don't normally make calls across
I doubt anyone will notice that matters. public net directly to a database. If the database itself isn't distributed, one might consider using vpn's to interconnect the sites, but I believe that is a rarity. Perhaps someone with a larger deployment can enlighten us. Jack
In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote:
open to the world. After a few google searches, it seems that PostgreSQL is in a similar situation.
I don't know when PostgreSQL first supported IPv6, but it works just fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres 8.4 port with no changes, and viola: postgresql# netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 localhost.postgresql *.* LISTEN tcp6 0 0 localhost.postgresql *.* LISTEN $ psql -h ::1 psql (8.4.4) Type "help" for help. pgsql=# \l List of databases Name | Owner | Encoding | Collation | Ctype | Access privileges -----------+-------+----------+-----------+-------+------------------- pgsql | pgsql | UTF8 | C | C | postgres | pgsql | UTF8 | C | C | template0 | pgsql | UTF8 | C | C | =c/pgsql : pgsql=CTc/pgsql template1 | pgsql | UTF8 | C | C | =c/pgsql : pgsql=CTc/pgsql (4 rows) ~pgsql/data/pg_hba.conf contains: # CIDR-ADDRESS specifies the set of hosts the record matches. # It is made up of an IP address and a CIDR mask that is an integer # (between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that specifies # the number of significant bits in the mask. Alternatively, you can write # an IP address and netmask in separate columns to specify the set of hosts. And later: # "local" is for Unix domain socket connections only local all all trust # IPv4 local connections: host all all 127.0.0.1/32 trust # IPv6 local connections: host all all ::1/128 trust So of your "LAMP" stack, I'm pretty sure all the L's are in good shape (Linux/FreeBSD/NetBSD/etc), the A is in good shape, been working fine for years. Perhaps the M needs some work on the MySQL side, but I'm fairly sure PostgreSQL is solid. I'm not exactly sure how the P would need IPv6 support, but I think it's generally a non-issue there other than updating software that acutally stores IPv4 addresses... -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 21/10/10 14:43 -0700, Leo Bicknell wrote:
In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote:
open to the world. After a few google searches, it seems that PostgreSQL is in a similar situation.
I don't know when PostgreSQL first supported IPv6, but it works just fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres 8.4 port with no changes, and viola:
All this is pretty moot point if you run a localized copy of your database (mysql or postgres) and connect via unix domains sockets. -- Dan White
On Thu, Oct 21, 2010 at 4:53 PM, Dan White <dwhite@olp.net> wrote:
On 21/10/10 14:43 -0700, Leo Bicknell wrote:
In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote:
open to the world. After a few google searches, it seems that PostgreSQL is in a similar situation.
I don't know when PostgreSQL first supported IPv6, but it works just fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres 8.4 port with no changes, and viola:
All this is pretty moot point if you run a localized copy of your database (mysql or postgres) and connect via unix domains sockets.
True. It mostly affects shared/smaller hosting providers who have customers that want direct access to the database remotely over the public network (and don't want to use some local admin tool such as phpMyAdmin). -brandon -- Brandon Galbraith US Voice: 630.492.0464
On 10/21/10 2:59 PM, Brandon Galbraith wrote:
On Thu, Oct 21, 2010 at 4:53 PM, Dan White <dwhite@olp.net> wrote:
On 21/10/10 14:43 -0700, Leo Bicknell wrote:
In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote:
open to the world. After a few google searches, it seems that PostgreSQL is in a similar situation.
I don't know when PostgreSQL first supported IPv6, but it works just fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres 8.4 port with no changes, and viola:
All this is pretty moot point if you run a localized copy of your database (mysql or postgres) and connect via unix domains sockets.
True. It mostly affects shared/smaller hosting providers who have customers that want direct access to the database remotely over the public network (and don't want to use some local admin tool such as phpMyAdmin).
linux/unix machines can trivially build ip-tunnels of several flavors.
-brandon
IMHO you should never, ever make your MySQL accesible over the public Internet, which renders the issue of MySQL not supporting IPv6 correctly mostly irrelevant. You could even run your MySQL behind your web backend using RFC1918 space (something I do recommend). Moreover, if you need direct access to the engine, you can trivially create an SSH tunnel (You can even do this in a point-and-click way using the latest MySQL Workbench). SSH works over IPv6 just fine. And for the LAMP stack, as long as the "A" fully supports IPv6 (which it does), we are fine. Warm regards, Carlos On Thu, Oct 21, 2010 at 8:06 PM, Joel Jaeggli <joelja@bogus.com> wrote:
On 10/21/10 2:59 PM, Brandon Galbraith wrote:
On Thu, Oct 21, 2010 at 4:53 PM, Dan White <dwhite@olp.net> wrote:
On 21/10/10 14:43 -0700, Leo Bicknell wrote:
In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote:
open to the world. After a few google searches, it seems that PostgreSQL is in a similar situation.
I don't know when PostgreSQL first supported IPv6, but it works just fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres 8.4 port with no changes, and viola:
All this is pretty moot point if you run a localized copy of your database (mysql or postgres) and connect via unix domains sockets.
True. It mostly affects shared/smaller hosting providers who have customers that want direct access to the database remotely over the public network (and don't want to use some local admin tool such as phpMyAdmin).
linux/unix machines can trivially build ip-tunnels of several flavors.
-brandon
-- -- ========================= Carlos M. Martinez-Cagnazzo http://cagnazzo.name =========================
Public or not, if someone wants to run IPv6 only, they shouldn't have to have the v4 stack just for the database. Databases must work on the v6 stack. On 10/22/2010 10:02 AM, Carlos Martinez-Cagnazzo wrote:
IMHO you should never, ever make your MySQL accesible over the public Internet, which renders the issue of MySQL not supporting IPv6 correctly mostly irrelevant. You could even run your MySQL behind your web backend using RFC1918 space (something I do recommend).
Moreover, if you need direct access to the engine, you can trivially create an SSH tunnel (You can even do this in a point-and-click way using the latest MySQL Workbench). SSH works over IPv6 just fine.
And for the LAMP stack, as long as the "A" fully supports IPv6 (which it does), we are fine.
Warm regards,
Carlos
On Thu, Oct 21, 2010 at 8:06 PM, Joel Jaeggli<joelja@bogus.com> wrote:
On Thu, Oct 21, 2010 at 4:53 PM, Dan White<dwhite@olp.net> wrote:
On 21/10/10 14:43 -0700, Leo Bicknell wrote:
In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote:
open to the world. After a few google searches, it seems that PostgreSQL is in a similar situation.
I don't know when PostgreSQL first supported IPv6, but it works just fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres 8.4 port with no changes, and viola:
All this is pretty moot point if you run a localized copy of your database (mysql or postgres) and connect via unix domains sockets.
True. It mostly affects shared/smaller hosting providers who have customers that want direct access to the database remotely over the public network (and don't want to use some local admin tool such as phpMyAdmin).
On 10/21/10 2:59 PM, Brandon Galbraith wrote: linux/unix machines can trivially build ip-tunnels of several flavors.
-brandon
-- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
On Fri, Oct 22, 2010 at 11:32 AM, Scott Reed <sreed@nwwnet.net> wrote:
Public or not, if someone wants to run IPv6 only, they shouldn't have to have the v4 stack just for the database. Databases must work on the v6 stack.
amen. so isn't that a dba issue and not a netop issue? I subscribe to postgresql-* lists for my dba fill (:
participants (10)
-
Aaron Glenn -
Brandon Galbraith -
Carlos Martinez-Cagnazzo -
Christopher McCrory -
Dan White -
Jack Bates -
Joel Jaeggli -
Leo Bicknell -
Majdi S. Abbas -
Scott Reed