## python3-rtslib-fb ## [Summary] MIR Team conditional-Ack. Good packaging in general, but we need the steps below to be completed before being really ready for promotion: (Note: this is Very similar to targetcli-fb) @rafaeldtinoco - please update python-rtslib-fb - update targetcli-fb to 2.1.71 - fix d/watch to detect the non *fb* versions - as usual work with Debian to have it there as well sooner or later - not sure but it might even need an epoch :-/ @rafaeldtinoco - please make install-fail graceful (see below for detail) Could be just a condition in the service, but that is up to you @rafaeldtinoco - please get Josh to subscribe to (all) these packages - we can drop that later, but that way we a) don't miss it later b) get a glimpse of the bug influx on these packages @rafaeldtinoco - tests missing Can we get some tests that will exercise targetcli-fb in this or another package of this MIRs context? @rafaeldtinoco - (optional) targetctl man page If it seems easy to do writign and proposing upstream a man page would be great, currently there is nothing but the -h output and that is rather scarce. @Rafael - once you are done with the above, please assign security to the python-rtslib-fb task @security - please put it on your review queue, but only process it once we are at version >=2.1.71 which @rafaeldtinoco will work on first. [Duplication] This is "object API for managing the Linux LIO kernel target"" we don't have that in main yet. TGT is no full alternative and to be replaced (tgt to be demoted) once we are ready to promote this. [Dependencies] OK: - All dependencies are in main already. - No -dev/-debug/-doc packages with extra deps that would be auto-incldued that need exclusion later on promotion [Embedded sources and static linking] OK: - no embedded source present - no static linking [Security] OK: - history of CVEs does not look concerning - does not use webkit1,2 - does not use lib*v8 directly - does not open a port - does not process arbitrary web content - does not use centralized online accounts - does not integrate arbitrary javascript into the desktop - does not deal with system authentication (eg, pam), etc) Problem: - does run a daemon as root - does parse data formats I don't think any of that will be critical it just reads the stored config from disk and restores it on boot. But one could e.g. mess with the config files to break it in unexpected ways. The executed program targetctl is part of this package, so it isn't reviewed already in another context. => security review is requested [Common blockers] OK: - does not FTBFS currently - no translation present, but none needed for this case (admin only)? - no new python2 dependency - uses dh_python Problems: - no Team subscriber yet, server-team please subscribe - does not have a test suite that runs at build time - does not have a test suite that runs as autopkgtest -> could we get some basic tests when working on 2.1.71 to at least cover and detect the most obvious issues) It might be ok to get the tests done in one of the packages here that would then use all the packages belonging to this "context". - doesn't install-fail gracefully Error on non-LIO capable systems (e.g. container unable to load modules) I know it can't really "work" there, but it should not break install itself. This needs to be made graceful (e.g. a systemd condition) Job for rtslib-fb-targetctl.service failed because the control process exited with error code. See "systemctl status rtslib-fb-targetctl.service" and "journalctl -xe" for details. invoke-rc.d: initscript rtslib-fb-targetctl, action "start" failed. ● rtslib-fb-targetctl.service - Restore LIO kernel target configuration Loaded: loaded (/lib/systemd/system/rtslib-fb-targetctl.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2020-02-25 06:45:06 UTC; 24ms ago Process: 1567 ExecStart=/usr/bin/mkdir -p /etc/rtslib-fb-target (code=exited, status=0/SUCCESS) Process: 1568 ExecStart=/usr/bin/targetctl restore (code=exited, status=1/FAILURE) Main PID: 1568 (code=exited, status=1/FAILURE) Feb 25 06:45:06 f target[1568]: File "/usr/bin/targetctl", line 47, in restore Feb 25 06:45:06 f target[1568]: errors = RTSRoot().restore_from_file(restore_file=from_file) Feb 25 06:45:06 f target[1568]: File "/usr/lib/python3/dist-packages/rtslib_fb/root.py", line 84, in __init__ Feb 25 06:45:06 f target[1568]: modprobe('target_core_mod') Feb 25 06:45:06 f target[1568]: File "/usr/lib/python3/dist-packages/rtslib_fb/utils.py", line 425, in modprobe Feb 25 06:45:06 f target[1568]: raise RTSLibError(stderrdata) Feb 25 06:45:06 f target[1568]: rtslib_fb.utils.RTSLibError: b"modprobe: ERROR: ../libkmod/libkmod.c:611 kmod_search_moddep() could not open moddep file '/lib/modules/5.3.0-40-generic/modules.dep.bin'\nmodprobe: FATAL: Module target_core_mod not found in directory /lib/modules/5.3.0-40-generic\n" Feb 25 06:45:06 f systemd[1]: rtslib-fb-targetctl.service: Main process exited, code=exited, status=1/FAILURE Feb 25 06:45:06 f systemd[1]: rtslib-fb-targetctl.service: Failed with result 'exit-code'. Feb 25 06:45:06 f systemd[1]: Failed to start Restore LIO kernel target configuration. dpkg: error processing package python3-rtslib-fb (--configure): installed python3-rtslib-fb package post-installation script subprocess returned error exit status 1 @Rafael - could you please fix that? [Packaging red flags] OK: - Ubuntu does not carry a delta - symbols tracking not applicable for this kind of code. - Upstream update history is good - promoting this does not seem to cause issues for MOTUs that so far maintained the package - no massive Lintian warnings - d/rules is slightly odd, using openstack-pkg-tools but seems ok overall - not using Built-Using Problems: - Debian/Ubuntu update history is slow e.g. 2.1.fb69 was added ~1year after its release - the current release is not packaged, d/watch doesn't detect the new versions so we miss 1.5y of updates which needs to be fixed. => https://github.com/open-iscsi/rtslib-fb/compare/v2.1.fb69...v2.1.71 - d/watch is present but missed non fb prefixed releases - Finally there is no man page for targetctl, but that is an upstream problem. It seems to ahve not too many options, so maybe oen could be added by providing a PR upstream? [Upstream red flags] OK: - no Errors/warnings during the build - no incautious use of malloc/sprintf (python) - no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH - no use of user nobody - no use of setuid (needs very careful design (prefer systemd to set those for services)) - no important open bugs (crashers, etc) in Debian or Ubuntu - no dependency on webkit, qtwebkit, seed or libgoa-* - no embedded source copies - not part of the UI for extra checks (If this is a scope for the Unity Dash, does it honor the privacy settings?)