error: Failed dependencies:
	libssl.so.6 is needed by elog-2.7.5-1.i386
	rtld(GNU_HASH) is needed by elog-2.7.5-1.i386

 Hi,

I just tried to install the latest elog on linux Fedora 10.  I also get an error saying that libssl.so.6 is needed.

But I already have libssl.so.7 installed.  Should I also install libssl.so.6 ?

thx,

-rob

[snihur@nunllap01 ~]$ rpm -qa | grep ssl
qca-ossl-2.0.0-0.4.beta3.fc10.i386
openssl-0.9.8g-12.fc10.i686
docbook-style-dsssl-1.79-5.fc9.noarch
nss_compat_ossl-0.9.4-2.fc10.i386
openssl-devel-0.9.8g-12.fc10.i386
[snihur@nunllap01 ~]$ rpm -q --provides openssl
config(openssl) = 0.9.8g-12.fc10
lib4758cca.so 
libaep.so 
libatalla.so 
libchil.so 
libcrypto.so.7 
libcswift.so 
libgmp.so 
libnuron.so 
libssl.so.7 
libsureware.so 
libubsec.so 
openssl = 0.9.8g-12.fc10
openssl(x86-32) = 0.9.8g-12.fc10

error: Failed dependencies:
	libssl.so.6 is needed by elog-2.7.5-1.i386
	rtld(GNU_HASH) is needed by elog-2.7.5-1.i386

The RPM system is a bit picky about which version is required. I believe you have to install libssl.so.7 or compile elog from the sources, which is very simple. 

Hi,

I really don't understand why elogd cannot run by root but it runs by a user.

I've put elog deamon in /etc/init.d. So it didn't bring up, but it runs if I run it by user interactively.

Thanks,

Dongwook

That's a security issue. If elogd runs under a user and gets hacked, the hacker obtains just the user rights, which can be limited. If it runs under root, the hacker will automatically get root rights, which is bad. Technically, there is no reason why elogd cannot be run as root. Just put

Usr = root

Grp = root

into elogd.cfg. 

 Hi,

I wonder how others manage this situation because deamons in /etc/init.d is excercuted by root. So I cannot run in /etc/init.d/elogd when the system starts up.

What do you think?

Thanks,

Dongwook

The normal situation is that elogd gets started by root under /etc/init.d/, then the configuration file contains "Usr = elog" and "Grp = elog", so after it has been started as root, the program falls back to the "elog" user, which only has restricted rights. 

Now I realized that it is not a problem in /etc/init.d, but deamon itself.

When I run the following command as a root, it didn't run

/mnt/wd500/jnj/products/elog/sbin/elogd -D -c /mnt/wd500/jnj/products/elog/elog/elogd.cfg

But, it runs when I did as a user.

I really don't understand this strange behavior.

Thanks,

Hi Stefan,

When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
your FAQ about marking of whole threads).

In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
ID number.

Thanks,

David Pilgram.