perl dependency prevents installing the 32bit libs on amd64

[Jeff Strunk]

[Impact]
the 32bit libnss-sss can't be installed on amd64, since the package depends on perl which isn't multiarched. Reimplementing the snippet that used perl allows the package to drop the dependency.

[Test case]
try to install libnss-sss:i386 on amd64

[Regression potential]
the perl snippet was replaced with (from postinst):

    # append 'sss' to the end of the line if it's not found already
    sed -i --regexp-extended '
      /^(passwd|group|netgroup):/ {
        /\bsss\b/! s/$/ sss/
      }
    ' /etc/nsswitch.conf

this has independently been verified to work. Note that the perl version added the entry for shadow as well, but SSSD doesn't handle shadow maps.

--

I discovered this on Maverick amd64. When attempting to run a 32 bit application, we get the following error, and the application fails to run.

$ acroread

(acroread:20387): GLib-WARNING **: getpwuid_r(): failed due to unknown user id (1115)

According to https://fedorahosted.org/sssd/ticket/190 , this is due to the 32 bit application being unable to load the 64 bit library.

After installing the 32bit libnss-sss package files to /lib32, acroread works as expected.

Please include the 32bit libnss-sss.so in the 64bit package, or do what libnss-ldap does to handle this.

Thank you.

[Stephen Gallagher (stephen-gallagherhome)]

I think the appropriate behavior here would be to make libnss-sss.so(32-bit) a "recommended" package for SSSD. The reason you might not want to install the 32-bit libnss-sss.so by default is that it would immediately require the 32-bit glibc as a dependency. For platforms that want to remain 100% 64-bit, this would be unacceptable.

[Steve Langasek (vorlon)]

The most recent upload of sssd for Ubuntu makes libnss-sss a multiarch package, which means that once multiarch is turned on by default in the package manager, you will be able to install 'libnss-sss:i386' to get the 32-bit .so.

This will not (yet) be pulled in by default because cross-architecture depends/recommends are currently not allowed by the package manager.

[Timo Aaltonen (tjaalton)]

One way to accomplish this is to add a virtual package that's only available on i386 which depends on libnss-sss, and then add a Recommends on that for sssd.

[TORNADO (tornado-torn)]

Bug still persists in Ubuntu 12.04.1 LTS
Unable to install libnss-sss:i386

 libnss-sss:i386 : Depends: perl:i386 but it is not going to be installed
                   Recommends: sssd:i386 but it is not going to be installed

[Stephen Gallagher (stephen-gallagherhome)]

Recommends: sssd:i386 but it is not going to be installed

That doesn't sound right to me. You don't want to have a 32-bit and 64-bit version of the daemon package running on the same system. It's wasteful and potentially harmful. The 64-bit server talks to the clients over sockets, so the clients can be 32-bit or 64-bit.

[Timo Aaltonen (tjaalton)]

yeah, the depends/recommends are wrong.. or sssd should be Multi-Arch: foreign to satisfy the Recommends for libnss-sss, not sure what to do with perl. Maybe rewrite the hackish nsswitch.conf mangling in postinst..

[Timo Aaltonen (tjaalton)]

perl needs to be multi-arch: foreign as well, but it seems to be more complicated, bug 1017603

[Ove Risberg (ove-risberg)]

The perl snipplet in postinst can be replaced with this one line sed command:
sed -i '/^\(passwd:\|group:\|shadow:\|netgroup:\)/ { /\(\ssss\s\|\ssss$\)/ !{ s/$/ sss/ } }' /etc/nsswitch.conf

And the perl snipplet in portrm can be replaced with this one line sed command:
sed -i '/^\(passwd:\|group:\|shadow:\|netgroup:\)/ { s/\(\s\s*\)sss\s\s*/\1/; s/\s\s*sss$// }' /etc/nsswitch.conf

This will hopefully remove the perl dependency...

[Launchpad Janitor (janitor)]

This bug was fixed in the package sssd - 1.9.2-0ubuntu4

---------------
sssd (1.9.2-0ubuntu4) raring; urgency=low

  * Add -lpthread to sss_ssh_knownhostsproxy LDFLAGS (FTBFS).
 -- Timo Aaltonen <email address hidden> Sat, 01 Dec 2012 08:58:44 +0200

[Adam Conrad (adconrad)]

Hello Jeff, or anyone else affected,

Accepted sssd into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/sssd/1.8.6-0ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Christophe Drevet (christophe-drevet)]

Hello Adam,

Thanks for your work on this.

I tried to install libnss-sss:i386 (1.8.6-0ubuntu0.1) from precise-proposed and I'm not sure what to think.

The package itself can be installed on my system without issue. But it came with a recommendation to install sssd:i386 as well which is conflicting with sssd(amd64). So I must manually unselect sssd:i386 (in aptitude, at least) to be able to install libnss-sss:i386.

Do you think it would be possible to either :
. resolve the conflict between sssd and sssd:i386
. change the recommendation to a suggestion for sssd

[Ballock (ballock)]

Hello, Christophe,

I think this change is a already good step forward. I am using "apt-get install --no-recommends libnss-sss:i386" and it works fine. Actually I deploy it to all the machines in my organization like this.

You can't resolve the conflict between sssd and sssd:i386 as this would cause you to have 2 sssd daemons running on a system (32 and 64 bit) and you don't want that.

Changing Recommends: sssd to Suggests: sssd is not a good idea, considering that libnss-sss will not work at all without an sssd daemon running on the system.

I guess the only way forward is to make native sssd satisfy all foreign archs sssd requirement, but I don't know if that can be done.

Cheers,
Ballock

[Christophe Drevet (christophe-drevet)]

OK. Sounds good.
I guess I should use this option (--no-recommends) to deploy packages as well, anyway.

[Timo Aaltonen (tjaalton)]

I guess sssd binary should be 'Multi-Arch: foreign' then, which would mean that sssd:amd64 would satisfy the dependency for libnss-sss:i386?

[Timo Aaltonen (tjaalton)]

uh, of course sssd is already M-A: foreign, aptitude in precise just doesn't support multiarch that well so that's the reason why it's trying to pull the i386 version of sssd..

so, can we mark this verification-done?

[Ballock (ballock)]

Tested 1.8.6 on Precise. Fixes the bug. Not ideal (as mentioned above), but I believe there's no better fix for this possible inside this package.

[Timo Aaltonen (tjaalton)]

This bug was fixed in the package sssd - 1.8.6-0ubuntu0.2

---------------
sssd (1.8.6-0ubuntu0.2) precise-proposed; urgency=low

  * rules: Really install the new pam-auth-update file for password
    changes. (LP: #1086272)
  * rules: Pass --datadir, so the path in autogenerated python files is
    correctly substituted. (LP: #1079938)