| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
1693
|
Tue Feb 14 17:43:15 2006 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | 2.6.1 | 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 |
|
1692
|
Tue Feb 14 16:22:56 2006 |
 | Steve Jones | steve.jones@freescale.com | Bug report | Other | 2.6.1 | CONCERN: Cross-platform compiling at risk | 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. |
|
1691
|
Tue Feb 14 16:06:28 2006 |
| Dimitrios Tsirigkas | dimitrios.tsirigkas@cern.ch | Question | Linux | 2.6.1 | Re: Accessing elog through two apache servers... | Hi,
The problem was coming from the fact that elog did not supports request coming from multiple hops through proxies. You got the ful string of them in the X-Forwarded-host header. Hence, you have to pick only the first one, terminated by a ','.
Here's the patch:
--- elogd-orig.c 2006-02-14 15:47:51.000000000 +0100
+++ elogd.c 2006-02-14 15:49:42.000000000 +0100
@@ -20985,6 +20985,8 @@
strcpy(str2, http_host);
if (strchr(str2, ':'))
*strchr(str2, ':') = 0;
+ if (strchr(str2, ','))
+ *strchr(str2, ',') = 0;
if (!strieq(str, str2)) {
redirect(lbs, _cmdline);
return FALSE;
Cheers
Eric and Dimitris |
|
1690
|
Tue Feb 14 14:23:04 2006 |
| Dimitrios Tsirigkas | dimitrios.tsirigkas@cern.ch | Question | Linux | 2.6.1 | Re: Accessing elog through two apache servers... | Hi Stefan,
| Stefan Ritt wrote: |
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/.
|
But my problem begins before I log in. Trying to load https://cmsdaq.cern.ch/elog/DAQ/?cmd=Login will get me in the infinite redirection directly. Besides, I do have URL = https://cmsdaq.cern.ch/elog/ in my configuration file, so the redirection should work in my case (since I'm trying to access it through cmsdaq) and fail in every other case. Is that right or is there something I'm missing?
Cheers,
Dimitris |
|
1689
|
Tue Feb 14 13:40:49 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.6.1 | 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 |
|
1688
|
Tue Feb 14 12:57:37 2006 |
 | Dimitrios Tsirigkas | dimitrios.tsirigkas@cern.ch | Question | Linux | 2.6.1 | Accessing 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 |
| Steve Jones | steve.jones@freescale.com | Question | Other | 2.6.1 | Re: 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 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Other | 2.6.1 | 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 |
|