Univention Bugzilla – Bug 38633
malformed .ini file causes appcenter traceback (KeyError: 'id')
Last modified: 2017-07-06 14:26:07 CEST
Execution of command 'appcenter/query' has failed: We received the following traceback, 4.0-2 errata205 (Walle): It happens if the 'id' is missing in a .ini file of any app. How could that happen without manipulating it manually? Should we ignore broken .ini files? Traceback (most recent call last): File "%PY2.7%/univention/management/console/base.py", line 282, in execute function(self, request) File "%PY2.7%/univention/management/console/modules/appcenter/__init__.py", line 81, in _decorated return func(self, request, *a, **kwargs) File "%PY2.7%/univention/management/console/modules/decorators.py", line 316, in _response result = _multi_response(self, request) File "%PY2.7%/univention/management/console/modules/decorators.py", line 460, in _response return list(function(self, iterator, *nones)) File "%PY2.7%/univention/management/console/modules/decorators.py", line 282, in _fake_func yield function(self, *args) File "%PY2.7%/univention/management/console/modules/appcenter/__init__.py", line 123, in query applications = Application.all(force_reread=True) File "%PY2.7%/univention/management/console/modules/appcenter/app_center.py", line 774, in all cls._all_applications.append(Application(ini_file, localize)) File "%PY2.7%/univention/management/console/modules/appcenter/app_center.py", line 365, in __init__ self.set_id(self._options['id']) KeyError: 'id'
Reported again, 4.0-2 errata205 (Walle)
Reported again, different UUID, 4.0-2 errata214 (Walle)
Reported again, different UUID, 4.0-2 errata215 (Walle)
Reported again, 4.0-2 errata279 (Walle)
Reported again, 4.0-3 errata292 (Walle)
Reported again, 4.0-3 errata288 (Walle)
There is an md5 check between what we write in our index.json and what UMC actually received as file content. While these two md5 hashes should be the same, maybe here they are not? Currently, UMC logs a WARNING but saves the ini file (or png, README, ...) as is. Maybe we should just delete them? However, if only this very file (that failed the md5 test) is discarded, this may lead to a broken "app meta file bundle". Maybe we need to discard the ini file, too, if the README is broken for whatever reason. Here it the ini files itself, though. But I do not know how this can happen other than some strange connection error while downloading.
Reported 4 times again by the same UUID, 4.0-3 errata320 (Walle)
14 times reported from 6 different UUID's until now.
The same UUID reported it another 3 times again, today.
That user btw. also reported Bug #38285 once: LOCAL_ERROR: {'info': 'SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (Matching credential (ldap/snIactIve00.active.sni@ACTiVE.SNi) not found)', 'desc': 'Local error'} (but probably they don't have to do with each other).
Reported again, 4.1-0 errata0 (Vahr)
Reported again, 4.1-0 errata75 (Vahr)
Maybe this is fixed by Bug #40874?
Move to 4.0-5-errata.
Moved to 4.1-2-errata. Still valid?
(In reply to Stefan Gohmann from comment #17) > Moved to 4.1-2-errata. Still valid? Let's wait if we receive this again from an >=4.1-1-errata130 system. If we don't receive it we can close it in e.g. a half year as WORKSFORME/Bug #40874. So we don't waste time in a maybe/probably already fixed bug.
This is not fixed yet, just a bit more unlikely to occur since we did some performance optimizations. Due to these optimizations, the ini files are not parsed by the old code during the very first module call (appcenter/query). So the App Center should at least load. But as soon as someone chooses to install any non-docker App and has such a malformed ini file, the traceback should return because then all ini files are parsed. Bug #40874 improved error handling of ini files in the new code, so this does not help. In fact, the new code was never vulnerable to this special error. This ini file has been ignored by the new code since 4.1-0. To fix this bug as DUPLICATE/WORKSFORME, one needs to fix Bug#40064.
Not happened since February? So, it is not critical and should be fixed along with Bug#40064 *** This bug has been marked as a duplicate of bug 40064 ***