I've just run a test against the modified version built in a ppa: === >8 ==== # apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: python-sss The following packages will be upgraded: libipa-hbac0 libnss-sss libpam-sss libsss-certmap0 libsss-idmap0 libsss-nss-idmap0 libsss-simpleifp0 libsss-sudo python3-sss sssd sssd-ad sssd-ad-common sssd-common sssd-dbus sssd-ipa sssd-krb5 sssd-krb5-common sssd-ldap sssd-proxy sssd-tools 20 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 2350 kB of archives. After this operation, 539 kB of additional disk space will be used. Do you want to continue? [Y/n] ^C === eof ===
So even running 'apt upgrade' pulls in the missing dependency. I checked 'man apt': "upgrade (...) New packages will be installed if required to satisfy dependencies, but existing packages will never be removed." So I guess that's consistent with what I observed. This makes it 1 less thing to worry about. -- You received this bug notification because you are a member of STS Sponsors, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1862226 Title: /usr/sbin/sss_obfuscate fails to run: ImportError: No module named pysss Status in sssd package in Ubuntu: Fix Released Status in sssd source package in Bionic: In Progress Status in sssd source package in Eoan: Fix Released Status in sssd package in Debian: Fix Released Bug description: [Impact] Current bionic d/control doesn't include "python3-sss" or "python-sss" as runtime dependency: Package: sssd-tools Architecture: any Depends: python, sssd-common (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends} Description: System Security Services Daemon -- tools Provides a set of daemons to manage access to remote directories and authentication mechanisms. It provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources. It is also the basis to provide client auditing and policy services for projects like FreeIPA. Current workaround: One can install the dependency by hand. [Test Case] # lsb_release -cs bionic # Install sssd-tools # sss_obfuscate Traceback (most recent call last): File "/usr/sbin/sss_obfuscate", line 8, in <module> import pysss ImportError: No module named pysss [Potential Regression] * After adding the dependency, if one run let's say 'apt-get upgrade': APT-GET(8) - upgrade: under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed. Meaning that one who would go that route, may not be able to get the update and will continue to experience the problem (No module named pysss) APT-GET(8) - dist-upgrade: dist-upgrade in addition to performing the function of upgrade, also intelligently handles changing dependencies with new versions of packages * Since sss_obfuscate never work out of the box (without one installing the missing dependency manually) ... first I don't expect a significant adoption/use of this binary, since it took years for one to discover it ... but since we are 'enabling' sss_obfuscate to finally work out of the box ... who knows what bugs can be found in sss_obfuscate that we didn't know before because it was simply not used. Clearly autopkgtest doesn't test that functionnality, otherwsie it would have caught this before. Some dogfooding testing of sss_obfuscate in -proposed may be useful to catch potential bugs related to its "enablement". It should be trivial to test, the program does only one thing: SSS_OBFUSCATE(8): sss_obfuscate converts a given password into human-unreadable format and places it into appropriate domain section of the SSSD config file. http://manpages.ubuntu.com/manpages/bionic/en/man8/sss_obfuscate.8.html * Worst worst case, sss_obfuscate still won't work as it currently does anyway, and so far it didn't seems to be a major problem in the sssd ubuntu community. But with the dogfooding testing we should be good to catch any obvious irregularity. It should be fine since disco uses the same upstream version and has the right dependendy, so sssd-tools in Bionic and Disco are very code alike. [Other Infos] * Debian upstream: https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c * Debian Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220 Rmadison: => sssd-tools | 1.16.1-1ubuntu1.4 | bionic-updates sssd-tools | 2.2.0-4ubuntu1 | eoan sssd-tools | 2.2.2-1 | focal sssd-tools | 2.2.2-1ubuntu1 | focal-proposed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1862226/+subscriptions -- Mailing list: https://launchpad.net/~sts-sponsors Post to : [email protected] Unsubscribe : https://launchpad.net/~sts-sponsors More help : https://help.launchpad.net/ListHelp
