db can't resolve www

[jonesy]

Hi,

I need to configure my web application to talk to the database - which means GRANTing privileges to 'someuser@webserver' to the requisite database. However, my database cannot resolve my web server, in spite of my web server being connected to the database (from a 'db' terminal on my db to the 'in' terminal on the db server).

I noticed the same issue with my (testing) application server. Is there some reason these machines can't resolve the web server, but the web server can resolve any of these hosts? All name resolution thus far has been set up automatically without any manual config on my part, so it seems like this is something that *should* just work.

Clues?

[JeremySuo]

If you are using the default MySQL template the root user for mysql is blank and you can connect from the command line of the 'www' appliance via ssh. First connect to the 'www' appliance shell. Try and 'ping' the db host.

# ping db

Should reply back with a 10.x.x.x address.

Example

# mysql -u root -p -h db
<Press enter for blank password>

Then you can grant the user access you need

mysql> GRANT ALL PRIVILEGES ON foo.* TO 'someone'@'10.%' IDENTIFIED BY 'somepassword';
mysql > FLUSH PRIVILEGES;

Exit mysql and then try and connect from that host via mysql on the 'www' host.

# mysql -u someone -p -h db
< enter the password you created above >

From there you should be able to access the DB using the newly create GRANT.

Thanks,

Jeremy

[jonesy]

I understand that I can do that, but I don't consider it a solution, and it doesn't answer the questions of how this is *supposed* to work and why it isn't working in the way one would expect given that everything else seems to resolve perfectly with no manual configuration from me.

Further, I was told that IP addresses can change, especially if you change packages, so putting an IP address in there, besides being kind of a bad idea in general, is especially bad here.

The real question isn't "how do I deal with non-resolving hosts?". The question is "Why are these hosts not resolving automatically, and how do I get them to resolve properly automatically, like the hosts in the rest of the app do?"

Thanks much for your input.
brian

[PeterNic]

Brian,

Considering that you can connect any number of web servers and other appliances (e.g., app servers), there is no one-to-one relationship to resolve the "webserver" host. While it would have been possible to allow appliances to resolve each other's name, it will defeat the purpose of having terminals as endpoints.

In AppLogic, the only direction of binding is from an output to an input -- i.e., in the LAMP case, from the web server to the database server. You will notice that the web server refers to the database server through the name 'db', which is the name of the web server's output terminal, not the instance name of the database server appliance.

Just an aside, this is a feature that enables the use of appliance classes and visual connections. Imagine having two web servers, W1 and W2; and two database servers D1 and D2. Because W1 and W2 access "the" database via the name db, rather than by the host name D1 or D2, you can connect and re-connect W1/W2 to D1/D2 in any way you want. For example, you can connect W1 to D1 and W2 to D2; each web server will access the corresponding database; if you then break the connection between W2 and D2, and connect W2 to D1, then both web servers will see D1 as the database, without ANY changes to either appliance.

More of the model is described in the AppLogic application model section of the concepts in the docs.

To get to the specific issue -- if you allow someuser@"%" to access the database server, it should be OK. Why? Because AppLogic allows traffic only between appliances that are explicitly connected -- i.e., you will be able to access the database server only from the instance of the web server that is connected to it (as well as from any other appliance connected to the in terminal of MySQL). In fact, you can verify this yourself -- (1) find out the IP address of the 'in' terminal of the MySQL appliance, (2) log in the web server, try to talk to the database by this IP address, should work, (3) log in the IN gateway, try to talk to the database by the same IP address, should fail; (4) log into the web server of another application, try to access the database by the same IP address, should fail. AppLogic creates something very close to VLAN for each connected set of terminals and allows traffic only between terminals that are connected.

Let me know if this clears up the issue.

Regards,
-- Peter

[jonesy]

Perfect. Thanks PeterNic - all's clear now. This is something of a departure from traditional administration, and is the first instance I've personally seen where the virtualization details actually affect userland app configuration.

Thanks.
brian.

[PeterNic]

Brian,

You are right -- the application model is beginning to affect "best practices". I am probably going to start a blog or a discussion on this sometime soon. Many of the assumptions of traditional servers -- firewalls, multiple users, complex binding -- are moot points in applications that are engineered from appliances rather than servers.

Another example is memory pool configurations -- if you use MySQL or PostGRE server, you can configure explicitly the max. amount of memory those can consume. The main goal in traditional servers is to leave enough memory for the server's other functions (e.g., web server). This is best practice and it is awfully fragile and qualified labor intensive (what if you reduce the server's physical memory?). In the appliance-based model, if you use the "one appliance - one function" principle, this becomes moot -- ALL of the appliance's memory is available to the database server, so the appliance can autosize the memory pools based on (a) the amount of memory the appliance has and (b) some heuristic based on the intended use (e.g., OLTP vs. analytics, etc.). We found a great article on heuristics for PostGRE and have used that in a prototype appliance. We'll see how it works out -- configuring a database server for optimum performance will no longer be black magic and mere mortals will be able to do it (as well as those mortals who have other things they need to get done and can now concentrate on those).

There are a lot of interesting and, in some cases, I am sure controversial departures from the old-style best practices due to the appliance-based model. In all cases, the result is simplification as a benefit of a removed human effort. In some cases, we need to (a) add more explanations and highlight the differences and (b) complete the support for the alternate best practice. I hope for more user feedback on those.

Regards,
-- Peter