uyuni – open-source configuration and infrastructure management | Hacker News Reader

uyuni – open-source configuration and infrastructure management

uyuni-project.org

42 pointsgjvc16 comments

https://www.uyuni-project.org/uyuni-docs/en/uyuni/quickstart...

> 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)

Guessing: it is probably used in shell commands and there's no intent to handle escaping.

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.

related to a recent discussion about Java exceptions (https://news.ycombinator.com/item?id=36708759), this project clearly haz all teh kwal-uh-teee:

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;
        }

Regarding that not following the developer rules, that specific commit was removing a module, which also removes the changes file for that module. The developer could not add a change log to a file there. The check is blind, so it returns the alert, but in this case can be ignored.

I am always beyond disappointed to see stuff like no spaces.

I understand the desire to flee Ansible before the IBM shittification completes, but anything based on Salt is not the way.

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.

I'm not at all a fan of Ansible but I must have missed something here - has IBM somehow bought/taken over Ansible?

RedHat owns Ansible and IBM owns RedHat.

IBM acquired RedHat who made Ansible. I believe that’s what the parent comment is alluding to.

Red Hat owns commercial side of Ansible and Red Hat was acquired by IBM

IBM -> RedHat -> Ansible (https://docs.ansible.com/platform.html)

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

Has something happened to the ansible-doc command?

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

Not sure where the dislike comes from, when all configuration management tools have issues with "orphaned nodes". I've even have small bugs/misconfigurations in fully push/declarative setups with Terraform packages where they stopped identifying updates correctly. If anything, with a push tool like Terraform reporting that it did what it planned on doing successfully, its arguably easier to not notice something has been orphaned since you won't have any signal back that something is "wrong", an orphaned configuration node has nothing to do and therefore is already "correct". Salt may have its flaws, but I find it hard to argue that "orphaned nodes" is any more of a flaw of salt than it is of cfEngine, Chef, Ansible, Puppet, Terraform, Helm Charts, Kubernetes Operators, or any other "configuration management tool".

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.

There is also foreman/katello

Kinda sucks that a distro neutral configuration manager would mandate that it has to run on SuSE. Most people who actually need CM don't want to take another major vendor through compliance just to roll out a tool.

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.

OpenSUSE to be precise. Having participated in a few of their community hours and learned that they are actively working on containerizing the server. This approach will eliminate the need for specific requirements and allow the server to run seamlessly on top of any distribution.

Reply on news.ycombinator.com