Py3.6 System - Config backups - Backup Current Configuration #2569
Comments
|
That one is due to
The big thing we may need to account for here, relates to how we use the md5 digest in that area:
The concern I have here is that the different method of generating the md5 digest may lead to a different digest than before. If that is the case, we would thus have a mismatch for all config backups currently in the database and we would thus delete their entry... Not the greatest user experience. We would thus need to verify whether the digest differ with either method when compared to our previous solution. |
|
@FroggyFlox Thanks for taking a look at this one: much apprecaited: I vote for:
Re:
OK, that's pretty messy. I wonder if we could just flag as legacy older (non matching) config files - rather than have them wiped from the db completely. |
|
Yeah... I'm really not sure how to deal with that one... I'll try to have a clear idea of whether md5 do differ and how we can adapt them accordingly. Hopefully we can indeed find a good solution. |
|
@FroggyFlox Noting here our remaining test issues - all of which are around this issues related code I think: |
|
I tried to test whether the md5 digest would remain identical between an update from current master branch to current testing branch:
The MD5 is thus still the same in Now, to further test, delete this config backup using the webUI.
All of that is reassuring. |
|
As briefly mentioned above, the original error reported in this issue can be fixed by opening the gzip file in For information,
It thus seems like we could simply switch to |
Let's test that using a Python console, based on our newest Py3.6 branch: >>> import os, hashlib
>>> def md5sum_new(fpath):
>>> # return the md5sum of the given file
>>> if not os.path.isfile(fpath):
>>> return None
>>> md5 = hashlib.md5()
>>> with open(fpath, "rb") as tfo:
>>> for l in tfo.readlines():
>>> md5.update(l)
>>> return md5.hexdigest()
>>> def md5sum_old(fpath):
>>> # return the md5sum of the given file
>>> if not os.path.isfile(fpath):
>>> return None
>>> md5 = hashlib.md5()
>>> with open(fpath) as tfo:
>>> for l in tfo.readlines():
>>> md5.update(l.encode())
>>> return md5.hexdigest()
>>> ss_src = "/usr/lib/systemd/system/smb.service"
>>> md5sum_new(ss_src) == md5sum_old(ss_src)
True
>>> md5sum_new(ss_src) != md5sum_old(ss_src)
False
>>> md5sum_new(ss_src)
'f96d97329b8314e9662ca24c8484b44d'
>>> md5sum_old(ss_src)
'f96d97329b8314e9662ca24c8484b44d'Looks like we can safely replace the |
|
looks like a "proof" right there, the outcome of your test yields the same md5 sum, so I would tend to say that should work. |
|
After fixing...
... we have... ... and thus... ... resulting in a functional restore of a config backup taken on a |
Following our move to Py3.6, we were unable to create a new config backup due to a failure to get the md5 digest of a gzip file (such as a config backup). Our config backup restore was also failing to the presence of a Py2.7-specific bit of code. This commit: - adjusts `md5sum()` to be able to read a compressed file as well. - ensures the task def validation returns the share/pool id as string - add type hints to help ensure proper types are used/returned - minor docstrings adjustments - Copyright update
…ups_Backup_Current_Configuration Restore config backup functionality #2569
|
Closing as fixed by #2592. |
Post #2567 in testing branch we have a failure in our Backup Current Configuration button function:
Noting a PyCharm editor warning on: src/rockstor/storageadmin/models/config_backup.py
return os.path.join(self.cb_dir(), self.filename)
"Unexpected Types"
The text was updated successfully, but these errors were encountered: