Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 779 of 808  Not logged in ELOG logo
ID Date Icon Author Author Emaildown Category OS ELOG Version Subject
  1321   Tue Jul 26 10:00:34 2005 Entry Emiliano GabrielliAlberT@SuperAlberT.itQuestionLinux2.6.0bRe: Can't set Author attribute properly in reply?

Chris Green wrote:
Hi,

I have two problems:

1) With the configuration below, I can't set the Author attribute to be the author of the reply. As written, it gives the Author field as blank. If the Remove on Reply line is removed, it is set to the parent's author. What am I doing wrong?

Subst on reply Author = $long_name
  1323   Tue Jul 26 10:45:14 2005 Reply Emiliano GabrielliAlberT@SuperAlberT.itRequestAll Re: <img> in Display Attribute

Stefan Ritt wrote:

Emiliano Gabrielli wrote:
donno if a "List Display <Attribute>" could be *the* solution ...


That's a good idea. Unfortunately, "List Display" is already used to specify which attributes to display in list mode. So I changed "Display <attibute>" to "Change <attribute>" and added "List change <attribute>", just to be different from "List display". In principle "List display =" and "List display <attibute> =" can be distinguished by elog, but it could be confusing to have the same option for two different things. The downside is that everybody using "Display <attribute>=" has to change this to "Change <attribute>=".


It works perfectly now Smile thank you Stefan
  1324   Tue Jul 26 10:49:12 2005 Entry Emiliano GabrielliAlberT@SuperAlberT.itQuestionLinux2.6.0bRe: Can't set Author attribute properly in reply?

Stefan Ritt wrote:

Chris Green wrote:
1) With the configuration below, I can't set the Author attribute to be the author of the reply. As written, it gives the Author field as blank. If the Remove on Reply line is removed, it is set to the parent's author. What am I doing wrong?


Hey, elog made it to MiniBooNE! I'm working on MEG...

What you need is the following:
Preset on reply subject = Re: $subject
Preset Author = $long_name
Preset on Reply Author = $long_name
Locked Attributes = Author

The Subst statements work after the entry gets submitted, while the preset statements work before. So Preset on Reply <attribute> is what you need.


Depending of what your paranoia level is Smile
Substitute is the only way I have to be assure it is as I want ... yes, in real life nobody of my users will never try to change the generated HTML ad replace by hand the Author, but ... Tongue
  1326   Tue Jul 26 10:55:03 2005 Reply Emiliano GabrielliAlberT@SuperAlberT.itQuestionLinux2.6.0bRe: Can't set Author attribute properly in reply?

Stefan Ritt wrote:

Emiliano Gabrielli wrote:
Substitute is the only way I have to be assure it is as I want ...


No, that's not true. A
Locked attributes = Author

will do the job as well.


I can't argue how it works ...
The following code will assure that, if the HTML generated by elog would be modified by hand by a malicious user the server can still preset the author field with the right $long_name?
Locked attributes = Author
Preset on Reply Author = $long_name

how works in details the "Locked Attribute" parameter then ?? ...
  1328   Tue Jul 26 12:02:35 2005 Reply Emiliano GabrielliAlberT@SuperAlberT.itQuestionLinux2.6.0bRe: Can't set Author attribute properly in reply?

Stefan Ritt wrote:

Emiliano Gabrielli wrote:
The following code will assure that, if the HTML generated by elog would be modified by hand by a malicious user the server can still preset the author field with the right $long_name?


Ok, you're right. But that requires quite some knowledge to change the generated HTML by hand. So for paranoiac people the "Subst" might be better. Actually you could have both the "Preset on Reply" and the "Subst on Reply", so on the reply entry form one sees already the correct author.


It's my actual configuration infact Wink
  1366   Wed Aug 3 13:01:17 2005 Reply Emiliano GabrielliAlberT@SuperAlberT.itBug reportLinux | Windows2.60b3Re: Response is very slow with beta3

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 ?? ..
  1368   Thu Aug 4 11:19:53 2005 Reply Emiliano GabrielliAlberT@SuperAlberT.itBug reportLinux | Windows2.60b3Re: Response is very slow with beta3

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 ...
  1380   Fri Aug 5 09:19:02 2005 Reply Emiliano GabrielliAlberT@SuperAlberT.itBug reportLinux 2.5.9+r16Re: problem with list display attribute

Stefan Ritt wrote:

John Habermann wrote:
I not sure if this has been found and fixed as I did find something to do with the list display attribute in the forums but wasn't sure if it was the same thing.

There seems to be a bug with the List Display attribute in that it drops the last attribute of the list. So in my example if I want to display the Subject in my list I have to add a dummy attribute after it otherwise the Subject will not be displayed. The comma after Subject is not enough, but all you have to do is to add 1 letter and then you will see the subject in List view. If you don't all I see is the Date and Author fields and then the Text field in my Summary view in the log book.

List Display = Date,Author,Subject,t

I am running elog 2.5.9+r1674-1 on Debian sarge.


I tried with the current 2.6.0-beta3 and it worked fine. Can you send me your full elogd.cfg in order to reproduce the problem?

it is the pippo bug...
it was fixed in revision 1.675, just the next he was using...

it is discussed in elog:1170
ELOG V3.1.5-3fb85fa6