Bug 1458440
| Summary: | The command "spacewalk-sync-setup" without any parameters return traceback | ||
|---|---|---|---|
| Product: | Red Hat Satellite 5 | Reporter: | Martin Korbel <mkorbel> |
| Component: | Server | Assignee: | Grant Gainey <ggainey> |
| Status: | CLOSED ERRATA | QA Contact: | Lukáš Hellebrandt <lhellebr> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 580 | CC: | dyordano, ggainey, jdobes, jdostal, jhutar, lhellebr, tlestach |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | spacewalk-utils-2.5.1-26-sat | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-10-19 11:57:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1004536, 1450111, 1450940 | ||
spacewalk 4130e786a40f5bef961153b817eafca5ad57415a Reproducer from OP only works for the first time. In the next runs, another traceback appears:
# spacewalk-sync-setup
Traceback (most recent call last):
File "/usr/bin/spacewalk-sync-setup", line 619, in <module>
master_cnx = connectTo(master_info)
File "/usr/bin/spacewalk-sync-setup", line 304, in connectTo
logging.info("Connecting to " + info['login'] + "@" + info['fqdn'])
TypeError: cannot concatenate 'str' and 'NoneType' objects
To force the original traceback again, run this before running spacewalk-sync-setup:
# rm -rf .spacewalk-sync-setup
FailedQA. Tried with spacewalk-utils-2.5.1-24. This is not fixed at all. Another traceback, mentioned in comment 4, is fixed instead. Reproducer: # rm -rf .spacewalk-sync-setup # spacewalk-sync-setup spacewalk.github: 6cc8c05ebed37c701127675b9a8c0065f1989764q (In reply to Grant Gainey from comment #6) > spacewalk.github: > 6cc8c05ebed37c701127675b9a8c0065f1989764q Bad hash, the real one 6cc8c05ebed37c701127675b9a8c0065f1989764 I can verify the bug is fixed in spacewalk-utils-2.5.1-25. However, I think using http instead of https (comment 8) is a security regression and as such, I want someone to confirm we really want to do this - Tomas? Also, you left, probably by accident, verbose=1 which results in pretty long and usually unnecessary output. (In reply to Lukáš Hellebrandt from comment #10) > I can verify the bug is fixed in spacewalk-utils-2.5.1-25. > > However, I think using http instead of https (comment 8) is a security > regression and as such, I want someone to confirm we really want to do this > - Tomas? The API example doc, and most of the other cmds in utils, use http. However, it looks like two of our cmds (clone-by-date and spacewalk-manage-channel-lifecycle) *do* use https. I'll investigate and see if I can figure out what makes the difference - I know that the newer the python2 release is, the less-happy it is with the self-signed-cert from Sat5. > Also, you left, probably by accident, verbose=1 which results in pretty long > and usually unnecessary output. ...ugh. Yes, I did do that. Fixing. (In reply to Grant Gainey from comment #11) > (In reply to Lukáš Hellebrandt from comment #10) > > I can verify the bug is fixed in spacewalk-utils-2.5.1-25. > > > > However, I think using http instead of https (comment 8) is a security > > regression and as such, I want someone to confirm we really want to do this > > - Tomas? > > The API example doc, and most of the other cmds in utils, use http. However, > it looks like two of our cmds (clone-by-date and > spacewalk-manage-channel-lifecycle) *do* use https. I'll investigate and see > if I can figure out what makes the difference - I know that the newer the > python2 release is, the less-happy it is with the self-signed-cert from Sat5. Run spacewalk-sync-setup on RHEL6, using HTTPS to talk to the master/slave servers, and it works. The exact same code, run under F25, fails with CERTIFICATE_VERIFY_FAILED. We can turn https back on, for spacewalk-sync-setup - but it will fail on anything running python 2.7.9 or better. (As will any of the rest of our tooling that tries to use HTTPS with python-xmlrpclib on python 2.7.9 or better). We could turn off ssl-cert-verification for the script - but at that point, you're not actually using SSL, you're using something that does most of the work of SSL without actually being secure... > > Also, you left, probably by accident, verbose=1 which results in pretty long > > and usually unnecessary output. ...ugh. Yes, I did do that. Fixing. (In reply to Grant Gainey from comment #12) > (In reply to Grant Gainey from comment #11) > > (In reply to Lukáš Hellebrandt from comment #10) > > > I can verify the bug is fixed in spacewalk-utils-2.5.1-25. > > > > > > However, I think using http instead of https (comment 8) is a security > > > regression and as such, I want someone to confirm we really want to do this > > > - Tomas? > > > > The API example doc, and most of the other cmds in utils, use http. However, > > it looks like two of our cmds (clone-by-date and > > spacewalk-manage-channel-lifecycle) *do* use https. I'll investigate and see > > if I can figure out what makes the difference - I know that the newer the > > python2 release is, the less-happy it is with the self-signed-cert from Sat5. > > Run spacewalk-sync-setup on RHEL6, using HTTPS to talk to the master/slave > servers, and it works. The exact same code, run under F25, fails with > CERTIFICATE_VERIFY_FAILED. We can turn https back on, for > spacewalk-sync-setup - but it will fail on anything running python 2.7.9 or > better. (As will any of the rest of our tooling that tries to use HTTPS with > python-xmlrpclib on python 2.7.9 or better). We could turn off > ssl-cert-verification for the script - but at that point, you're not > actually using SSL, you're using something that does most of the work of SSL > without actually being secure... > > > > Also, you left, probably by accident, verbose=1 which results in pretty long > > > and usually unnecessary output. > > ...ugh. Yes, I did do that. Fixing. I would switch it back to https, I think we already solved this issue in past. As you say this is expected with newer Python and I think the right way how to deal with this is to add your Sat's cert to your Sat's machine trusted store: Put the cert into /etc/pki/ca-trust/source/anchors/ and run update-ca-trust. This should be actually done during Sat installation already, iirc (?). Or if the Sat's cert is installed using pre-generated rhn-org-trusted-ssl-cert RPM from Sat's /pub it's done automatically during installation. (typically on clients) Sounds reasonable. Lukáš - I made it so that the xmlrpclib-cnx verbose-ness is now controlled by the --debug flag (as it should have been from the start). -d sets verbose=1, default is verbose=0. spacewalk.github: 1a3ceb75fa1b492144643e7a9e66c1e4ef1cd4c5 Verified with spacewalk-utils-2.5.1-26. Used reproducer from comment 5. Also verifying the debug switch works correctly. *** Bug 1001615 has been marked as a duplicate of this bug. *** *** Bug 1004536 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:2915 |
Description of problem: The command "spacewalk-sync-setup" without any parameters return traceback. Version-Release number of selected component (if applicable): spacewalk-utils-2.5.1-23 How reproducible: 100% Steps to Reproduce: > spacewalk-utils-2.5.1-23 Actual results: Traceback (most recent call last): File "/usr/bin/spacewalk-sync-setup", line 614, in <module> config = setupConfig(options) File "/usr/bin/spacewalk-sync-setup", line 212, in setupConfig initializeConfig(opt, handle) File "/usr/bin/spacewalk-sync-setup", line 148, in initializeConfig hdr = hdr.replace('SLAVE', opt.slave) TypeError: expected a character buffer object Expected results: no traceback Additional info: