Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 321 of 807  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Version Subjectdown
  1978   Wed Oct 11 08:18:14 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.2-1714Re: SVN1723 (was SVN1714) will not run in 'daemon" mode on Solaris8

Steve Jones wrote:
There are also strange system calls that differ, and I thought it might be due to the setuid(60001) -nobody- but the the non-daemn mode also sets to nobody and works fine.


The elogd program opens the port (which might be below 1024 and thus needs privileges), then either become daemon or not, then changes to the user and group specified in elogd.cfg. So this behaviour should be the same on both cases.



Steve Jones wrote:
I just compiled SVN1723 and tried the generic elogd.cfg -- of course *that works!*. Something in my complex config that causes elog to barf when it is attempting to fork the daemon process.


That's a good starting point. Take your config file, strip one option after the other, and see which is the offending one. This helps us tracking down the problem.



Steve Jones wrote:
I have no idea what "/var/run/syslog_door" is.


I have not either. But one thing which is different in the daemon mode that all output is redirected to the syslog facility via the function call redirect_to_syslog();. This routine was not written by myself so I don't know 100% what it's doing, just under Linux it works fine. Try to outcomment this function and try again.
  1940   Mon Sep 18 22:09:23 2006 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714Re: SVN1714 will not run in 'daemon" mode on Solaris8

Steve Jones wrote:
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"



Quote:

As a followon, when I do run SVN1714 as a detached process but started as ROOT I get the following console messages:

Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.
Cannot restore original GID/UID.

I do not get these when I run the app as me - which is a non-UID 0 account. Perhaps this is an artifact of the "-x" option?

  1947   Fri Sep 22 07:47:58 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportOther2.6.2-1714Re: SVN1714 will not run in 'daemon" mode on Solaris8

Steve Jones wrote:
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"


The "one where it errors out" does not look like an error. It does the "fork()" at the end and the main thread ends, that's how it's supposed to be.
  1954   Fri Sep 22 19:32:45 2006 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714Re: SVN1714 will not run in 'daemon" mode on Solaris8

Stefan Ritt wrote:

Steve Jones wrote:
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"


The "one where it errors out" does not look like an error. It does the "fork()" at the end and the main thread ends, that's how it's supposed to be.



Quote:


Ok, what this tells me is I need to get TRUSS to follow the fork - which I think I can do. The behavior, however, is that elog never goes into daemon mode after that fork.

More info to follow.
  1956   Fri Sep 22 22:12:18 2006 Reply Steve Jonessteve.jones@freescale.comBug reportOther2.6.2-1714Re: SVN1714 will not run in 'daemon" mode on Solaris8

Stefan Ritt wrote:

Steve Jones wrote:
On Solaris, SVN1714 will not go into daemon mode. Running the compiled version under TRUSS (which provides a dump of every system call) and shows precisely where elog is failing. I have attached two TRUSS outputs: one where it errors out and the other where it runs but "interactively". Both runs are as root, simply one with and one without the "-D"


The "one where it errors out" does not look like an error. It does the "fork()" at the end and the main thread ends, that's how it's supposed to be.




Quote:
Ok, I got it. I've attached the TRUSS output where we follow the fork. It appears that elogd cannot open any of the specified files then gives up. What was throwing me is no error output, even to STDERR. When I run the same but without the -D flag the files are opened fine.

There are also strange system calls that differ, and I thought it might be due to the setuid(60001) -nobody- but the the non-daemn mode also sets to nobody and works fine.
  69155   Fri Jun 5 13:24:01 2020 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux3.1.4-2Re: SSL does not work

When you compile elog from the soruces, you need the OpenSSL library to be installed. The CMake build process will then find it and include it in the compile process. When you use the "make" build process, you have to make sure that SSL is enabled there:

USE_SSL = 1

To install the OpenSSL library, you can do on most systems something like "sudo yum install openssl-dev" or "sudo apt-get install openssl-dev"

/Stefan

 

Hisataka YOSHIDA wrote:

Hello.

I installed the latest elog (3.1.4-2) in CentOS 7, and it is working well without SSL.
When I enalbled SSL option (SSL = 1) in the "elogd.cfg", and tried to start the elogd, the message below was shown and failed to run.

SSL support not compiled into elogd

If I switched the elog to older one (3.1.4-1), I could successeed to run the elogd with SSL option.
Is there any other option required in the latest elog to run with SSL? Or is this bug in the latest version?

Thank you,
Hisataka YOSHIDA

 

  69160   Thu Jun 11 08:23:01 2020 Reply Hisataka YOSHIDAhisataka@rcnp.osaka-u.ac.jpBug reportLinux3.1.4-2Re: SSL does not work

Dear Stefan,

Thank you for your comment. I successfuly compiled the latest elog from source code, and now elogd could work with SSL.

In fact, I reported the case of installation with rpm file. Maybe, the latest elog rpm doesn't support SSL, I guess.
The installtion with rpm file is easier to build the common environment, so I hope the next rpm will support the SSL.

best regards,
Hisataka YOSHIDA

Stefan Ritt wrote:

When you compile elog from the soruces, you need the OpenSSL library to be installed. The CMake build process will then find it and include it in the compile process. When you use the "make" build process, you have to make sure that SSL is enabled there:

USE_SSL = 1

To install the OpenSSL library, you can do on most systems something like "sudo yum install openssl-dev" or "sudo apt-get install openssl-dev"

/Stefan

 

Hisataka YOSHIDA wrote:

Hello.

I installed the latest elog (3.1.4-2) in CentOS 7, and it is working well without SSL.
When I enalbled SSL option (SSL = 1) in the "elogd.cfg", and tried to start the elogd, the message below was shown and failed to run.

SSL support not compiled into elogd

If I switched the elog to older one (3.1.4-1), I could successeed to run the elogd with SSL option.
Is there any other option required in the latest elog to run with SSL? Or is this bug in the latest version?

Thank you,
Hisataka YOSHIDA

 

 

  69205   Wed Aug 26 20:41:50 2020 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux3.1.4-2Re: SSL does not work

Today I succeeded with the help of L.JR to produce a new RPM which contains SSL, KRB5, PAM and LDAP support. It's uploaded to https://elog.psi.ch/elog/download/RPMS/elog-3.1.4-2.el7.x86_64.rpm

Hisataka YOSHIDA wrote:

Dear Stefan,

Thank you for your comment. I successfuly compiled the latest elog from source code, and now elogd could work with SSL.

In fact, I reported the case of installation with rpm file. Maybe, the latest elog rpm doesn't support SSL, I guess.
The installtion with rpm file is easier to build the common environment, so I hope the next rpm will support the SSL.

best regards,
Hisataka YOSHIDA

Stefan Ritt wrote:

When you compile elog from the soruces, you need the OpenSSL library to be installed. The CMake build process will then find it and include it in the compile process. When you use the "make" build process, you have to make sure that SSL is enabled there:

USE_SSL = 1

To install the OpenSSL library, you can do on most systems something like "sudo yum install openssl-dev" or "sudo apt-get install openssl-dev"

/Stefan

 

Hisataka YOSHIDA wrote:

Hello.

I installed the latest elog (3.1.4-2) in CentOS 7, and it is working well without SSL.
When I enalbled SSL option (SSL = 1) in the "elogd.cfg", and tried to start the elogd, the message below was shown and failed to run.

SSL support not compiled into elogd

If I switched the elog to older one (3.1.4-1), I could successeed to run the elogd with SSL option.
Is there any other option required in the latest elog to run with SSL? Or is this bug in the latest version?

Thank you,
Hisataka YOSHIDA

 

 

 

ELOG V3.1.5-3fb85fa6