> Passwords must be at at least seven characters in length, and must not contain spaces, single or double quotation marks (' or "), exclamation marks (!), or dollar signs ($)

bahahahahaaha, whaaaaat is going on here?!

---

In an effort to be constructive, previously: https://news.ycombinator.com/item?id=31115254 (60 pt, 7 comments)

Okay, guessing less: https://github.com/uyuni-project/uyuni/blob/88b6b3cf25a2fd6b....

By the way: 83k+ commits and 15k+ tags. There are seven programming languages in the main repository. Sounds impenetrable. PRs merged with failing tests and developers not following their own requirements, example: https://github.com/uyuni-project/uyuni/pull/7243#issuecommen....

This commit is interesting: https://github.com/uyuni-project/uyuni/blame/df29070c58a9a1b.... It fixes the password printed to logs which existed on the main branch for about a year.

https://github.com/uyuni-project/uyuni/pull/7274/files#diff-...

                catch (IOException e) {
                    log.warn("Cannot read {}", file.getName());
                }

          catch (IOException e) {
            log.warn("Cannot create " + NOREPO_FILE + " file.");
          }

        catch (IOException e) {
            return false;
        }

Needing a "master" node that can lose sync or orphan managed nodes it forgets about is a show stopper for any project with meaningful hardware churn.

Also... Salt does have High Availability options, https://docs.saltproject.io/en/latest/topics/highavailabilit... with Replication/Failover and Multi-Master modes, and there's also "Syndic" which break up how much each master is responsible for in order to create failure domains or separate responsibilities between stacks of infrastructure like having one per datacenter... oh and the underlying data stores that masters and syndic daemons rely on can be setup with highly configurations since you can keep the cached data in Redis, Consul, EtcD, or MySQL...

Salt is a bit complicated, but just can't understand where you're coming from here. I've never used a configuration management system that wasn't a bit complicated in one way or another, their job is to be the sin-eater of the complexity that is inherent in managing computers and software.

I think the new ansible docs are opaque, and the new "everything is an ansible collection" scheme makes troubleshooting any issues reported by users hundreds of times harder than "the old days"

I keep this (https://github.com/ansible-community/ansible-build-data/blob...) bookmarked because it's the only way to match up what "ansible 8.1.0" (https://pypi.org/project/ansible/8.1.0/) even means since it for damn sure not any of this: https://github.com/ansible/ansible/releases (they used to have a 'release' pinned on that releases tab saying "these are not the droids you are looking for"). I believe I tried asking for them to update the completely erroneous pypi "source code" link to point to that repo and ... well, one can see how well that turned out

This has behaved the same for me for years, but I use distribution packages so may lag behind a bit.

In any case, "machines" are well trodden ground. It's all the random "smart" network devices and "cloud services" that make documenting and auditing configuration absolute tedium today.