Matt Solnit's questions

Day One

I have to hide the actual host names, so I'm hoping there is still enough information to answer this question...

I'm trying to resolve a certain host name (let's pretend it's www.example.com, but this is not the actual host name). A simple dig request works, but when I try to do a series of dig starting from a root nameserver, I hit a dead-end. Here's an example:

# Starting with arbitrarily-chosen root nameserver
$ dig @198.41.0.4 www.example.com
(returns the usual list of TLD .com nameservers)

# Using a.gtld-servers.net
$ dig @192.5.6.30 www.example.com
(returns a list of 5 example.com authorities)

At this point, I tried each of the 5 example.comauthorities. Three of them fail with status SERVFAIL, and the remaining two time out. Here's a SERVFAIL example:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33577
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.example.com.       IN  A

;; Query time: 74 msec
;; SERVER: <intentionally removed>
;; WHEN: Tue Mar  8 10:10:33 2011
;; MSG SIZE  rcvd: 37

I tried this multiple times, from my own machine at home and from a remote machine in our co-lo, and both machines consistently get the same results.

However,

• As I mentioned above, dig www.example.com (without specifying an @server) works fine.
• This DNS trace utility is able to resolve the host name, and it clearly shows that it's using one of the name servers that times out for me!

Can anybody help me figure out what's going on?

EDIT 1: In case it helps, what should happen is that this host name should ultimately resolve to a CNAME record pointing to www.example.com.edgesuite.net, which should in turn resolve to another CNAME record pointing to an Akamai edge server.

EDIT 2: Per Joris's recommendation, I ran dig +trace www.example.com, and it actually failed to find a result. It gets to the same list of example.com authorities that I found before, and stops there.

Caching seems like a very likely culprit (and I did think of this earlier), but the weird part is that the actual host name isn't that popular. Would it be cached on two different ISP local nameservers if I'm the first person to request it? :-)

Day Two

OK, I've discovered a few things:

1. The two example.com authorities that I thought were timing out (as opposed to the other three, that were returning SERVFAIL) are not actually timing out. They just require a much longer timeout. If I use dig +time=10, for example, then I do eventually get back a result.
2. I've tried this from several servers around the U.S., and the story is the same -- using dig www.example.com returns a result very quickly, but dig @ns1.example.com (or @ns2.example.com) requires using a large timeout parameter.

So my new questions are:

1. Could the result really be cached on a variety of proxying DNS servers, even though it's not a commonly-used host name? The TTL is 54,000 (or 15 hours, if I understand correctly).
2. If not, then is it possible that ns1.example.com is somehow configured to return a result more quickly to proxying DNS servers than to my own dig queries (some kind of white list)? Or is that just crazy talk?

We are looking at deploying our application as a Xen image, to a hosting company that we aren't 100% sure about yet. Can they access random data on our virtual hard drive(s)?

This page says no:

About Domains

Dom0 and domU are separate entities. Other than by login, you cannot access a domU from dom0...

But I want to be really, really sure. If there are "n00b" issues that I'm not understanding, that's fine :-). Just point them out to me.

I'm dealing with a database system that can have thousands of tables. The problem is, when I try to back it up using pg_dump, I sometimes get the following error:

pg_dump: WARNING:  out of shared memory
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.
pg_dump: The command was: LOCK TABLE public.foo IN ACCESS SHARE MODE

I could of course increase the max_locks_per_transaction setting. But the problem is that the number of tables can vary. I don't want to constantly have to revisit this setting every time there is a failure (assuming we notice the failure at all, given that this is in a cron job!).

What would be the best way to tackle this problem? Currently I'm working on a Perl script that will list all the tables and then call pg_dump in "chunks" to keep a limit on the number of table locks, but I bet I could do better.

I'm migrating a CentOS 5.3 system from MySQL to PostgreSQL. The way our machine is set up is that the biggest disk partition is mounted to /home. This is out of my control and is managed by the hosting provider. Anyway, we obviously want the database files to be on /home for this reason.

With MySQL, we did the following:

• Edited my.cnf and changed the datadir setting to /home/mysql
• Added a new "File type" policy record (I hope I'm using the right terminology) to set /home/mysql(/.*)? to mysqld_db_t
• Ran restorecon -R /home/mysql to assign the labels

and everything was good.

With PostgreSQL, however, I did the following:

• Edited /etc/init.d/postgresql and changed the PGDATA and PGLOG variables to /home/pgsql/data and /home/pgsql/pgstartup.log, respectively
• Added a new policy record to set /home/pgsql/pgstartup.log to postgresql_log_t
• Added a new policy record to set /home/pgsql/data(/.*)? to postgresql_db_t
• Ran restorecon -R /home/pgsql to assign the labels

At this point, I still cannot start PostgreSQL. pgstartup.log says:

# cat pgstartup.log
postmaster cannot access the server configuration file "/home/pgsql/data/postgresql.conf": Permission denied

The weird thing is that I don't see any messages related to this in /var/log/messages or /var/log/secure, but if I turn off SElinux, then everything works.

I made sure all the permissions are correct (600 for files and 700 for directories), as well as the ownership (postgres:postgres).

Can anyone tell me what I am doing wrong?

I'm using the Yum repository from commandprompt.com, version 8.3.7.

EDIT: The reason my question specifically mentions the /home directory is that if I go through all these steps for any other directory, e.g. /var/lib/pgsql2 or /usr/local/pgsql, then it works as expected.

I've been using an Amazon EC2 image (AMI) based on Fedora Core 6 for a long time now, but I would like to update to FC8 or FC10.

The problem is, when I went through the excellent upgrade instructions at ioncannon.net and re-bundled, I ended up with an AMI that had grown from 1.9 GB to 2.4 GB. Similarly, when I tried re-building from scratch using the Amazon FC8 image (fedora-8-x86_64-base-v1.08 a.k.a. ami-2547a34c), the size was about the same.

Is there something inherently "bigger" about FC8? Did I somehow pick up some new packages that I don't need? Is there any other explanation?