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