On 2007-07-17, Peter Chant wrote:
> Chaps,
>
> looking to make a script to make file systems for virtual machines and I ran
> into this one, it appears that installpkg calls ldconfig. When running
> installpkg as a user (not root) and using the -root option for my
> subdirectory with the new file system installpkg is complaining when it is
> trying to run ldconfig for example see output below. Question is, if it
> could write the temporary file would ldconfig put its output in the correct
> place. Bit concerned as I suspect to get the correct permissions I will
> have to run the script as root and I don't want to hose my installation by
> running ldconfig in the wrong place.
>
> Pete
>
>
> Installing package ytalk-3.3.0-i486-1 ([skip])...
> PACKAGE DESCRIPTION:
> ytalk: ytalk (multi-user chat program)
> ytalk:
> ytalk: YTalk is a multi-user chat program. It works almost exactly like the
> ytalk: UNIX talk program and even communicates with the same talk daemon,
> but
> ytalk: YTalk allows for multiple connections.
> ytalk:
> /sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~:
> Permission denied
> Executing install script for ytalk-3.3.0-i486-1...
>

This is by design. pkgtools is not meant to be run by a normal user.

-Matt

>> /sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~:
>> Permission denied
>> Executing install script for ytalk-3.3.0-i486-1...
>>
>
> This is by design. pkgtools is not meant to be run by a normal user.

Well yes and no, you are not getting my point. I am trying to create a
root file system to be used in a virtual machine system in say

/home/pete/new-root

I thought it would be a good plan to do that as a user ok.

So, I want installpackage and its invocation of ldconfig to write to
/home/pete/new-root/etc/ld.so.cache~ etc. Seems reasonable to me.

OK, for general permission reasons I may well have to run the script as
root, however, I still want it to write
to /home/pete/new-root/etc/ld.so.cache~ and I'd be rather concerned if it
were writing to /etc/ld.so.cache as that is the wrong part of the
filesystem.

Noting it is falling over I can call ldconfig directly - but if I run it as
root do I have anything to be concerned about?

Pete



--
http://www.petezilla.co.uk

Peter Chant wrote:
>>> /sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~:
>>> Permission denied
>>> Executing install script for ytalk-3.3.0-i486-1...
>>>
>> This is by design. pkgtools is not meant to be run by a normal user.
>
> Well yes and no, you are not getting my point. I am trying to create a
> root file system to be used in a virtual machine system in say
>
> /home/pete/new-root
>
> I thought it would be a good plan to do that as a user ok.
>
> So, I want installpackage and its invocation of ldconfig to write to
> /home/pete/new-root/etc/ld.so.cache~ etc. Seems reasonable to me.
>
> OK, for general permission reasons I may well have to run the script as
> root, however, I still want it to write
> to /home/pete/new-root/etc/ld.so.cache~ and I'd be rather concerned if it
> were writing to /etc/ld.so.cache as that is the wrong part of the
> filesystem.
>
> Noting it is falling over I can call ldconfig directly - but if I run it as
> root do I have anything to be concerned about?

Here's the skinny on ldconfig:
Many (most?) unix programs use shared libraries (called dll's by MS).
Whenever one of these programs starts, it asks the system to load
the libraries it needs. The system then finds and loads the requested
library.

To speed this search, /sbin/ldconfig scans the system (usually just
the directories listed in /etc/ld.so.conf) for shared object files and
stores a lists of what it finds. Other libraries can be specified via
LD_LIBRARY_PATH.

Long story short, don't worry if ldconfig is the only thing failing in
an install script; you just have to set LD_LIBRARY_PATH to include the
directory containing the newly-installed shared libraries.

Hope that helps,
Daniel

D Herring wrote:

> Long story short, don't worry if ldconfig is the only thing failing in
> an install script; you just have to set LD_LIBRARY_PATH to include the
> directory containing the newly-installed shared libraries.
>

So does this mean:

1. I can run ldconfig once the virtual machine has booted, i.e. nothing in
the boot process will need it?

2. I won't break my system if it is supposedly working under my root I
created but actually runs under my real /.

Pete

--
http://www.petezilla.co.uk

Just got back in town...

Peter Chant wrote:
> D Herring wrote:
>> Long story short, don't worry if ldconfig is the only thing failing in
>> an install script; you just have to set LD_LIBRARY_PATH to include the
>> directory containing the newly-installed shared libraries.
>
> So does this mean:
>
> 1. I can run ldconfig once the virtual machine has booted, i.e. nothing in
> the boot process will need it?

Probably. A few things might break during the first boot; but after
ldconfig runs, the other boots should be fine.

> 2. I won't break my system if it is supposedly working under my root I
> created but actually runs under my real /.

If /etc/ld.so.conf doesn't contain any lines referencing this fake
root, then ldconfig won't even look in the fake root. It won't hurt a
thing; your shared libraries still won't be available anywhere, though.


This page might be helpful to you.
http://slackworld.berlios.de/2007/chroot_howto.html

Later,
Daniel