Bug 1409333
| Summary: | dnf-plugins/spacewalk.py - TypeError: argument of type 'NoneType' is not iterable | ||
|---|---|---|---|
| Product: | [Community] Spacewalk | Reporter: | Fermulator <redhat-bugzilla> |
| Component: | Clients | Assignee: | Tomáš Kašpárek <tkasparek> |
| Status: | CLOSED DUPLICATE | QA Contact: | Red Hat Satellite QA List <satqe-list> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 2.6 | CC: | ogajduse |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-06-13 17:49:42 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: | 1484117 | ||
DNF plugin package versions may also be needed $ rpm -qa | grep dnf | grep plugin python2-dnf-plugins-core-0.1.21-3.fc24.noarch dnf-plugin-system-upgrade-0.7.1-3.fc24.noarch python3-dnf-plugins-core-0.1.21-3.fc24.noarch python-dnf-plugins-extras-migrate-0.0.12-3.fc24.noarch dnf-plugins-core-0.1.21-3.fc24.noarch python-dnf-plugins-extras-common-0.0.12-3.fc24.noarch python3-dnf-plugin-system-upgrade-0.7.1-3.fc24.noarch python2-dnf-plugin-system-upgrade-0.7.1-3.fc24.noarch dnf-plugin-spacewalk-2.6.3-1.fc24.noarch Also of note, w.r.t. the failed dnf update and administrator pushed packages -- once the client re-enabled the local fedora-updates.repo, (rather than relying on the spacewalk server for packages), the update is successful. So this is isolated down to the Python bug as noted above. This /could/ be the same as https://bugzilla.redhat.com/show_bug.cgi?id=1331494#c12. That bug report, while not initially about that issue, eventually led to it. This is the code in the dnf-plugins/spacewalk.py
{{{
def add_http_headers(self, handle):
http_headers = []
for header in self.needed_headers:
if not header in self.login_info:
error = MISSING_HEADER % header
raise dnf.Error.RepoError(error)
if self.login_info[header] in (None, ''):
# This doesn't work due to bug in librepo (or even deeper in libcurl)
# the workaround bellow can be removed once BZ#1211662 is fixed
#http_headers.append("%s;" % header)
http_headers.append("%s: \nX-libcurl-Empty-Header-Workaround: *" % header)
else:
http_headers.append("%s: %s" % (header, self.login_info[header]))
if not self.force_http:
http_headers.append("X-RHN-Transport-Capability: follow-redirects=3")
if http_headers:
handle.setopt(librepo.LRO_HTTPHEADER, http_headers)
}}}
Note sure as of yet what the issue is.
Need to understand what the importance of "login_info" is. (I tried augmenting and ultimately removing the code surrounding it -- the for loop: "for header in self.needed_headers" -- but ended up hitting other error conditions).
It's clear that login_info is initialized to "None" in activate_channels().
Then it tries to populate it via the up2date information:
{{{
try:
login_info = up2date_client.up2dateAuth.getLoginInfo(timeout=self.conf.timeout)
except up2dateErrors.RhnServerException as e:
logger.error("%s\n%s\n%s", COMMUNICATION_ERROR, RHN_DISABLED, e)
return
if not login_info:
logger.error("%s\n%s", NOT_REGISTERED_ERROR, RHN_DISABLED)
self._write_channels_file({})
return
}}}
For my client system, I don't have any login information defined ... is it required?
{{{
$ sudo cat /etc/sysconfig/rhn/up2date | grep -i login
}}}
Reproducer and the results are exactly the same as in the BZ#1331494 The fix is available in the nightly repository. *** This bug has been marked as a duplicate of bug 1331494 *** This BZ closed some time during 2.5, 2.6 or 2.7. Adding to 2.7 tracking bug. |
Description of problem: Running "sudo dnf update" has been yielding an error message about failing to synchronize the cache for the spacewalk managed repository for clients. Digging more into this, it seems that the spacewalk dnf plugin bails out when running "makecache". Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. After having installed spacewalk client and registered 2. After server channel & repo configuration, client subscription etc 3. Client disables local OS updates repo (enabled=0) 4. Client attempts to manually upgrade packages (which should pull via spacewalk) -- OR -- administrator pushes package updates to client Actual results: Initial observations at first were from administrator perspective, trying to push updates with the shiny new repo sync webUI interface, but even basic package updates started to fail: {{{ This action will be executed after 12/31/16 9:05:00 AM EST This action's status is: Failed. The client picked up this action on 12/31/16 12:00 PM The client completed this action on 12/31/16 12:00 PM Client execution returned "Failed: Packages failed to install properly: Package file-roller-0:3.20.4-1.fc24.x86_64 is not available for installation Package file-roller-nautilus-0:3.20.4-1.fc24.x86_64 is not available for installation Package shotwell-0:0.24.3-1.fc24.x86_64 is not available for installation" (code 32) Packages Scheduled: file-roller-nautilus-3.20.4-1.fc24.x86_64 shotwell-0.24.3-1.fc24.x86_64 file-roller-3.20.4-1.fc24.x86_64 }}} Weird, so then the client tries manually: {{{ $ sudo dnf update This system is receiving updates from Spacewalk server. Failed to synchronize cache for repo 'fedora_24', disabling. <<--- ouch Last metadata expiration check: 0:12:17 ago on Sat Dec 31 16:10:30 2016. }}} Running makecache yields this stacktrace in the Python scripts: {{{ $ sudo dnf makecache Traceback (most recent call last): File "/bin/dnf", line 58, in <module> main.user_main(sys.argv[1:], exit_code=True) File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 174, in user_main errcode = main(args) File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 60, in main return _main(base, args) File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 112, in _main cli.run() File "/usr/lib/python3.5/site-packages/dnf/cli/cli.py", line 1099, in run return self.command.run(self.base.extcmds) File "/usr/lib/python3.5/site-packages/dnf/cli/commands/makecache.py", line 89, in run self.base.fill_sack() # performs the md sync File "/usr/lib/python3.5/site-packages/dnf/base.py", line 239, in fill_sack self._add_repo_to_sack(r) File "/usr/lib/python3.5/site-packages/dnf/base.py", line 111, in _add_repo_to_sack repo.load() File "/usr/lib/python3.5/site-packages/dnf/repo.py", line 833, in load handle = self._handle_new_remote(tmpdir) File "/usr/lib/python3.5/site-packages/dnf-plugins/spacewalk.py", line 264, in _handle_new_remote self.add_http_headers(handle) File "/usr/lib/python3.5/site-packages/dnf-plugins/spacewalk.py", line 247, in add_http_headers if not header in self.login_info: TypeError: argument of type 'NoneType' is not iterable }}} Expected results: dnf spacewalk plugin has to work Additional info: $ cat /etc/fedora-release Fedora release 24 (Twenty Four) $ uname -a Linux mcallaghan-lnx-1 4.8.15-200.fc24.x86_64 #1 SMP Thu Dec 15 23:09:22 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | grep spacewalk python3-spacewalk-backend-usix-2.6.74-1.fc24.noarch spacewalk-oscap-2.6.1-1.fc24.noarch spacewalk-client-repo-2.6-0.fc24.noarch dnf-plugin-spacewalk-2.6.3-1.fc24.noarch