ELOG Forum

Demo Discussion

Forum Config Examples Contributions Vulnerabilities

Discussion forum about ELOG, Page 214 of 801

Not logged in

Find | Login | Help

Full | Summary | Threaded | Show attachments

6408 Entries

Goto page Previous 1, 2, 3 ... 213, 214, 215 ... 799, 800, 801 Next

Fri Feb 10 13:58:17 2006

Re: compiling elog 2.6.1 on solaris platform

Steve Jones wrote:

Stefan, I found the following "forkpty()" replacement for running under Solaris.

Ok, I put your code into the current SVN revision (1656). Unfortunately I cannot try it due to the lack of a Sun. Maybe you can try and tell me if it's working.

- Stefan

1679

Fri Feb 10 17:29:03 2006

Re: compiling elog 2.6.1 on solaris platform

Steve Jones wrote:

Actually, what I will be delivering is a new Makefile with conditional compile statements plus the C code module since the example that I provided need some cleaning. Since I don't have a Linux system on which to test the conditional compile completely I would need you to do that. Sound ok?

Sure. I put already the conditional compiling into the current Makefile, so just try it. I tested the Linux part, which is ok. If you could test the Solaris part, that would be great.

1681

Fri Feb 10 20:29:12 2006

Re: 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

1683

Fri Feb 10 21:50:27 2006

Chris Warner wrote:

Do you have an ise when that will be?

In about a week from now.

1686

Fri Feb 10 22:35:20 2006

Re: 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

1689

Tue Feb 14 13:40:49 2006

Re: Accessing elog through two apache servers...

Hi Dimitrios,

I know where your problem is and you could actually help me in solving it. The reason of the problem is the redirection. After you login, you get redirected (via the HTTP "Location:" statement) to the start page. In an very old version of ELOG, I had relative redirection. So from https://cmsdaq.cern.ch/elog/DAQ/?cmd=Login I did a redirect to "." and voila I the browser asked for https://cmsdaq.cern.ch/elog/DAQ/. In meantime I learned that relative redirects are not allowed. Actually the Safari Browser on the MAC complains and does not support this. So my problem is not how to derive the URL for the redirection.

The standard way is the URL = ... option in the config file. So ELOG takes this URL, and adds the remainder if needed (like the entry ID after a submit, so to go to .../DAQ/123 for example). While this works fine if you only access ELOG through that URL, it breaks if you access if from different locations. Other people at BNL have the problem that they access ELOG through a ssh tunnel, so the browser URL is then http://localhost:1234 which is the local end of the tunnel. Since the redirection uses then the Apache URL, they have the same problem.

Now the big question is how to derive the URL dynamically. From your Ethereal dumps you see that there is the Referer: statement which would be one option. Actually if you install "Tamper Data", which is a Firefox extension, you can monitor the HTTP traffic much easier inside your browser than with Ethereal. The problem with this is that if you bookmark a ELOG page directly in the browser, the first access to that page does not contain any Referer: statement. The other options are the Host: or the X-Forwarded-Host: statements. The problem is that they do not contain any subdirectory, like your /DAQ/ in the example above. Furthermore, if you access ELOG through Apache and through an ssh tunnel directly for example, one URL does have the Apache subdirectory and the other has none.

So from the setup you have right now, can you derive a set of rules how to compose the forward URL from the items in the HTTP header? If you succeed, I'm happy to implement this into the next version of ELOG.

Best regards,

Stefan

1693

Tue Feb 14 17:43:15 2006

Re: CONCERN: Cross-platform compiling at risk

Steve Jones wrote:

Stefan, I am concerned that there are becoming too many Linux dependencies in terms of required libraries and header files. Although we have a replacement for the

forkpty()

routine, I am running into many other dependencies, the latest of which is pty.h. Aren't there guidelines in GCC that point out what is available cross-platform and what is not? For example, any SVR# (System Five, Release XX) based Unix will not include the forkpty() function, but BSD derivatives will.

Currently we are stuck at eLog 2.5.9 because of this issue.

The whole issue with the forkpty() came from the request of the shell subsitution. I managed to compile this under Linux and under Windows, so I was under the impression that this is not too specific (although I had to use completely different approaches for Linux and Windows). Now if you tell me that this is not true, we have basically two options:

1) Make the shell substitution an option. On systems which don't have a forkpty(), don't compile it in. I guess not many people need the shell substitution. Thos people who need it have to stick to certain Unix flavours.

2) Find equivalents of forkpty() on all systems. The problem with that is that I have to rely on others like you to supply me some code for other systems and test it.

Please let me know what option you prefer. Also other users are asked for their opinion.

Best regards,

Stefan

1695

Wed Feb 15 18:13:25 2006

Re: Accessing elog through two apache servers...

Thanks for the patch, I committed it to Subversion Revision #1657.

Goto page Previous 1, 2, 3 ... 213, 214, 215 ... 799, 800, 801 Next

ELOG V3.1.5-3fb85fa6