ELOG Forum

Demo Discussion

Forum Config Examples Contributions Vulnerabilities

Discussion forum about ELOG, Page 180 of 238

Not logged in

Find | Login | Help

Full | Summary | Threaded | Collapse | Expand

1898 Entries

Goto page Previous 1, 2, 3 ... 179, 180, 181 ... 236, 237, 238 Next

List view for CHANGE attributes, posted by Holger Mundhahs on Wed Feb 22 13:49:03 2006

Hello @all,
I've tried to implement an attribute with Change. The detail view works well,
but in the list view the field is empty (see screen shots). Can somebody help me?
Regards
Holger

LOGBOOK CONFIGURATION:
Comment = DEMO
Attributes = Admin, Hostname, IP-Adresse, Funktion, RIB-Hostname, RIB-IP, RIB-Admin
Change RIB-Admin = <a href="https://$RIB-Hostname/" target="_new">$Hostname RIB-Board: $RIB-Hostname</a>

Preset Admin = DEMO
Locked Attributes = Admin, RIB-Admin
Display search = ID, Date, Admin, Hostname, RIB-Admin
List Display = ID, Edit, Date, Admin, Hostname, IP-Adresse, RIB-Admin
Link Display = ID

Page Title = ELOG - $subject
Quick filter = Date, Admin
Default encoding = 1
Suppress default = 3
Show text = 0
Summary lines = 0
Sort Attributes = IP-Adresse

Re: List view for CHANGE attributes, posted by Stefan Ritt on Wed Feb 22 13:55:08 2006

> Hello @all,
> I've tried to implement an attribute with Change. The detail view works well,
> but in the list view the field is empty (see screen shots). Can somebody help me?

For the list view, you need an additional

List Change RIB-Admin = ...

Some people want different modes for the list view and the detail view, that's why there are two options.

Re: List view for CHANGE attributes, posted by Holger Mundhahs on Wed Feb 22 15:47:45 2006

Hello Mr. Ritt,

6 min 5 sek to answer - great. Big grin

Thanks & regards
Holger

Stefan Ritt wrote:

svn revision number in the source, posted by Steve Jones on Tue Feb 21 19:25:28 2006

There is a variable $Id$ in source that looks like it is supposed to reflect the svn revision number of the compiled code. How is this supposed to be set, manually just before compiling?

Thanks!

Re: svn revision number in the source, posted by Stefan Ritt on Tue Feb 21 20:24:18 2006

Steve Jones wrote:

There is a variable $Id$ in source that looks like it is supposed to reflect the svn revision number of the compiled code. How is this supposed to be set, manually just before compiling?

It gets set automatically on every commit to the Subversion repository.

Re: svn revision number in the source, posted by Steve Jones on Tue Feb 21 21:01:22 2006

Stefan Ritt wrote:

Steve Jones wrote:

There is a variable $Id$ in source that looks like it is supposed to reflect the svn revision number of the compiled code. How is this supposed to be set, manually just before compiling?

It gets set automatically on every commit to the Subversion repository.

So, when we go to the download section and download directly from there, that is not "committed" source? I ask because the revision id there is not set to anything that I can see.

Re: svn revision number in the source, posted by Stefan Ritt on Tue Feb 21 21:17:13 2006

Steve Jones wrote:

So, when we go to the download section and download directly from there, that is not "committed" source? I ask because the revision id there is not set to anything that I can see.

Can you be a bit more specific? What do you download? The Windows binaries, the Linux RPM? Or from the Subversion repository? The current version in the repository, which you can download here, contains in the file elogd.c following line 8:

   $Id: elogd.c 1660 2006-02-17 19:48:12Z ritt $

This tells you that this is revision 1660, committed on Feb. 17 by myself. So what is the problem?

Re: svn revision number in the source, posted by Steve Jones on Tue Feb 21 21:58:16 2006

Stefan Ritt wrote:

Steve Jones wrote:

So, when we go to the download section and download directly from there, that is not "committed" source? I ask because the revision id there is not set to anything that I can see.

   $Id: elogd.c 1660 2006-02-17 19:48:12Z ritt $

This tells you that this is revision 1660, committed on Feb. 17 by myself. So what is the problem?

Steve Jones wrote:

Ok, this is really strange but just an hour ago I clicked on the http://midas.psi.ch/elog/download.html link and I was taken to a completely different webview - in fact, I am quite sure that at the bottom right corner it said "WebCVS"! Now, it says WebSVN and the revision info is in there. I've been trying to debug a problem with default.css and the elcode icons - and somewhere in there I cleared my firefox cache. Perhaps an old page was cached????

I have no idea how I got to CVS, and it make sense that CVS was not setting the SVN revision code.
Sorry to botter you on this.

Re: svn revision number in the source, posted by Steve Jones on Tue Feb 21 22:13:40 2006

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:

So, when we go to the download section and download directly from there, that is not "committed" source? I ask because the revision id there is not set to anything that I can see.

   $Id: elogd.c 1660 2006-02-17 19:48:12Z ritt $

This tells you that this is revision 1660, committed on Feb. 17 by myself. So what is the problem?

Steve Jones wrote:

I just downloaded the tarball from SVN and the revision numbers are set correctly, as you said. I'm stumped as to how I got to CVS. I am running into issues that are related to the stylesheet properties, but that is for a different entry.

Thanks!

Re: svn revision number in the source, posted by Stefan Ritt on Tue Feb 21 22:33:32 2006

Steve Jones wrote:

I have no idea how I got to CVS

I realized that I had an old link to CVS when I checked your previous posting, so I updated that link like 30 min ago. That's why you got a new one.

Re: svn revision number in the source, posted by Steve Jones on Tue Feb 21 22:37:14 2006

Stefan Ritt wrote:

Steve Jones wrote:

I have no idea how I got to CVS

I realized that I had an old link to CVS when I checked your previous posting, so I updated that link like 30 min ago. That's why you got a new one.

Ah, thanks. All is now right with the world Big grin

compiling elog 2.6.1 on solaris platform, posted by Angus Au on Thu Feb 2 03:19:44 2006

I came across problem in compiling elog 2.6.1 on solaris platform.

The messages "

# make
gcc -o elog src/elog.c -lutil -lsocket -lnsl
ld: fatal: library -lutil: not found
ld: fatal: File processing errors. No output written to elog
collect2: ld returned 1 exit status
*** Error code 1
make: Fatal error: Command failed for target `elog'

It seems to me that library libutil does not exist on solaris platform.

Is there any fix ? I can compile elog 2.6.0 successfully on solaris.

Re: compiling elog 2.6.1 on solaris platform, posted by Willem Koster on Fri Feb 3 13:10:14 2006

[quote="Angus Au"]I came across problem in compiling elog 2.6.1 on solaris platform.

Is there any fix ? I can compile elog 2.6.0 successfully on solaris.[/quote]

There is a fix, we have 2.6.1 running on Solaris.

A colleague of me installed it and did mention something about having to go through the source and adapting the 
makefile. I didn't hear him speak of missing libraries though, I will ask him next week.

Re: compiling elog 2.6.1 on solaris platform, posted by Stefan Ritt on Mon Feb 6 08:27:40 2006

Angus Au wrote:

ld: fatal: library -lutil: not found

The util library was added recently because of the new shell substitution functionaly, which requires the forkpty() function call. If you know in which library the forkpty is available on solaris, the makefile could be adjusted accordingly. If the forkpty is not available at all, we have to disable the shell substitution under solaris via conditional compilation.

Re: compiling elog 2.6.1 on solaris platform, posted by Steve Jones on Mon Feb 6 16:44:46 2006

Stefan Ritt wrote:

Angus Au wrote:

ld: fatal: library -lutil: not found

Steve Jones wrote:

I have checked and can find no reference within Sun documents regarding the support of the forkpty() function. I have not been following elog development lately -- what is shell substitution supposed to buy us?

-- Ah, just looked at the docs, I see what that buys us. Surely there is a similar function available that is cross platform?

Re: compiling elog 2.6.1 on solaris platform, posted by Stefan Ritt on Mon Feb 6 16:48:17 2006

Steve Jones wrote:

See the config manual and look for $shell

Re: compiling elog 2.6.1 on solaris platform, posted by Steve Jones on Wed Feb 8 18:19:02 2006

Stefan Ritt wrote:

Steve Jones wrote:

See the config manual and look for $shell

Steve Jones wrote:

Yep, I saw it. Thanks

Re: compiling elog 2.6.1 on solaris platform, posted by Steve Jones on Wed Feb 8 18:34:43 2006

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:

See the config manual and look for $shell

Steve Jones wrote:

Yep, I saw it. Thanks

Steve Jones wrote:

Stefan, I found the following "forkpty()" replacement for running under Solaris. The URL is http://www.developerweb.net/forum/showthread.php?t=2990.

Perhaps this can be used unless someone comes up with a Solaris "util" library.

#ifdef SOLARIS /* Use the code in my_forkpty.c */
int my_forkpty (int *amaster, char *name, void *unused1, void *unused2);
#define forkpty my_forkpty
#endif
-----------------------
my_forkpty.c
-----------------------
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/ioctl.h>
#include <sys/stream.h>
#include <sys/stropts.h>

/* fork_pty() remplacement for Solaris.
* This ignore the last two arguments
* for the moment
*/
int
my_forkpty (int *amaster,
char *name,
void *unused1,
void *unused2)
{
int master, slave;
char *slave_name;
pid_t pid;

master = open("/dev/ptmx", O_RDWR);
if (master < 0)
return -1;

if (grantpt (master) < 0)
{
close (master);
return -1;
}

if (unlockpt (master) < 0)
{
close (master);
return -1;
}

slave_name = ptsname (master);
if (slave_name == NULL)
{
close (master);
return -1;
}

slave = open (slave_name, O_RDWR);
if (slave < 0)
{
close (master);
return -1;
}

if (ioctl (slave, I_PUSH, "ptem") < 0
|| ioctl (slave, I_PUSH, "ldterm") < 0)
{
close (slave);
close (master);
return -1;
}

if (amaster)
*amaster = master;

if (name)
strcpy (name, slave_name);

pid = fork ();
switch (pid)
{
case -1: /* Error */
return -1;
case 0: /* Child */
close (master);
dup2 (slave, STDIN_FILENO);
dup2 (slave, STDOUT_FILENO);
dup2 (slave, STDERR_FILENO);
return 0;
default: /* Parent */
close (slave);
return pid;
}

return -1;
}

Re: compiling elog 2.6.1 on solaris platform, posted by Stefan Ritt on Fri Feb 10 13:58:17 2006

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

Re: compiling elog 2.6.1 on solaris platform, posted by Steve Jones on Fri Feb 10 17:22:36 2006

Stefan Ritt wrote:

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

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?

Re: compiling elog 2.6.1 on solaris platform, posted by Stefan Ritt on Fri Feb 10 17:29:03 2006

Steve Jones wrote:

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.

Re: compiling elog 2.6.1 on solaris platform, posted by Steve Jones on Fri Feb 10 20:24:56 2006

Stefan Ritt wrote:

Steve Jones wrote:

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.

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?

Re: compiling elog 2.6.1 on solaris platform, posted by Stefan Ritt on Fri Feb 10 20:29:12 2006

Steve Jones wrote:

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

Re: compiling elog 2.6.1 on solaris platform, posted by Steve Jones on Fri Feb 10 21:52:35 2006

Stefan Ritt wrote:

Steve Jones wrote:

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

#ifdef OS_SOLARIS

  forkpty(...)
  {
    ...
  }

#endif

Steve Jones wrote:

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

Re: compiling elog 2.6.1 on solaris platform, posted by Steve Jones on Fri Feb 10 22:31:38 2006

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:

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

#ifdef OS_SOLARIS

  forkpty(...)
  {
    ...
  }

#endif

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).

Re: compiling elog 2.6.1 on solaris platform, posted by Stefan Ritt on Fri Feb 10 22:35:20 2006

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

Re: compiling elog 2.6.1 on solaris platform, posted by Steve Jones on Mon Feb 13 18:22:08 2006

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.

Re: compiling elog 2.6.1 on solaris platform, posted by Steve Jones on Mon Feb 20 17:52:06 2006

Steve Jones wrote:

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:

In working with Stefan changes were made so that the latest release should once again cross-compile fine, and Makefile also works under Solaris. Great job Stefan!

CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Tue Feb 14 16:22:56 2006

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.

Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Tue Feb 14 17:43:15 2006

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()

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

Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Tue Feb 14 22:31:08 2006

Steve Jones wrote:

Stefan Ritt wrote:

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()

Stefan et al.

I think it would be preferrable if we could find a routine that performed the same function but that was available under Windows/Linux/Unix. Question: Is the functionality really just to issue an arbitrary command-string to a "shell" and have the result stuffed back into an eLog variable? I'm not an expert but it would seem that such a feature would be universally available or could be used to construct a suitable routine.

If possible, could one use the

int system(const char *s);

function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps

char *tmpnam(char *s);

, running a command via

int system(const char *s);

, then opening that file for a read would accomplish what is being desired?

Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Wed Feb 15 18:25:15 2006

Steve Jones wrote:

Question: Is the functionality really just to issue an arbitrary command-string to a "shell" and have the result stuffed back into an eLog variable? I'm not an expert but it would seem that such a feature would be universally available or could be used to construct a suitable routine.

If possible, could one use the

int system(const char *s);

function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps

char *tmpnam(char *s);

, running a command via

int system(const char *s);

, then opening that file for a read would accomplish what is being desired?

Indeed the results from the "shell" need to be stuffed back into an elog attribute, that's why you cannot use the system() function directly. The idea with the tmpnam() could however be a clever workaround. I have to see if this works under Windows. If so, it would be a much more portable alternative to forkpty().

Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Wed Feb 15 19:02:32 2006

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:

int system(const char *s);

function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps

char *tmpnam(char *s);

, running a command via

int system(const char *s);

, then opening that file for a read would accomplish what is being desired?

Yes, these routines are from the standard C libraries. tmpname() returns a pointer to a filename guaranteed to be unique, then you can create that file. tmpfile() actually creates a temporary file and returns a pointer to the filestream, and auto cleans up upon stream termination. system() passes the command string to the shell/commandproc if available. You could wrap these into a single callable function that is called 'shell()' and accomplish your first gola plus achieve cross-platformness again ;->

My 2 cents - hope that is enough!

Re: CONCERN: Cross-platform compiling at risk, posted by Stefan Ritt on Fri Feb 17 13:31:00 2006

Steve Jones wrote:

If possible, could one use the

int system(const char *s);

function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps

char *tmpnam(char *s);

, running a command via

int system(const char *s);

, then opening that file for a read would accomplish what is being desired?

I implemented exprimentally such a code. Instead of tmpnam() (which the compiler claims to be obsolete), I use a hard-wired file name /tmp/elog-shell for that purpose. I put it under /tmp so that the "elog" user (under which elog should normally run) is able to write to. Can you please check if that works fine now under Solaris?

Re: CONCERN: Cross-platform compiling at risk, posted by Steve Jones on Mon Feb 20 17:50:33 2006

Stefan Ritt wrote:

Steve Jones wrote:

If possible, could one use the

int system(const char *s);

function in conjunction with a filei/o function as the means for getting the results of a system call back into a var. Perhaps

char *tmpnam(char *s);

, running a command via

int system(const char *s);

, then opening that file for a read would accomplish what is being desired?

The compiled version runs fine under Solaris9. When executing Subst Subject = $shell(uname) I got:

"SunOS" !!! ;->

So, short of the items I pointed out below I would say that you have successfully re-rendered eLog as a truly cross platform application once again! My hat is off to you!

thanks

Steve

Accessing elog through two apache servers..., posted by Dimitrios Tsirigkas on Tue Feb 14 12:57:37 2006

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

Re: Accessing elog through two apache servers..., posted by Stefan Ritt on Tue Feb 14 13:40:49 2006

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

Re: Accessing elog through two apache servers..., posted by Dimitrios Tsirigkas on Tue Feb 14 14:23:04 2006

Hi Stefan,

Stefan Ritt wrote:

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

Re: Accessing elog through two apache servers..., posted by Dimitrios Tsirigkas on Tue Feb 14 16:06:28 2006

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

Re: Accessing elog through two apache servers..., posted by Stefan Ritt on Wed Feb 15 18:13:25 2006

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

email problems, posted by Chris Warner on Tue Feb 7 21:02:22 2006

When I select to get email notification on new logbook entries I receive this error when entering a new record.

Error sending Email via "xxx.xxx.xxx.xx": Syntax error, parameters in command "MAIL FROM: christopher_warner@xxx.gov SIZE=1985" unrecognized or missing

The user that sent the message was a test account that I set up. I entered the email address in the box provided and I am not sure what may be causing the difficulty.

Any thoughts as to what may be causing this?

Re: email problems, posted by Stefan Ritt on Wed Feb 8 15:29:03 2006

Chris Warner wrote:

Error sending Email via "xxx.xxx.xxx.xx": Syntax error, parameters in command "MAIL FROM: christopher_warner@xxx.gov SIZE=1985" unrecognized or missing

There are two possible reasons:

1) The email address "christopher_warner@xxx.gov" is invalid. Some SMTP server immediately complain about invalid email addresses and refuse to send any mail then. In that case just supply an existing email address or remove that test account.

2) The SMTP server does not like the "SIZE=xxx" option. This comes from a single line in elogd.c:

snprintf(str, strsize - 1, "MAIL FROM: %s SIZE=%d\r\n", from, strlen(text));

you could just go there and remove the " SIZE=%d", so that the line looks like:

snprintf(str, strsize - 1, "MAIL FROM: %s\r\n", from);

to see if that makes any difference.

Re: email problems, posted by Chris Warner on Wed Feb 8 18:38:30 2006

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

Chris Warner

Stefan Ritt wrote:

Chris Warner wrote:

Error sending Email via "xxx.xxx.xxx.xx": Syntax error, parameters in command "MAIL FROM: christopher_warner@xxx.gov SIZE=1985" unrecognized or missing

snprintf(str, strsize - 1, "MAIL FROM: %s SIZE=%d\r\n", from, strlen(text));

you could just go there and remove the " SIZE=%d", so that the line looks like:

snprintf(str, strsize - 1, "MAIL FROM: %s\r\n", from);

to see if that makes any difference.

Re: email problems, posted by Stefan Ritt on Thu Feb 9 09:09:30 2006

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.

Re: email problems, posted by Chris Warner on Fri Feb 10 21:26:33 2006

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.

Re: email problems, posted by Stefan Ritt on 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.

Posting without logging in!, posted by Dimitrios Tsirigkas on Thu Feb 9 14:15:54 2006

Hi all! This is an HTTP POST request submitted from the command line using curl, and providing no authentication information. If I can post as myself using this command, then shouldn't something be done about this? Cheers, Dimitris

Re: Posting without logging in!, posted by Stefan Ritt on Fri Feb 10 11:41:38 2006

Dimitris wrote:

Hi all! This is an HTTP POST request submitted from the command line using curl, and providing no authentication information. If I can post as myself using this command, then shouldn't something be done about this?

Yes indeed. I fixed that in SVN revision 1655. I upgraded this server so you can try again if it works.

Re: Posting without logging in!, posted by Dimitrios Tsirigkas on Fri Feb 10 16:16:11 2006

Stefan Ritt wrote:

Yes indeed. I fixed that in SVN revision 1655. I upgraded this server so you can try again if it works.

Just tried it, it's fixed Smile

Dimitris

Work on PAM Support?, posted by Steve Jones on Wed Feb 8 18:23:52 2006

Stefan (or any others):

Has anyone been seriously looking into building in PAM support in eLog? I ask because I have started reading the developer papers from Sun and looking at sample code.

Thanks

Steve

Re: Work on PAM Support?, posted by Stefan Ritt on Thu Feb 9 09:12:44 2006

Steve Jones wrote:

Has anyone been seriously looking into building in PAM support in eLog? I ask because I have started reading the developer papers from Sun and looking at sample code.

Not really. I have two big issues higher on my list: XML database format and multithreaded HTTP server. From having a quick look to PAM, I was not sure how easy this would be to implement. If it's not too difficult, it could move higher in the priority list.

Re: Work on PAM Support?, posted by Steve Jones on Thu Feb 9 19:51:26 2006

Stefan Ritt wrote:

Steve Jones wrote:

Has anyone been seriously looking into building in PAM support in eLog? I ask because I have started reading the developer papers from Sun and looking at sample code.

Tell you what, I'm looking at two items related to eLog -- tell me to stop if you want:

forkpty() emulation for Solaris
PAM support

I'm furthur ahead on the forkpty() - just trying to figure out exactly where to place the code. Once I know it works then I can give it to you to incorporate. Unless you want what I have now and you can work on it.

I've also got quite a bit of reference code for PAM support. A little more daunting.

Goto page Previous 1, 2, 3 ... 179, 180, 181 ... 236, 237, 238 Next

ELOG V3.1.5-3fb85fa6