Total Ignorance in hostname checking logic in foreman-installer

Support
1

Problem:
I am absolutely disgusted with the lack of professionalism in the decision making process of some people in this project.
Who in their right mind decided that the following logic was acceptable when validating server host names before foreman-installer will install ?

I have a cluster with the naming convention logic;_..net

Foreman Server e.g.
myCassandraCluster_0.myDomain.net foreman-installer can not cope with characters like _

Parameter foreman-servername invalid: _..net must match one of (?-mix:^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9-][a-zA-Z0-9]).)([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9-]*[A-Za-z0-9])$)

Expected outcome:

Which moron thinks that all host names in the real world only contain alpha numeric charters ?

Whoever made this decision should not be allowed to work on this project.
These type of ignorant unprofessional people ruin projects, destroy their reputation, and undermine all the hard work of others working on the project.

If you don’t know the RFC and can not be bothered to read the RFC, just ask the community

(https://tools.ietf.org/html/rfc2181#section-11)

I am tired of this bullshit project and im installing Salt.

Foreman and Proxy versions:
latest

Foreman and Proxy plugin versions:
latest

Other relevant data:
installing with Ubuntu Bionic

logs

2

Correction I used chevrons which have been parsed out of the original text …

"I have a cluster with the naming convention logic; myClusterName_clusterInstance.net

Foreman Server e.g.
myCassandraCluster_0.myDomain.net foreman-installer can not cope with characters like _

Parameter foreman-servername invalid: myClusterName_clusterInstance.net must match one of (?-mix:^(([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9-] [a-zA-Z0-9]).) ([A-Za-z0-9]|[A-Za-z0-9][A-Za-z0-9-]*[A-Za-z0-9])$)"

3

Your post is very unprofessional and unacceptable. However, since you at least posted a link to an RFC I will reply with the RFCs that actually state this is incorrect usage:

https://www.ietf.org/rfc/rfc1912.txt

Allowable characters in a label for a host name are only ASCII letters,
digits, and the `-’ character. Labels may not be all numbers, but may have a
leading digit (e.g., 3com.com). Labels must end and begin only with a
letter or digit. See [RFC 1035] and [RFC 1123]. (Labels were initially
restricted in [RFC 1035] to start with a letter, and some older hosts still
reportedly have problems with the relaxation in [RFC 1123].) Note there are
some Internet hostnames which violate this rule (411.org, 1776.com). The
presence of underscores in a label is allowed in [RFC 1033], except [RFC
1033] is informational only and was not defining a standard. There is at
least one popular TCP/IP implementation which currently refuses to talk to
hosts named with underscores in them. It must be noted that the language in
[1035] is such that these rules are voluntary – they are there for those who
wish to minimize problems. Note that the rules for Internet host names also
apply to hosts and addresses used in SMTP (See RFC 821).

1 Like
4

Stdlib::Fqdn is used here, the source is https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/types/fqdn.pp - so please stop by at Puppet Labs to rant and let us know how it went. :gift_heart:

1 Like
5

I hope you don’t expect salt to work well with your non-standard hostnames, or are you planning to be also rude to them when you realize they strip away the underscores?

1 Like
6

It is NOT non standard. just because somebody reads Wikipedia and believes that the LDH convention is in fact a standard is wrong. the RFC’s are the standard. and the RFC clearly states that it is perfectly acceptable to use _ (and indeed many other characters).

I have been working in this industry for over 30 years. I had my own email server, DNS Server, internet domain and node on the internet, while everybody was still using AOL and CompuServe. Google\Yahoo did not even exist.

While I acknowledge since the advent of Google (other search engines did not re-parse _ at the time) … it has become practical to implement LDH labels … even the later RFC’s refer to it as “preferred name syntax” NOT A STANDARD!

I also perfectly accept that if I was building an internet facing service, I would indeed be negligent if I did not implement LDH on those nodes or at least use load balancer’s, NAT Firewall’s, to mask hosts that would cause issues with Google.

However by assuming that LDH is a standard is nothing more than incompetence for two main reasons;

1). It rules out foreman being implemented on perfectly legal, acceptable and well used naming conventions for millions host names in private networks. I have worked with all the major international banks, and IT Companies like IBM on large legacy networks (before Google even existed) and can tell you such naming conventions were well used at the time.

For somebody in foreman to think that LDH is a universal standard and not a convention for internet facing hostnames … is pure ignorance as it expect people to rename all their hosts to get foreman to install.

2). Somebody did not clearly read that LDH was for hostnames
“[2.3.1] LDH Label
This is the classical label form used, albeit with some additional restrictions, in hostnames”

The logic stated in the fqdn checking syntax also precludes legal characters as per the RFC standard for domain names too.

By the way puppet and salt work perfectly well supporting LDH.

Probably because those developers realise that the RFC is the standard not wikipedia or Google!

7

correction “By the way puppet and salt work perfectly well supporting LDH.”

should have read

“By the way puppet and salt work perfectly well not supporting LDH.”

8

apologies … I should clarify that i do not use puppet Enterprise just the cli tools so the fqdn.pp referenced must not be being implemented by puppet cli and indeed not salt cli.

I was actually hired on my first job to replace x400 and x25 networks with TCP\IP and Windows for workstations did not even have its own TCP/IP stack so often we were writing our own, back in those days there was only RFC’s and only CERN had a decent web page … so RFC’s were taken as gospel, while there were plenty of grey areas, if it was not expressly prohibited in the RFC we would not assume it and would code to cope with all eventualities. I actually worked with the well known IP Stack mentioned in the RFC that that issues with “_” … which is why we got rid of it and implemented a RFC Compliant OSI implementation.

Perhaps i am a relic of a bygone era and nobody respects RFC’s these days :frowning:

9

What exactly are you hoping to achieve by being extremely rude to a group of developers who are working on an open source project, many of them in their free time, none of which you pay a salary to or even know in person?
How is your previous work experience relevant to the discussion? Do you expect people to just say “oh, this person, who is being very rude to me and is deriding my work, professionalism and skills as an engineer, has been working for many years in the industry so I should just do what he tells me to do”?

3 Likes
10

Per the original RFC 952 a hostname is composed of letters, numbers or hyphens. Not underscores:

<name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]

RFC 1123 relaxed the requirement slightly by allowing it to start with digits as well. I’m unaware of a RFC that relaxes this to allow underscores.

Other than that, I your tone is still unacceptable. If you wish to change something, this is not the way to do it.

11

Hi I am not seeking support.

I am trying to shake the project maintainers up to take seriously flaws that are undermining what is a great project. I am even happy to contribute code changes, but I cant do this while people have fundamental misunderstanding of what the real standards are and just how inconstant the project is when it comes the host naming conventions and the tools it uses

e.g. It uses facter and hostname ?? why two different tools that uses different logic in parsing host & domain that causes the installer to barf because the results can differ. Take a look at the original 127.0.1.1 fdqn standard and see how this will prevent foreman from installing when using local files. I can clearly see there is a lack of experience in the project who understands the real RFC’s, original system V standards upon which all this new networkmanager\resolver layers still sit upon and have to support but don’t do so well.

To be fair this is not foreman that has created the problems. Over the last 15 I have seen the old system V standards get ignored by people in the dist maintainers who have tried to make things (easier to understand) but have in fact created a complete nightmare to support. How many different name resolvers\managers do we have and now even abstractions like netplan in Ubuntu that don’t even support the nuances of the old standards in teh generated files that are needed to fix foreman installer issues (e.g.domain statement in interface files).

I spend a lot of my time reporting and big fixing Cisco Nexus switches so I am used to dealing with low level network protocol issues and RFC violations like this to a high level of detail.

Many many people I have spoken to warned me that foreman was a nightmare to install.
I have had so much bad feedback I was surprised as with RHEL adopting puppet there would be not be an upsurge in support.

However I have abandoned foreman after two days of struggling to deal with its inconsistencies that simply prevent it being installed. I abandoned it not because I could not get it working, I just did not want to bother having to constantly hack code\scripts that are not up to the rigorous network checking diligence required to deal with the mess that the distros (Ubuntu in particular) have caused.

It would just constantly break my clusters if I attempted updates.

I have deliberately switched to salt to see how the foreman salt integration support is, as I have had people warn me about that too.

From what I have seen most of the issues are just silly logic issues that are fixable.

1). Stick to hostname or facter or checking the generated files directly (hosts/resolv.conf/hostname/networks)

2). Fix the logic error in thinking that the internet is LDH when all the switches, bind use real RFC Standards …forget “_”, I have not even started on international character sets which are supported by RFC. The internet does exist outside of countries that use more that the 26 Alpha characters and decimal digits. The DNS octets are BINARY in the core network infra and the RFC just limit the sizes of the chains and the separators and from memory the beginning of a hostname starting with a “-” (i’d have to kick up a bind instance and test that old chestunt I’d bet it still works).

I can understand why people are giving the project a bad name as steep learning curve

Its not technically complex, just some basic decision making problems.

12

All those who have responded to you so far are some of the project maintainers, including myself.

If you wish to contribute, improve and discuss technical matters, starting off by calling people “morons”, “ignorant”, “unprofessional” and the project “bullshit” is a good way to make sure none of the maintainers or other developers ever want to work with you on improving it or changing what you think it does wrong.

Despite your unacceptable behaviour, we have tried to be very polite and explain why we disagree with your argument rather than block your account and delete this discussion. You still chose to continue communicating rudely and insultingly.

No one (here, at least) is forcing you to use Foreman - you are welcome not to use it if you don’t think it fits your needs. We try to be friendly and helpful to new users, many of which have successfully installed Foreman and use it to manage networks of all sizes - from a small home network to tens of thousands of nodes across multiple datacenters and compute resources. Had you tried asking politely for help with the setup, I’m sure many of them would be happy to help you. Had you opened a civilized discussion regarding host name conventions in the development category, I’m sure many of the developers would have been happy to discuss it and improve as needed (and perhaps show some other considerations that were made when making some technical decisions that you are not aware of).

It’s easy to yell and insult strangers on the internet, but it’s also not difficult to be kind, polite and nice to people. Who knows, maybe you’ll find out that by collaborating everyone can win.

I hope you have a happy new year and don’t get yelled at by strangers on the internet.

5 Likes
13

I actually spend 2 days of my holiday helping one of your users who could not get the software working on one of my enterprise clusters. I was not doing it for myself.

People come to me when things don’t work … when I find fault i escalate.

If you don’t believe me I can understand, I can give you a contact in Cisco who implements their DNS products. People are not reading the RFC’s properly … they are very clear, it uses terms such as “preferred” but clearly states the ASCII character support as binary blobs in the fqdn octets. Preferred does not mean implicit

… the logic is wrong, full stop, it wont help the project or the users.

I have ran open source projects before and seem them fail down to individual mistakes which undermines the hard work and efforts of the whole team.

If Linus was sloppy we would not have an amazing kernel. I expect the same standards from myself.

While I apologies if my sleep deprived angst offended people.

However I don’t differentiate the quality of my work if its commercial or Open source.
If anything else I work harder for open source because I know the code has to be be bullet proof and understand the stress and pain it can cause unskilled users who don’t do this for a living.

I would never do this logic error for an end user myself, its for them that I am trying to correct this mistake.

If you do not believe I am correct, or let me bring in Cisco otherwise I can’t help.

One the wire and in the fqdn octets in memory they are just binary blobs, in the BIND/Cisco DNS code they support’s the ASCII character set with a few limitations as per the RFC’s (namely length & “.” separators).

Also what about my point … the logic apply’s to the full fdqn not just the hostname?

Shall I crate a http instance on my EC2 elastic cloud with the alleged none standard charters and see if it works on the internet infra and core DNS ?

Just because puppet have got it wrong dopes not mean that everybody else is justified in copying the same mistake ?

14

I should also apologies and mention that I create playgrounds for developers off the corp infrastructure so we can support the open source community … and test and try out software without the restrictive diligence of security, code inspection and penetration testing.

I support open source and promote the contribution financially to open source rather than the enterprise commercial additions.

If I was frustrated, its because oversights like this, undermine my efforts to promote the open source community as a workable business model, rather than keep buying commercial offerings, when we could be hiring devs to feed back into open source.

I work in high availability high pressured environments, and I should have switched my mindset accordingly.

This is not my project and you guys are not my dev ops, I am not paying you.

I should have not reacted as if this was my project.

Apologies.

15

That’s a great post / reference.

If you read it, in full

“The presence of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
is informational only and was not defining a standard. There is at
least one popular TCP/IP implementation which currently refuses to
talk to hosts named with underscores in them.”

It further goes on to state …

“It must be noted that the language in [1035] is such that these rules are voluntary – they
are there for those who wish to minimize problems. Note that the
rules for Internet host names also apply to hosts and addresses used
in SMTP (See RFC 821).”

If when coding to a RFC, if it is not implicitly stated as a requirement, you can not assume that it is implemented by everybody, and therefore you have to accept that you need to support all eventualities. BIND does it, Cisco does, puppet should also do it. the Earlier RFC’s are clear abut binary blobs representing the octets and its support for the ASCII character set.

16

In case you are still missing the point, the installer check is totally not about standards, this is all about reasonable default. Foreman consist of about two dozen of components which do something with hostnames and all those components implement the hostname handling in a slightly different way. As you can see, different RFCs, different people, different opinions.

We have deliberately chosen the common denominator in our installer because we had users complaining in the past about hostname errors. These kind of errors were not easy to troubleshoot, so we have chosen to be opinionated to prevent spending hours and hours helping frustrated users who used some semi-valid character in a hostname that is causing problems to a component that is not even maintained by us.

However, you may disable this check and proceed if you want. Those errors only appears in particular situations and your workflow might be the lucky one. You better pick a new username on our community site because after this shit-storm I am pretty sure nobody will be eager to help you. I will be very cautious when replying to any hostname related question from now on.

I don’t want to comment what you have done here, it’s disgusting. People like you have one thing in common tho, they like to expose how many years they’ve been in the industry. Let me tell you something, those 30 years are waste of time with this behavior. Think.