Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 606 of 808  Not logged in ELOG logo
ID Datedown Icon Author Author Email Category OS ELOG Version Subject
  1688   Tue Feb 14 12:57:37 2006 Question Dimitrios Tsirigkasdimitrios.tsirigkas@cern.chQuestionLinux2.6.1Accessing elog through two apache servers...
Hello,

We have elogd running on a pc, say cmsdaqpreseries, that also runs an apache server and we've made sure that it's only accessible through the apache server, like so:

http://cmsdaqpreseries.cern.ch/elog/

This works fine.

We then tried to set up another apache server on another computer, say cmsdaq, and use that as a proxy server to access the apache server on cmsdaqpreseries and thus the elog (don't ask why...). Our sysadmin has set up kerberos authentication on that machine, so if I go to:

https://cmsdaq.cern.ch/elog/ (note the 's')

I am prompted for a username and password and then get the elog selection page. All seems to be working well, for example, the URL:

https://cmsdaq.cern.ch/elog/DAQ/?cmd=Find

will load properly. However, if I hit "login" (https://cmsdaq.cern.ch/elog/DAQ/?cmd=Login) I get caught in an infinite redirection. Of course:

http://cmsdaqpreseries.cern.ch/elog/DAQ/?cmd=Find

will still work! Any ideas on what we should do to set it up correctly? And why does this only happen with the login command?

Our sysadmin used ethereal to sniff the message exchange between the apache on cmsdaqpreseries and elog. I am including the details of the http request that elog likes (directly from cmsdaqpreseries) and of the one it doesn't like (from cmsdaqpreseries but originating at cmsdaq) as image attachments, as the text is not selectable (sorry).

Thanks in advance,

Dimitris
  1687   Mon Feb 13 18:22:08 2006 Reply Steve Jonessteve.jones@freescale.comQuestionOther2.6.1Re: compiling elog 2.6.1 on solaris platform

Stefan Ritt wrote:

Steve Jones wrote:
BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS.


Ok, what about adding:
ifeq ($(OSTYPE),SunOS)
OSTYPE=solaris
endif



Steve Jones wrote:

That would work, but my question is "why is this statement needed at all?" In GNU-land it appears that the make utilities use the canonical names rather than the ones returned by the OS. When I simply comment out this section, the solaris compile works fine. Perhaps it does not on other platforms?

Also, I ran into another snag. The include file "pty.h" does not appear to exist in solaris-land, so I am seeing if there is one made available elsewhere.
  1686   Fri Feb 10 22:35:20 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionOther2.6.1Re: compiling elog 2.6.1 on solaris platform

Steve Jones wrote:
BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS.


Ok, what about adding:
ifeq ($(OSTYPE),SunOS)
OSTYPE=solaris
endif
  1685   Fri Feb 10 22:31:38 2006 Reply Steve Jonessteve.jones@freescale.comQuestionOther2.6.1Re: compiling elog 2.6.1 on solaris platform

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:
Ok, I see what you did. I took a different route since I was not sure how the gnu linker would handle the fact that there would be two declarations of the forkpty() function when compiled and linked under Linux. Instead, I created a separate forkpty.c module and compiled it separately. Then, if "solaris", link it in. Otherwise, use library "util" which already has forkpty().

So, since it seems to work under Linux, any idea which function is being used?


No, there are no two forkpty() function, due to the
#ifdef OS_SOLARIS

  forkpty(...)
  {
    ...
  }

#endif

conditional compiling. So if I compile under Linux, the variable OS_SOLARIS is not defined, and therefore the special forkpty does not get compiled. Instead the one from the library is taken, since under Linux I use the -libutil switch. Under Solaris, there is no -libutil, but the OS_SOLARIS gets set, and therefore we have the code right inside elogd.c


Steve Jones wrote:

Got it. Much easier than how I was going about it.



BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS. When I run 'make -P' or 'gmake -P' the environment variable 'OSTYPE' is already set to 'solaris'. This is the reason the original Makefile did not work on our solaris systems. I'm not sure if this is universal but it applies to the systems we run (Solaris 8 and 9).
  1684   Fri Feb 10 21:52:35 2006 Reply Steve Jonessteve.jones@freescale.comQuestionOther2.6.1Re: compiling elog 2.6.1 on solaris platform

Stefan Ritt wrote:

Steve Jones wrote:
Ok, I see what you did. I took a different route since I was not sure how the gnu linker would handle the fact that there would be two declarations of the forkpty() function when compiled and linked under Linux. Instead, I created a separate forkpty.c module and compiled it separately. Then, if "solaris", link it in. Otherwise, use library "util" which already has forkpty().

So, since it seems to work under Linux, any idea which function is being used?


No, there are no two forkpty() function, due to the
#ifdef OS_SOLARIS

  forkpty(...)
  {
    ...
  }

#endif

conditional compiling. So if I compile under Linux, the variable OS_SOLARIS is not defined, and therefore the special forkpty does not get compiled. Instead the one from the library is taken, since under Linux I use the -libutil switch. Under Solaris, there is no -libutil, but the OS_SOLARIS gets set, and therefore we have the code right inside elogd.c


Steve Jones wrote:

Got it. Much easier than how I was going about it.

  1683   Fri Feb 10 21:50:27 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux Re: email problems

Chris Warner wrote:
Do you have an ise when that will be?


In about a week from now.
  1682   Fri Feb 10 21:26:33 2006 Question Chris Warnerchristopher_warner@dcd.uscourts.govQuestionLinux Re: email problems
Do you have an ise when that will be?


Stefan Ritt wrote:

Chris Warner wrote:
The email address id correct. I am using an Elog Binary. I don't have the source code.


Ok, so I removed the SIZE=xxx parameter, which is not strictly necessary anyhow I believe. So wait for the next release, and you can try.
  1681   Fri Feb 10 20:29:12 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionOther2.6.1Re: compiling elog 2.6.1 on solaris platform

Steve Jones wrote:
Ok, I see what you did. I took a different route since I was not sure how the gnu linker would handle the fact that there would be two declarations of the forkpty() function when compiled and linked under Linux. Instead, I created a separate forkpty.c module and compiled it separately. Then, if "solaris", link it in. Otherwise, use library "util" which already has forkpty().

So, since it seems to work under Linux, any idea which function is being used?


No, there are no two forkpty() function, due to the
#ifdef OS_SOLARIS

  forkpty(...)
  {
    ...
  }

#endif

conditional compiling. So if I compile under Linux, the variable OS_SOLARIS is not defined, and therefore the special forkpty does not get compiled. Instead the one from the library is taken, since under Linux I use the -libutil switch. Under Solaris, there is no -libutil, but the OS_SOLARIS gets set, and therefore we have the code right inside elogd.c
ELOG V3.1.5-3fb85fa6