Gavin Miller's questions

I'm in the process of configuring a cloud server to run the following stack: Ruby, Passenger, Apache; under Ubuntu 10.04 (Lucid Lynx).

In the process of wanting to make the server easier to manage I setup RSA keys on root, and www-data so that I can ssh into the server. The thing I didn't like was that www-data's .ssh directory sat in /var/www which is the default directory setup for apache. My worry is that if apache isn't configured properly then the .ssh directory can be exposed.

I came across the solution to move the ~/.ssh/authorized_keys file into a central location by changing AuthorizedKeysFile in /etc/ssh/sshd_config. This comes with 2 pros: A single location for keys, and not having to worry about a bad apache configuration. The single con that I can think of is that now every user is available for login on the server (clearly a double edged sword of the central key file.)

Is there anything that I've missed in this configuration? Have I over exposed myself, or is this a better solution than individual authorized_keys files?

I'm green when it comes to server management, but am totally ready to be called bad names for doing bad things. :D

I'm looking to setup a user account in Sql Server 2000 in the most secure manner. The criteria is as follows:

• No access to the master database (db_denydatareader & db_denydatawriter on master)
• DB Read Permission (db_datareader)
• DB Write Permission (db_datawriter)
• DB Execute Permission for sprocs (???)

To me this seems like a pretty straight forward setup and that it ought to be a standard scheme. Running through a couple articles show that it isn't and that granting sproc execute permissions is less than easy.

Is there an easier way to grant sproc execute permission? Is there a catch all scheme that provides secure database access? Am I tracking on the right path?

So here's the situation. An email was sent from a computer within our organization yesterday and we were subsequently marked as spam because of it. We don't know who sent it. We don't know when it was sent (but have an approximate time) and therefore don't have a copy of the e-mail. And we don't know how to track it back.

I'm a programmer and so IT is not my domain, but the programmer in me screams that there's got to be a way to trace this back to the origin. We're running on MS Exchange.

Is it possible to trace this e-mail back to the sender? And how can we do it?!