Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 303 of 807  Not logged in ELOG logo
    icon2.gif   Re: Conditional attributes does not work in French, posted by Stefan Ritt on Thu Feb 3 16:48:41 2005 
> I am very much interested in using elog as a shift logbook for SOLEIL
> accelerators.

Hey, elog made it to SOLEIL! You know, we run it here at the SLS...

> I tested most of the options. Every thing works well except the conditional
> attributs when French language is selected. In this case, I lost the
> selected list option in the Field Equipement.

There was indeed a bug which only happend when switching to French! Some
javascript code contained

confirm('Erreur: l'attribute .... ')

So the "'" in l'attribute finished the string and Javascript stopped working. I
changed the quotes to

confirm("Erreur: l'attribute .... ")

so it works now. The new version is under CVS.

- Stefan
icon5.gif   ELOG Command Line Utility, posted by Tim Fowler on Wed Feb 9 15:40:12 2005 
I am trying to use the command line utility elog. Some of the attributes 
that I have setup are multiple options. When I run the command line 
utility to create a new message, any attribute that is setup with multiple 
options will not be filled in. The syntax I am using is as  follows:

elog -h localhost -p 8080 -l Lab -a "Site=xxxx" -a "Area=System" -
a "Priority=Low" -a "Shift=1" -a "Status=Open" -m text.txt

Site and Area are defined in the config file as MOptions. Is there a way 
to use this feature with multiple options on attributes with the 
attributes = to one or more variables?
    icon2.gif   Re: ELOG Command Line Utility, posted by Stefan Ritt on Sun Feb 13 17:21:19 2005 
> I am trying to use the command line utility elog. Some of the attributes 
> that I have setup are multiple options. When I run the command line 
> utility to create a new message, any attribute that is setup with multiple 
> options will not be filled in. The syntax I am using is as  follows:
> 
> elog -h localhost -p 8080 -l Lab -a "Site=xxxx" -a "Area=System" -
> a "Priority=Low" -a "Shift=1" -a "Status=Open" -m text.txt
> 
> Site and Area are defined in the config file as MOptions. Is there a way 
> to use this feature with multiple options on attributes with the 
> attributes = to one or more variables?

For MOptions, you have to append an "_n" to each attribute to distinguish
different options for the same attribute, like

elog -h localhost -p 8080 -l Lab -a "Site_0=Home" -a "Site_1=Work" ...

Even if you only use one attribute, the trailing "..._0" is necessary. I will
add a note to the documentation.
icon4.gif   ELOG security vulnerability fixed, IMPORTANT!!!!, posted by Stefan Ritt on Mon Feb 14 12:36:30 2005 
Dear ELOG users,

It has been brought to my attention that ELOG has a vulnerability through
which one can obtain a remote shell (meaning to log in to your machine
through elog). There is even an exploit available which demonstrates that
both for linux and windows.

This is a severe security problem for all logooks which can be seen from
outside, even if they have password protection on. I strongly recommened to
upgrade to elog version 2.5.7 as soon as possible if you run a public elog
server.

Here is some explanation for the technically interested:

The problem arises from a strcpy() in the decode_post() routine, which
triggers a buffer overflow when attachment file names longer than 256
characters are submitted. I replaced (hopefully) all strcpy() with strlcpy()
to fix this problem, but if someone sees a location which I have missed,
please tell me.

The second vulnerability had to do with write passwords. If you put a "write
password = xxx" statement into your config file, it was still possible to
download the config file with a special hand-written URL, and decode the
write password, which is usually only base-64 encoded unless you haven't
compiled elog with the -DHAVE_CRYPT flag. I have changed that so if a write
password is present, the download is only possible when this password is
submitted in each request. If this has some effects on synchronizing of
logbooks, please let me know.

Stefan Ritt
    icon2.gif   Re: Response is very slow with beta3, posted by Emiliano Gabrielli on Wed Aug 3 13:01:17 2005 

PJ Meyer wrote:
I finally got 2.60 Beta3 running on my server (explicit statements in cfg for most of the defaults)

Now I'm seeing a veerrry slooooow response time - over 3 minutes to open a logbook vs 10 sec in 2.54
Utilization of CPU runs to 60% on elogd.

Tried slimning down elog.cfg, 'emptying' userlog file (actually renamed so Elog created a new one).

Still 2.60b3 is very slow to respond.

When I rolled back to 2.54 speed was fast again.

Any ideas?

this is on a dual processor Win2000 server with 2 gb memory.

attached is the elog.cfg if that helps.

i'm stumped

7/28 Follow-up testing and trials

When I stopped using a password file - speed was quick and responsive (on test book with no password file speed was good which got me thinking about the password file)
When I added back in the 'old' xml password file - slow response
I created new password file with only one user - slow response (took almost 3 minutes to save new account)

I've attached the password file so you can try it out if yo want....

This has me very stumped.



I can confirm .. it's very very slow for me too:

munmap(0xb7db4000, 4096)                = 0
select(1024, [5], NULL, NULL, {6, 0})   = 1 (in [5], left {5, 996000})
recv(5, "GET /calendar_filter/imgs/window"..., 100000, 0) = 485
open("/usr/share/elog/scripts/calendar_filter/imgs/window_close.gif", O_RDONLY) = 6
close(6)                                = 0
open("/usr/share/elog/scripts/calendar_filter/imgs/window_close.gif", O_RDONLY) = 6
lseek(6, 0, SEEK_END)                   = 648
lseek(6, 0, SEEK_CUR)                   = 648
lseek(6, 0, SEEK_SET)                   = 0
time([1123066183])                      = 1123066183
read(6, "GIF89a\20\0\20\0\306`\0\16\26 \r\27!\16\30!\24 .\25 .I"..., 648) = 648
close(6)                                = 0
send(5, "HTTP/1.1 200 Document follows\r\nS"..., 879, 0) = 879
close(5)                                = 0
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 0 (Timeout)
select(1024, [3], NULL, NULL, {1, 0})   = 1 (in [3], left {0, 81000})
accept(3, {sa_family=AF_INET, sin_port=htons(57723), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
time(NULL)                              = 1123066193
socket(PF_FILE, SOCK_STREAM, 0)         = 6
connect(6, {sa_family=AF_FILE, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No such file or directory)
close(6)  
= 0


for every image elog has to serve one can see something similar to the above ... lot of time lost in selects.. then a lot of data (serving an image I suppose), then a lot of time in select again and again ... untill everything is sent, in a couple of minutes or more Crying


Maybe an issue related to the dns search you introduced in order to guess the correct host name ?? ..
    icon2.gif   Re: Response is very slow with beta3, posted by Stefan Ritt on Wed Aug 3 22:44:43 2005 

Emiliano Gabrielli wrote:
for every image elog has to serve one can see something similar to the above ... lot of time lost in selects.. then a lot of data (serving an image I suppose), then a lot of time in select again and again ... untill everything is sent, in a couple of minutes or more Crying


Maybe an issue related to the dns search you introduced in order to guess the correct host name ?? ..


This is strange to me, since I did not change anything which could slow down the server this much. The dns search your mentioned is only evaluated once on startup of elogd, so it cannot be the cause. The select() statements with Timeouts are normal. If there is no HTTP request (elogd is idling), the select should time out after one second, to be able to check a changed config file for example. If a HTTP request arrives, the select() call is immediately terminated and the request served.

There is however some problem with DNS server which I saw on midas.psi.ch. If the DNS host name resolution is slow due to a slow DNS server, this could slow down elogd considerably significantly, but only occasionally. I saw elogd hanging on midas.psi.ch like once or twice a day for ~30 seconds.

I order to address this problem, I imlemented a global flag "resolve host names = 0|1". The default is "0", which means that elogd does not contact the DNS server, and rather save the raw IP address in log files etc.

Can you check the CVS version and see if it makes any difference?
    icon2.gif   Re: Response is very slow with beta3, posted by Emiliano Gabrielli on Thu Aug 4 11:19:53 2005 

Stefan Ritt wrote:

Emiliano Gabrielli wrote:
for every image elog has to serve one can see something similar to the above ... lot of time lost in selects.. then a lot of data (serving an image I suppose), then a lot of time in select again and again ... untill everything is sent, in a couple of minutes or more Crying


Maybe an issue related to the dns search you introduced in order to guess the correct host name ?? ..


This is strange to me, since I did not change anything which could slow down the server this much. The dns search your mentioned is only evaluated once on startup of elogd, so it cannot be the cause. The select() statements with Timeouts are normal. If there is no HTTP request (elogd is idling), the select should time out after one second, to be able to check a changed config file for example. If a HTTP request arrives, the select() call is immediately terminated and the request served.

There is however some problem with DNS server which I saw on midas.psi.ch. If the DNS host name resolution is slow due to a slow DNS server, this could slow down elogd considerably significantly, but only occasionally. I saw elogd hanging on midas.psi.ch like once or twice a day for ~30 seconds.

I order to address this problem, I imlemented a global flag "resolve host names = 0|1". The default is "0", which means that elogd does not contact the DNS server, and rather save the raw IP address in log files etc.

Can you check the CVS version and see if it makes any difference?


No, ok it appears to be a very strange problem related to my JS calendar filter ... I'll change it's state to beta in contributions, but the very strange thing is that it works fine when no stunnel is used ...
icon8.gif   Post appearing twice, posted by Dan Chitwood on Fri Sep 23 19:23:26 2005 
We are having trouble on our logbook with posts appearing twice. Both posts contain the same ID number, time, etc. This most often occurs when the e-log entry is being written for an extended period of time (ie. more than 30 minutes), but I don't know if that is the root cause of the problem. It may also be related to posts that are edited after an initial posting. Could this be due to an improper setting in our config file?
ELOG V3.1.5-3fb85fa6