Re: ipv6 vs. LAMP
Hi all, the replication point is a good one, I did not think about that. However, I still believe that on the road to v6 adoption, databases are far from being our most pressing roadblock. Thanks all! Carlos On Fri, Oct 22, 2010 at 4:52 PM, Jerry B. Altzman jba...@altzman.comwrote: Only to you. on 10/22/2010 10:02 AM Carlos Martinez-Cagnazzo said the following: 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). Except for those of us who have to support applications based upon MySQL replication...in that case, we use IP-based access rules on a firewall in front, and on the host, and on the MySQL server itself. But we still need IP access to it. We could shade it all by using IPSec or VPN tunnels, but that's more administrative overhead, and MySQL replication is fragile enough without adding that. 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. See above about replication. Carlos //jbaltz -- jerry b. altzmanjba...@altzman.com www.jbaltz.com thank you for contributing to the heat death of the universe. -- -- = Carlos M. Martinez-Cagnazzo http://cagnazzo.name =
Re: ipv6 vs. LAMP
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 joe...@bogus.com wrote: On 10/21/10 2:59 PM, Brandon Galbraith wrote: On Thu, Oct 21, 2010 at 4:53 PM, Dan White dwh...@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 =
Re: ipv6 vs. LAMP
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 Jaegglijoe...@bogus.com wrote: On 10/21/10 2:59 PM, Brandon Galbraith wrote: On Thu, Oct 21, 2010 at 4:53 PM, Dan Whitedwh...@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 -- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060
ipv6 vs. LAMP
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.
Re: ipv6 vs. LAMP
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
Re: ipv6 vs. LAMP
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? I doubt anyone will notice that matters. 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 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
Re: ipv6 vs. LAMP
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: hostall all 127.0.0.1/32 trust # IPv6 local connections: hostall 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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpkAKJRRFqcB.pgp Description: PGP signature
Re: ipv6 vs. LAMP
On Thu, Oct 21, 2010 at 4:53 PM, Dan White dwh...@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
Re: ipv6 vs. LAMP
On 10/21/10 2:59 PM, Brandon Galbraith wrote: On Thu, Oct 21, 2010 at 4:53 PM, Dan White dwh...@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
