[Rpm-maint] rpm --chroot and glibc/nscd

[Panu Matilainen]

On 05/17/2011 04:36 PM, Michael Schroeder wrote:
> On Tue, May 17, 2011 at 04:27:08PM +0300, Panu Matilainen wrote:
>> Did you try talking to glibc developers about this? Just asking so I
>> wont bother them again if they already told you to keep the pieces or
>> something to that effect...
>
> Not really. I was never successful when proposing something to
> Ulrich Drepper, so I didn't dare this time ;-)

I know what you mean... My turn to test my luck then :)

> Also, I needed a fix for the old SUSE versions, so it didn't make
> much sense to ask for some new functionality.
>
> But I agree that support in glibc would be much better than this
> hack. Note that you have to both delete the ncsd connection and
> flush the nss setup.

Yup.

>
>>> The patch also
>>> - fixes the cache usage. lastUnameLen/lastGnameLen were never
>>>    set, so the code *always* did a getpwuid/gid call!
>>> - renames lastU/GnameLen to lastU/GnameAlloced in
>>>    rpmugU/Gname, so that it is consistent with the
>>>    rpmugU/Gid function.
>>>
>>> Even if you do not want the safe_lookup() part, having a
>>> rpmugChroot() function that calls endpwent()/endgrent() and
>>> drops the local caches if a chroot is done seems like a
>>> good idea.
>>
>> Hmm, wouldn't it suffice to just store the rpmChrootDone() state in
>> rpmug and flush the caches etc when the chroot_done state has changed
>> between calls?
>
> Yes, that was actually how I coded it earlier. I then simplified
> it a bit -- how often is the chroot state changed?

Rpm goes in and out of chroot for each transaction element - typically 
the packages to install live outside of the chroot so opening the 
package file needs to happen outside chroot, and actual installation 
obviously inside the chroot. For removals it wouldn't have to, but 
there's no real win special-casing that.

So flushing caches on each state change means the cache is only valid 
for a single package installation, but once inside the transaction the 
rpmug stuff will only get called inside the chroot (IIRC) so the cache 
would remain valid for the entire transaction if it's only flushed at 
use-time instead of state-change time.

>
>> Other than that, will apply at least the other bits, I'll mull over the
>> safe_lookup() a bit (perhaps a bit academic but it might break if the
>> chrooted version is configured to use something else than files for user
>> information, but then it probably doesn't work now either due to glibc
>> remembering that stuff).
>
> Yes, that's why it is better to tell glibc to re-read the nss
> setup. OTOH it probably doesn't make much sense if glibc does
> ldap lookups in the chroot or something like that.

Yup, it seems unlikely that anybody wants ldap lookups in a chroot. Nss 
could be configured to use 'db' too but that seems unlikely as well (I 
dont recall ever seeing/hearing anybody using that but hey what do I know)

	- Panu -