Update MariaDB repo and key for Xenial

[RiFi2k]

MariaDB was still using the repo and signing keys for Trusty which was also using weak digest algorithm (SHA 1) you can see this when you run apt-get update currently.

This change should cover all the bases and be non-breaking on existing installs as well as work as it currently does in relation to remote database setups.

• Conditionally check if you have the old Trusty repository currently configured. If so it will remove those lines and add the updated repo.
• If it detects the removal of the Trusty lines then it moves to update your MariaDB packages but only on that run so it won't be updating packages on every run once the initial change is made.
• If you are running a setup with only remote databases it will only update mariadb-client but if you have local databases then it will update mariadb-server as well.

You can easily test this by spinning up a VM as the role stands currently. Then switch to this new branch and re-provision and you will see it gracefully updates everything. Then run it again and you will see that it doesn't try updating MariaDB packages again.

[swalkinshaw]

Good catch on this.

One issue is that Trellis currently works on both Trusty and Xenial (as far as I know). We should definitely encourage and even require Xenial for new installs, but someone can re-provision an existing Trusty server right now without breaking anything.

With this PR as it is, it would update MariaDB to Xenial which might break Trusty?

Maybe we have to conditionally set those default variables based on Ubuntu version?

[RiFi2k]

Without looking I'm 90% sure I worked that in. It only runs the repo update
if user is using Xenial, if not then it stays as is.

On Sep 28, 2016 6:43 PM, "Scott Walkinshaw" notifications@github.com
wrote:

Good catch on this.

One issue is that Trellis currently works on both Trusty and Xenial (as
far as I know). We should definitely encourage and even require Xenial for
new installs, but someone can re-provision an existing Trusty server right
now without breaking anything.

With this PR as it is, it would update MariaDB to Xenial which might break
Trusty?

Maybe we have to conditionally set those default variables based on Ubuntu
version?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#659 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AMEHA3lwp0pvVZ6oyaAfvFQL5THW6l18ks5quu2ggaJpZM4J_ef-
.

[RiFi2k]

Yeah, just took a look.

when: ansible_distribution == 'Ubuntu' and ansible_distribution_release == 'xenial'

I'm running this on the step that changes the repo out and all the following steps related to upgrading all only when this step runs, so it should be 100% safe on Trusty setups because it simply will skip all my additions.

Although it would probably be more elegant to set the repos based on your version of Ubuntu, I can make that change if you feel like it's better for long term support even past Xenial.

[swalkinshaw]

Oops, I did kind of gloss over that. I was also worried about the task above it:

- name: Add MariaDB MySQL apt-key
  apt_key:
    url: "http://keyserver.ubuntu.com/pks/lookup?op=get&fingerprint=on&search={{ mariadb_keyserver_fingerprint }}"
    state: present

Since mariadb_keyserver_fingerprint changed even for Trusty users, this might get run again and add the Xenial specific key? I'm just not sure what consequences would happen from that.

[RiFi2k]

Good call on that.

I'm gonna switch this around a bit and make it so it will be distribution dependent the whole way through. Add the keys and repo for trusty if you are on trusty, add the keys and repo for xenial if you are running that, and also upgrade from trusty to xenial if you are running the old trusty keys and repo on xenial.

I'll commit the changes here and comment back when it's done.

[RiFi2k]

Ok, so I added a check for the key based on which distribution and also for the repo to configure just using the ansible distribution variable instead of having a variable for it, to avoid confusion.

Also just hard coding the old trusty key as the important part is having the key for Xenial editable.

[runofthemill]

I've been dealing with some related issues, and wanted to note that MariaDB is available in Trusty Tahr 14.04 onwards - the first two tasks in trellis/roles/mariadb/tasks/main.yml (and accompanying variables in defaults/main.yml) can be removed without impacting the playbook, at least on a fresh installation on df376a0.

[RiFi2k]

Seems the the versions are a match on the packages I checked.

I guess at this point it's more about who you want maintaining your packages and updates for MariaDB and its deps.

Keep it as is
MariaDB Developers
http://mirror.jmu.edu/pub/mariadb/repo/10.0/ubuntu/dists/xenial/main/binary-amd64/Packages

Remove the repo completely (would probably just need to add a step for existing installs that removes the MariaDB repo and runs apt-get update, also side note would need tested to make sure after update and upgrade nothing breaks)
Ubuntu Developers
http://packages.ubuntu.com/xenial/mariadb-server-10.0

Thoughts on the subject?

[swalkinshaw]

I'd lean towards just using the official Ubuntu package now. Unless we have a good reason not to, it's usually a good thing to default to that.

Even that page says:

For these you can use the distribution's management system to install MariaDB.

[eshimischi]

mariadb_binary_logging_disabled: true
mariadb_keyserver_fingerprint: "0xf1656f24c74cd1d8"
mariadb_mirror: nyc2.mirrors.digitalocean.com
mariadb_version: "10.1"
mariadb_dist: xenial
mysql_root_user: root

from roles/mariadb/defaults/main.yml

[runofthemill]

agree with @swalkinshaw - keeps the code DRYer too

[swalkinshaw]

@RiFi2k are you still able to take care of this, or want us to finish it?

[RiFi2k]

Oops, my fault for going MIA on you. I can for sure finish this up, but not thinking I got rid of my fork, doh!

Did some research and even re-forking and pulling this pull request into the new fork won't let me make an update. I don't know if you care about losing this conversation if I had to submit a new pull request with the fix, also I'm quite sure you don't want this orphaned pull request hanging out just so it can be linked to the new one either.

Then I saw the File System & Backups protocol from that Github blog so I already put in a support request to have it restored into my account. I would assume they would be able to take care of restoring it for me quickly and right after they do I'll shoot an update.

[swalkinshaw]

@RiFi2k don't worry about this PR. You can just create a new one if you need to and reference this one. Thanks 👍