This changes moves from using SQLite in the integration tests and in the
test/boulder-config.json.
It does not port the unit tests over, unfortunately. That's a much more
invasive change.
This also updates the Dockerfile to include the MariaDB and RabbitMQ
requirements of start.py as well as adjusts the CMD to expose the
boulder server to the host machine. The Dockerfile also needed to have
its Go version bumped and the test.sh had to grow some explict
"function"s.
Updates #132
Fixes#579 (which blocks #132).
This changes the SA to use a unique index on the sha256 of a
Registration's JWK's public key data instead of on the full serialized
JSON of the JWK. This corrects multiple problems:
1. MySQL/Mariadb no longer complain about key's being larger than the
largest allowed key size in an index
2. We no longer have to worry about large keys not being seen as unique
3. We no longer have to worry about the JWK's JSON being serialized with its inner keys in different orders and causing incorrectly empty queries or non-unique writes.
This change also hides the details of how Registrations are stored in
the database from the other services outside of SA. This will give us
greater flexibility if we need to move them to another database, or
change their schema, etc.
Also, adds some tests for NoSuchRegistration in the SA.
We move the admin-revoker and expiration-mailer to using the
SA.GetRegistration RPC method instead of digging into the database
itself.
This allows the hiding of the registration model layer inside of SA, so
we can do fancy things with sha256 for the unique index inside of
it. This will happen in a later commit. See #579.
By exposing fewer details about how Registration is stored, we gain more
flexibility to fix up how its stored.
In the expiration-mailer, the performance hit for the early filtering of
mailto is likely neglibible and possibly even a benefit given the cost
of joins to the memory of MySQL.
If need be, we can built a bulk RPC layer for SA that provides the data
we need in findExpiringCertificates. It'll be easier than trying to
scale and change the storage layer underneath for each consumer.
Roland Shoemaker