After applying patch http://drupalcode.org/project/hosting.git/commit/9121600 , if the system was migrated from a aegir 1.x system that had multiple IP per certificate, the garbage collection can delete certificates that were in the database as "non-related", as they had different IP, while having the same physical files.

As this might delete certificates and can cause serious downtime, there should be a check to verify that the files are not "physically" in use.

Its just adding a check to: http://drupalcode.org/project/hosting.git/blob/HEAD:/web_server/ssl/host... in the hosting_ssl_clean_keys function. I could write a patch.

Comments

anarcat’s picture

anarcat CreditAttribution: anarcat commented

Hum, this seems to contradict #2159265: SSL certificate not deleted, which says SSL certificates are never deleted at all.

Is this in the frontend or the backend?

Note that the 1.x frontend didn't actually *know* which site was associated to which SSL certificate, it was stored only in the backend. Usually, this is fixed on verify...

So this may be the cause of this problem.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Related issues: +#2159265: SSL certificate not deleted
Guillaume Beaulieu’s picture

Guillaume Beaulieu CreditAttribution: Guillaume Beaulieu commented

I don't understand the aegir packaging mechanisms, but from what I can read, https://drupal.org/node/2159265 seems to be a bug affecting hosting-2.0-rc5 . There isn't a release including the commit making the garbage collection actually working (eg: http://drupalcode.org/project/hosting.git/commit/9121600 ), so my guess is that the bug isn't reproducible on current git aegir-2.x branch, as it is now fixed by the patch aforementionned.

I think you're right when you say that the front end don't know, as from my understanding, when the upgrade from 1 to 2 does happen, the files in ssl.d can be referred multiple times and thus, causing this actual bug we're talking about ; you have multiple IPs pointing at the same actual files, and when you're on the last entry using that "IP" on that cert, it deletes the file for everybody else.

Don't know if that's clear ; I guess I should patch it as PHP is a more universal language.

anarcat’s picture

anarcat CreditAttribution: anarcat commented

Oh I see, I got confused there. So right, #2159265: SSL certificate not deleted was fixed by the commit you mentionned, and I corrected myself over there.

I'd love to get more information about this, however. It would be great if we could have a better upgrade path for SSL hosts. The migration for us was certainly painful.

anarcat’s picture

anarcat CreditAttribution: anarcat commented
Title: SSL Certificate garbage collection overly aggressive » SSL Certificate garbage collection overly aggressive after upgrade from 1.x
Status: Active » Needs work

After discussions with guillaume on IRC, it seems this is due to a corrupted mapping in the site/ssl certificate in the 1.x database.

This is specifically a problem with upgrades, from what I understand.

What is needed here is to clarify a workaround for when this problem happens on upgrade, what steps need to be taken to recover the database and avoid loss of data.

A sanity check could also be performed during upgrade and rollback with an error telling people to fix their stuff.

ac’s picture

ac
Primary language English
Location Perth
CreditAttribution: ac commented

Any news here? Holding back on an upgrade because of this.

ergonlogic’s picture

ergonlogic
he/him
Primary language English
Location Montréal, Québec 🇨🇦
CreditAttribution: ergonlogic at Ergon Logic Enterprises for Aegir Cooperative commented
Status: Needs work » Closed (outdated)

The 6.x-2.x branch will go EOL along with Drupal this week. So I'm closing this issue. If it remains a confirmed issue in 7.x-3.x, feel free to re-open, or better yet, create a new issue referencing this one.