-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix FQDN machine name mapping on proxy configuration #7672
fix FQDN machine name mapping on proxy configuration #7672
Conversation
Suggested tests to cover this Pull Request
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how you document what was the issue in the PR description. Since it's fairly hard to find the PR from a given commit, would you mind adding it to the commit description too? In such cases if there is only one commit GH adds the description to the PR when you create it.
- fix FQDN machine name mapping on proxy configuration | ||
- fix proxy configuration error display |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is for users to read: you don't have to be too specific. Think about you would like to see here as a user that indicates your bug is fixed. And I wouldn't have 2 entries here: one is enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got you! To see it as end user is a good hint.
else { | ||
return String.join("."); | ||
} | ||
String[] hostnameParts = this.getCn().replace("*", "_star_").split("\\."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I don't understand here is why this is needed... Was the bug only if there is a *
in the proxy FDQN? or is that character added somehow? The proxy FQDN should not contain such a character: it's a single name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure why you'd use asterisk, ie, specifying/restricting domain in this context.
I wasn't expecting this to be a valid input, but it doesn't even fail any validation. For me, this could even have been a slip.
But the fact they were specifically handled by python's machine name mapping is what made me think asterisks are expected.
As far as i see we have 2 options:
- keep the solution, focusing on the original failure when accessing the uploaded files
- add a validation to the fqdn inputs 'Proxy FQDN' and 'Parent FQDN' when they contain
what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding validation of the FQDNs couldn't be a bad thing, but I had the issue here even without any invalid one... so I think the truth is somewhere else
After some quick debugging here, I found that we miss a
|
After trying again I figured out I was mistyping my CA password. Once set right I got the config generated correctly. Could you please add the missing log and add the verification of the FQDNs on the Java side? I can show you later how to add them on the TSX side if you are interested in that 😜 |
d2ffa4a
to
0ba0550
Compare
4cfeef7
to
a09df8b
Compare
a09df8b
to
a4071bf
Compare
It was noticed that configuring a proxy sometimes would fail and just display a generic error. Analysis can be split in two: - what was causing the problem Files uploaded during configuration are stored and moved based on a 'machine name' mapping based on the provided 'Proxy FQDN'. https://github.com/uyuni-project/uyuni/blob/32465f6efccd319926ae1897e14d9d20d4d89c39/spacewalk/certs-tools/sslToolLib.py#L73 Current solution based on a slightly more generic occurrence: https://github.com/uyuni-project/uyuni/blob/f1f62028c363f8ea95b0cc080b4fa9eddf9fbaa0/spacewalk/certs-tools/rhn_ssl_tool.py#L205 - why was just a generic error This had to do with our (rhn) custom FileUtils throwing generic RTEs while RhnRuntimeException is expected https://github.com/uyuni-project/uyuni/blob/32465f6efccd319926ae1897e14d9d20d4d89c39/java/code/src/com/redhat/rhn/common/util/FileUtils.java#L130
a4071bf
to
966629a
Compare
What does this PR change?
It was noticed that configuring a proxy sometimes would fail and just display a generic error.
Analysis can be split in two:
Files uploaded during configuration are stored and moved based on a 'machine name' mapping based on the provided 'Proxy FQDN'.
uyuni/spacewalk/certs-tools/sslToolLib.py
Line 73 in 32465f6
Current solution based on a slightly more generic occurrence:
uyuni/spacewalk/certs-tools/rhn_ssl_tool.py
Line 205 in f1f6202
This had to do with our (rhn) custom FileUtils throwing generic RTEs while RhnRuntimeException is expected
uyuni/java/code/src/com/redhat/rhn/common/util/FileUtils.java
Line 130 in 32465f6
GUI diff
No difference.
Documentation
No documentation needed: only internal and user invisible changes
DONE
Test coverage
Unit tests were added
DONE
Links
Fixes: #7610
Changelogs
Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository
If you don't need a changelog check, please mark this checkbox:
If you uncheck the checkbox after the PR is created, you will need to re-run
changelog_test
(see below)Re-run a test
If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run: