random: expose hashed passwords in recipe options
Directly expose all passlib.hash supported hashes, using a `passwd-` prefix. For example, to access `sha256_crypt`, use `passwd-sha256-crypt` option name. [secret] recipe = slapos.cookbook:generate.password [config-file] hashed-password = ${secret:passwd-sha256-crypt} This changes the format of storage-path, it used to be the password in plain text, it is now a mapping also containing hashed passwords, to have the same hashed passwords for each buildout run. This needs collaboration from publish_early recipe, because .pop(k) does raised a KeyError with the dict.__missing__ approach.
-
Owner
This commit is introducing the following error when passwd is set:
[2024-10-18 14:35:57,397] INFO slapos While: [2024-10-18 14:35:57,397] INFO slapos Installing switch_softwaretype. [2024-10-18 14:35:57,397] INFO slapos Installing monitor-htpasswd. [2024-10-18 14:35:57,397] INFO slapos [2024-10-18 14:35:57,397] INFO slapos An internal error occurred due to a bug in either zc.buildout or in a [2024-10-18 14:35:57,397] INFO slapos recipe being used: [2024-10-18 14:35:57,397] INFO slapos Traceback (most recent call last): [2024-10-18 14:35:57,398] INFO slapos File "/opt/slapgrid/639c58b9c93e44c377060b1a1f618575/eggs/zc.buildout-3.0.1+slapos005-py3.9.egg/zc/buildout/buildout.py", line 2664, in main [2024-10-18 14:35:57,398] INFO slapos getattr(buildout, command)(args) [2024-10-18 14:35:57,398] INFO slapos File "/opt/slapgrid/639c58b9c93e44c377060b1a1f618575/eggs/zc.buildout-3.0.1+slapos005-py3.9.egg/zc/buildout/buildout.py", line 855, in install [2024-10-18 14:35:57,398] INFO slapos self._install_parts(install_args) [2024-10-18 14:35:57,398] INFO slapos File "/opt/slapgrid/639c58b9c93e44c377060b1a1f618575/eggs/zc.buildout-3.0.1+slapos005-py3.9.egg/zc/buildout/buildout.py", line 1026, in _install_parts [2024-10-18 14:35:57,398] INFO slapos installed_files = self[part]._call(recipe.install) [2024-10-18 14:35:57,398] INFO slapos File "/opt/slapgrid/639c58b9c93e44c377060b1a1f618575/eggs/zc.buildout-3.0.1+slapos005-py3.9.egg/zc/buildout/buildout.py", line 1948, in _call [2024-10-18 14:35:57,398] INFO slapos return f() [2024-10-18 14:35:57,398] INFO slapos File "/opt/slapgrid/639c58b9c93e44c377060b1a1f618575/eggs/slapos.cookbook-1.0.369-py3.9.egg/slapos/recipe/switch_softwaretype.py", line 122, in install [2024-10-18 14:35:57,399] INFO slapos sub_buildout.install([]) [2024-10-18 14:35:57,399] INFO slapos File "/opt/slapgrid/639c58b9c93e44c377060b1a1f618575/eggs/zc.buildout-3.0.1+slapos005-py3.9.egg/zc/buildout/buildout.py", line 855, in install[2024-10-18 14:35:57,399] INFO slapos self._install_parts(install_args) [2024-10-18 14:35:57,399] INFO slapos File "/opt/slapgrid/639c58b9c93e44c377060b1a1f618575/eggs/zc.buildout-3.0.1+slapos005-py3.9.egg/zc/buildout/buildout.py", line 1026, in _install_parts [2024-10-18 14:35:57,399] INFO slapos installed_files = self[part]._call(recipe.install) [2024-10-18 14:35:57,399] INFO slapos File "/opt/slapgrid/639c58b9c93e44c377060b1a1f618575/eggs/zc.buildout-3.0.1+slapos005-py3.9.egg/zc/buildout/buildout.py", line 1948, in _call [2024-10-18 14:35:57,399] INFO slapos return f() [2024-10-18 14:35:57,399] INFO slapos File "/opt/slapgrid/639c58b9c93e44c377060b1a1f618575/eggs/slapos.cookbook-1.0.369-py3.9.egg/slapos/recipe/random.py", line 208, in install [2024-10-18 14:35:57,399] INFO slapos if self.create_once and os.stat(self.storage_path).st_size and not self._needs_migration: [2024-10-18 14:35:57,400] INFO slapos AttributeError: 'Password' object has no attribute '_needs_migration'
-
Owner
This problem was with https://lab.nexedi.com/nexedi/slapos/-/blob/863e9196b40fa558f8e3619228add09cd9321b55/software/kvm/instance-kvm-resilient.cfg.jinja2#L35-44
using publish-early with storage-path does not work here.
I start to believe that this combination can also lead to this other problem we observe with partitions having different monitor passwords. I don't really have a full scenario, but because the password storage file is no longer updated if it has been generated, maybe there is a scenario where passwd is not an option a first time, a partition generates its storage file with a password it generates and during next buildout run, passwd is in option but storage file is not updated.
I thought that maybe this does not happen in the test because unlike "slapos master", slap proxy always returns up to date connection parameters and always returns partitions right after requesting. I tried to run KVM resilient tests with a modified slapos proxy introducing delays a bit similar to slapos master, but it did not reproduce. I did not try all possible timing delays scenarios, I still feel that the difference of timings might be the reason why we don't see that password problems with slapos proxy.
slapos proxy patch for test
diff --git a/slapos/proxy/views.py b/slapos/proxy/views.py index 19ce0af13..ee477d95b 100644 --- a/slapos/proxy/views.py +++ b/slapos/proxy/views.py @@ -462,6 +468,14 @@ def supplySupply(): return 'Supplied %r to be %s' % (url, state) +request_failures_by_partition_reference = { + #'PBS (kvm / 1)': 2, + 'PBS pushing on kvm1': 2, + 'kvm0': 1, + 'kvm1': 3, +} + + @app.route('/requestComputerPartition', methods=['POST']) def requestComputerPartition(): parsed_request_dict = parseRequestComputerPartitionForm(request.form) @@ -537,6 +552,18 @@ def requestComputerPartition(): software_instance = requestSlave(**parsed_request_dict) else: software_instance = requestNotSlave(**parsed_request_dict) + failures_left = request_failures_by_partition_reference.get( + parsed_request_dict['partition_reference'], + 0) + print(request_failures_by_partition_reference, slave, matching_partition['reference'] + , parsed_request_dict.get('partition_parameter_kw', {}).get('monitor-password'), + repr(parsed_request_dict['partition_reference'])) + #breakpoint() + request_failures_by_partition_reference[ + parsed_request_dict['partition_reference']] = failures_left - 1 + if failures_left > 0: + abort(503) + else: # Instance is not yet allocated: try to do it. external_master_url = isRequestToBeForwardedToExternalMaster(parsed_request_dict)
This is not the full patch I was trying, I also tried similar approach in other places ( code to emulate frontend requests or
getFullComputerInformation
) -
mentioned in merge request !1671 (merged)