dastra's questions

We're running unattended-upgrades on debian squeeze, and would like it to run once a week, only on a Wednesday morning.

To attempt this, we have set:

APT::Periodic::Unattended-Upgrade "7"

in /etc/apt/apt.conf.d/50unattended-upgrades

And then touched the /var/lib/apt/periodic/update-stamp to set the timestamp to a Wednesday, for instance:

touch -t 201211280000 /var/lib/apt/periodic/update-stamp

Running:

stamp=$(date --date=$(date -r /var/lib/apt/periodic/update-stamp --iso-8601) +%s 2>/dev/null)

date -u --date="1970-01-01 $stamp sec GMT"

Gives the correct timestamp:

Wed Nov 28 00:00:00 UTC 2012

However, unattended-upgrades then seems to ignore this, and run the updates on a Saturday morning.

Could anyone enlighten me as to how this parameter works, and how to set up upgrades to run on a Wednesday?

We have a PHP application which connects to a MySQL server, and we wish to secure connections between the web & application servers and the database.

At peak times, the web servers make many hundreds of concurrent connections to the database, and perform lots of small reads and writes. I'm aware this isn't optimal, and am working on reducing the number of database connections in parallel to this.

We don't have persistent connections to the database turned on currently, and although we intend to in the future I would like to implement this independently of that.

Hardware wise - the MySQL server is quite chunky (16 core) as are the web servers. They're dedicated servers.

My question then surrounds the most performant way of securing & encrypting the connections to the database server.

My research so far has suggested that the main performance overhead is with setting up the SSL connection - once SSL is connected there is little performance penalty. And here's what I have about each method of securing the connection:

1. MySQL SSL Certificates - works just like normal SSL. Can use client certificates to prevent unauthorised connections. No persistent connections with our existing setup. Still have to have MySQL listening on an open port on the firewall.
2. stunnel. Set up a port to port ssl tunnel. Do not have to reconfigure MySQL. Can close the normal MySQL listening port to prevent malicious MySQL connection attempts. Does not support persistent connections. Unknown performance hit.
3. SSH Tunneling. Create an SSH tunnel between the client and the server. Do not have to reconfigure MySQL. Can close the normal MySQL listening port to prevent malicious MySQL connection attempts. Supports persistent connections, but these sometimes drop out. Unknown performance hit.

This is as far as I've been able to get. I'm aware of the limitations of benchmarks - in my experience of running them it's very difficult to simulate real world traffic. I was hoping that someone had some advice based on their own experiences of securing MySQL?

Thanks