Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 191 of 238  Not logged in ELOG logo
icon3.gif   charset specified in elog.conf has no effect [updated], posted by cunnilinux on Sun Aug 7 17:16:42 2005 

well, here's the problem that i had: my charset (koi8-u) was specified in elog.conf for every logbook, but this had no effect, and all elog pages continued tu appeared as iso-8859-1 (which is the default)

when i specified charset in the global section, the problem's gone away.

2do: i think it's worth testing how does it work whet charset specified for a separate logbook overrides globally specidied charset

elog version that is in use: 2.5.7 from debian sarge 3.1 r0a powerpc

    icon2.gif   Re: charset specified in elog.conf has no effect [updated], posted by Stefan Ritt on Mon Sep 5 20:16:50 2005 

cunnilinux wrote:
well, here's the problem that i had: my charset (koi8-u) was specified in elog.conf for every logbook, but this had no effect, and all elog pages continued tu appeared as iso-8859-1 (which is the default) when i specified charset in the global section, the problem's gone away.

2do: i think it's worth testing how does it work whet charset specified for a separate logbook overrides globally specidied charset

elog version that is in use: 2.5.7 from debian sarge 3.1 r0a powerpc


The documentation clearly states that the "charset" option is under the [global] section. I put it there since it does not make much sense to have separate charsets for separate logbooks. Or do you have one Russian, one Japanese and one Swedish logbook on the same server? Maybe for an international language school Wink

I can easily put it into the individual logbook's config, but only if more than one person requests this.
icon1.gif   password forgot kills elogd, posted by Martin Lindjärv on Wed Aug 31 22:03:04 2005 
Hi!

At first, thanx for this software!

But i found a bug or something like that. I installed elog on win2003 and winxp with default settings. And everywhere i had same problem - when forgot password is used it kills elogd. Error what is reported in EventLog is "Faulting application elogd.exe, version 0.0.0.0, faulting module elogd.exe, version 0.0.0.0, fault address 0x0002f1ee." and thats all. For testing tried newest beta too but it seems to have same problem.
i can insert my email address and when i click submit it wait's for some time and then gives 404.
But tried under linux (gentoo) and everything works like charm.

Any kind of info would be good...
    icon2.gif   Re: password forgot kills elogd, posted by Stefan Ritt on Mon Sep 5 20:05:43 2005 

Martin Lindjärv wrote:

But i found a bug or something like that. I installed elog on win2003 and winxp with default settings. And everywhere i had same problem - when forgot password is used it kills elogd. Error what is reported in EventLog is "Faulting application elogd.exe, version 0.0.0.0, faulting module elogd.exe, version 0.0.0.0, fault address 0x0002f1ee." and thats all. For testing tried newest beta too but it seems to have same problem.
i can insert my email address and when i click submit it wait's for some time and then gives 404.
But tried under linux (gentoo) and everything works like charm.


I tried with the current version under XP and found no problem. Can you try 2.6.0-beta4?
icon2.gif   something for the wishlist: 'Recent Changes', posted by Heiko Scheit on Fri Aug 26 13:08:10 2005 
Something for the wishlist:

A 'Recent Changes'-link (option) that lists entries that were changed
recently, where 'recent' can be changed from 1,2,3...(some maximum)
days.
    icon2.gif   Re: something for the wishlist: 'Recent Changes', posted by ralphb on Thu Sep 1 18:26:38 2005 

Heiko Scheit wrote:
A 'Recent Changes'-link (option) that lists entries that were changed
recently, where 'recent' can be changed from 1,2,3...(some maximum)
days.


Two possible solutions:

1. Use ELOG's RSS support (look for "RSS Title" in the config syntax help). I added an RSS icon to each entry with "Bottom Text=<a href="http://myserver:8080/mylogbook/elog.rdf"><img border=0 height="14" width="36" src="/Rssicon_3614.gif" alt="[RSS]"></a>

2. Add a new attribute "Revised" and config it as follows: "Locked attributes = Revised" and "Subst on Edit Revised = $date". It'll get updated each time the entry gets updated. Then all you just need to create a link to "http://yourserver:8080/yourlogbook/page?mode=summary&rsort=Revised"

Best regards, Ralph.
icon1.gif   password forgot kills elogd, posted by Martin Lindjärv on Wed Aug 31 22:02:46 2005 
Hi!

At first, thanx for this software!

But i found a bug or something like that. I installed elog on win2003 and winxp with default settings. And everywhere i had same problem - when forgot password is used it kills elogd. Error what is reported in EventLog is "Faulting application elogd.exe, version 0.0.0.0, faulting module elogd.exe, version 0.0.0.0, fault address 0x0002f1ee." and thats all. For testing tried newest beta too but it seems to have same problem.
i can insert my email address and when i click submit it wait's for some time and then gives 404.

Any kind of info would be good...
icon8.gif   Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction, posted by Chris Green on Fri Aug 5 02:27:15 2005 
Hi,

Just as our ELOG went into production, I tripped over a couple of related (I think) bugs.

First, the easy one: line 21368 of src/elogd.c has a compile warning which looks non-benign. I fixed it in my local copy with:

Index: elogd.c
===================================================================
RCS file: /usr/local/cvsroot/elog/src/elogd.c,v
retrieving revision 1.739
diff -r1.739 elogd.c
21368,21369c21368
< sprintf(str, "?fail=1", user);
< redirect(lbs, str);
---
> redirect(lbs, "?fail=1");

Regardless (ie if I use the original CVS code or the patched version), a hard-to trace problem occurs with my configuration whereby users are denied access after password entry at the logbook selection page (even when details are verifiably correct), and users are dropped through to the next (non-protected) Top Group page. This problem goes away if "Protect Selection Page" is turned off.

A kind of "shadow" of this problem occurs if you create a new logbook from the Change Config File page, whereby after creating the new logbook one is dropped through to the next Top Group's selection page after saving the configuration (and the url has ?fail=1 added to it, althoguh line 21368 above is hardly the only place where this could have occurred).

I think all these things are linked. I'd be grateful if you could review this section of this code for possible causes of these problems. While we can operate for now with non-logged-in users able to see our list of logbooks, that is not something we want for the long term.

Thanks for your help,
Chris.
    icon2.gif   Re: Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction, posted by Stefan Ritt on Fri Aug 5 12:06:47 2005 

Chris Green wrote:
Index: elogd.c
===================================================================
RCS file: /usr/local/cvsroot/elog/src/elogd.c,v
retrieving revision 1.739
diff -r1.739 elogd.c
21368,21369c21368
< sprintf(str, "?fail=1", user);
< redirect(lbs, str);
---
> redirect(lbs, "?fail=1");


Thanks, applied.


Chris Green wrote:
Regardless (ie if I use the original CVS code or the patched version), a hard-to trace problem occurs with my configuration whereby users are denied access after password entry at the logbook selection page (even when details are verifiably correct), and users are dropped through to the next (non-protected) Top Group page. This problem goes away if "Protect Selection Page" is turned off.


I hope I have fixed this problem, at least it works ok here when I tried with your config file.

One note I would like to make however: "Top groups" were invented for having completely separate logbook groups. Before the invention of top groups, one had to run several instances of elogd for different departments for example, where one department should not see the other department's logbooks. But having many departments means having to maintain many elogd daemons. This led to the invention of top groups, so one daemon can serve several independent groups, each having their own [global] section, with probably their own administrator.

In your case however, it would be more applicable not to use top groups, but use nested groups. Like
Group MiniBooNE = Analysis, Miscellaneous
Group Analysis = Charged Current Pi Plus, Neutral Current Coherent Pions
Group Miscellaneous = demo

I presume this is more what you want, and you can avoid some problems which arise from top groups.



Chris Green wrote:
A kind of "shadow" of this problem occurs if you create a new logbook from the Change Config File page, whereby after creating the new logbook one is dropped through to the next Top Group's selection page after saving the configuration (and the url has ?fail=1 added to it, althoguh line 21368 above is hardly the only place where this could have occurred).


I have not tested this one, but it could well be that the modification I made also fixes this.
       icon7.gif   Re: Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction, posted by Chris Green on Fri Aug 5 16:15:04 2005 

Stefan Ritt wrote:
One note I would like to make however: "Top groups" were invented for having completely separate logbook groups. Before the invention of top groups, one had to run several instances of elogd for different departments for example, where one department should not see the other department's logbooks. But having many departments means having to maintain many elogd daemons. This led to the invention of top groups, so one daemon can serve several independent groups, each having their own [global] section, with probably their own administrator.

In your case however, it would be more applicable not to use top groups, but use nested groups. Like
Group MiniBooNE = Analysis, Miscellaneous
Group Analysis = Charged Current Pi Plus, Neutral Current Coherent Pions
Group Miscellaneous = demo

I presume this is more what you want, and you can avoid some problems which arise from top groups.


The quick attempt I just made to use this doesn't do what I want, which is to require password protection for the Analysis logbook selection page. If you think that *is* possible and I just didn't configure it properly, I'd appreciate pointers. In the meantime though, your bug fixes appear to have solved my top group / password problem and I think I'll proceed with that for now.

Thanks again,
Chris.
          icon2.gif   Re: Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction, posted by Stefan Ritt on Fri Aug 5 16:51:02 2005 

Chris Green wrote:
The quick attempt I just made to use this doesn't do what I want, which is to require password protection for the Analysis logbook selection page.


This indeed is not possible and you have to use top groups for that.
icon5.gif   How does RSS interact with password protection?, posted by Chris Green on Fri Aug 5 16:17:00 2005 
Can I have an RSS feed to a protected log book? Does it also require authentication, or does it bypass it? If it bypasses it, how do I disable RSS?

Thanks,
Chris.
    icon2.gif   Re: How does RSS interact with password protection?, posted by Stefan Ritt on Fri Aug 5 16:48:56 2005 

Chris Green wrote:
Can I have an RSS feed to a protected log book? Does it also require authentication, or does it bypass it? If it bypasses it, how do I disable RSS?

Thanks,
Chris.


I added this topic to the FAQs at http://midas.psi.ch/elog/faq.html#15
icon5.gif   Email subject garbaged when set?, posted by Chris Green on Wed Jul 27 17:30:38 2005 
Hi,

So I'm using the CVS version now since I was hoping this would be fixed. If I set the email subject explicitly, viz:

Use Email Subject = [BooNE-ELOG] New submission to $logbook from $Author

The email I get has:

Subject:
=?ISO-8859-1?B?W0Jvb05FLUVMT0ddIE5ldyBzdWJtaXNzaW9uIHRvIENoYXJnZWQgQ3Vyc
mVudCBQaSBQbHVzIGZyb20gQ2hyaXMgR3JlZW4=?=

... which isn't particularly illuminating.

Advice appreciated.

Thanks,
Chris.
    icon2.gif   Re: Email subject garbaged when set?, posted by Stefan Ritt on Thu Aug 4 22:59:12 2005 

Chris Green wrote:
The email I get has:

Subject:
=?ISO-8859-1?B?W0Jvb05FLUVMT0ddIE5ldyBzdWJtaXNzaW9uIHRvIENoYXJnZWQgQ3Vyc
mVudCBQaSBQbHVzIGZyb20gQ2hyaXMgR3JlZW4=?=

... which isn't particularly illuminating.


This is the BASE64 encoding of the subject. It was discussed here and I implemented it according to RFC2047. All subjects I receive look fine in Outlook and Thunderbird, but not under Pine, which apparently does not implement the RFC correctly. One could of course put a switch into elog to encode it or not. But as soon as you want to send some non-ASCII characters (like the Norwegian as described in the thread mentioned above) you have a problem. Maybe you can configure your email client correctly to interprete the encoded subject?
       icon2.gif   Re: Email subject garbaged when set?, posted by Chris Green on Fri Aug 5 01:13:13 2005 

Stefan Ritt wrote:

Chris Green wrote:
The email I get has:

Subject:
=?ISO-8859-1?B?W0Jvb05FLUVMT0ddIE5ldyBzdWJtaXNzaW9uIHRvIENoYXJnZWQgQ3Vyc
mVudCBQaSBQbHVzIGZyb20gQ2hyaXMgR3JlZW4=?=

... which isn't particularly illuminating.


This is the BASE64 encoding of the subject. It was discussed here and I implemented it according to RFC2047. All subjects I receive look fine in Outlook and Thunderbird, but not under Pine, which apparently does not implement the RFC correctly. One could of course put a switch into elog to encode it or not. But as soon as you want to send some non-ASCII characters (like the Norwegian as described in the thread mentioned above) you have a problem. Maybe you can configure your email client correctly to interprete the encoded subject?


Apparently the pine people think they're implementing it correctly. Indeed the default subject, "[ISO-8859-1] New ELOG entry" appears just fine. The one for membership confirmation, and anything set in Use Email Subject, however, is borked as above. Maybe the pine bug is something that can be worked around with something simple (like spaces after the ISO spec, or something? Some things work just fine, as I said.

Thanks,
Chris.
       icon2.gif   Re: Email subject garbaged when set?, posted by Heiko Scheit on Fri Aug 5 11:18:08 2005 

Stefan Ritt wrote:

Chris Green wrote:
The email I get has:

Subject:
=?ISO-8859-1?B?W0Jvb05FLUVMT0ddIE5ldyBzdWJtaXNzaW9uIHRvIENoYXJnZWQgQ3Vyc
mVudCBQaSBQbHVzIGZyb20gQ2hyaXMgR3JlZW4=?=

... which isn't particularly illuminating.


This is the BASE64 encoding of the subject. It was discussed here and I implemented it according to RFC2047.


Well not quite. According to the RFC the encoded word must not be longer than 75 characters! Indeed
shorter subjects are displayed by pine, but not longer ones as they do not follow RFC2047.
Below is the quote from the RFC.


Stefan Ritt wrote:

All subjects I receive look fine in Outlook and Thunderbird, but not under Pine, which apparently does not implement the RFC correctly.


Actually pine implements it correctly but not elogd Smile

The relevant text from the RFC
   An 'encoded-word' may not be more than 75 characters long, including
   'charset', 'encoding', 'encoded-text', and delimiters.  If it is
   desirable to encode more text than will fit in an 'encoded-word' of
   75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
   be used.
          icon2.gif   Re: Email subject garbaged when set?, posted by Stefan Ritt on Fri Aug 5 12:37:42 2005 

Heiko Scheit wrote:
Well not quite. According to the RFC the encoded word must not be longer than 75 characters! Indeed shorter subjects are displayed by pine, but not longer ones as they do not follow RFC2047.
Below is the quote from the RFC.


You are right Big grin, thanks for this information, I overlooked it.

Now I split a long subject into separate chunks of encoded words, and my pine is happy. Update in CVS.
icon4.gif   problem with list display attribute, posted by John Habermann on Thu Jul 28 01:02:00 2005 
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.
    icon2.gif   Re: problem with list display attribute, posted by Stefan Ritt on Thu Aug 4 20:32:56 2005 

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?
       icon2.gif   Re: problem with list display attribute, posted by Emiliano Gabrielli on Fri Aug 5 09:19:02 2005 

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