If I create an entry via the web-interface, the defined encoding of the browser is used.
If I create an entry via "elog", it is always stored in UTF-8 encoding.
For the text I can overcome that with HTML encoding, but for attribute values the encoding does not show properly.
The only solution I found was to convert the whole logbook to UTF-8 encoding:

 define "charset=UTF-8" in elogd.cfg
 iconv --from-code=ISO-8859-1 --to-code=UTF-8 elogd.cfg >tmp;mv tmp elogd.cfg
 iconv --from-code=ISO-8859-1 --to-code=UTF-8 resources/eloglang.german >tmp;mv tmp resources/eloglang.german

Has anyone any idea why ISO8859-1 does not work for me?

Or can anyone advice me of an editor similar to NEdit that is capable to display UTF-8? :-)

I just ran into an odd bug with conditional attributes: If I add a certain attribute to "Required Attributes", none of the conditionals will work anymore. I have tried to create a small logbook definition that will demonstrate the problem (the original logbook is more complex and uses two sets of conditionals, both of which will be disabled when the bug hits):

; General settings
Menu commands = List, New, Edit, Duplicate, Delete, Reply, Select, Move to, Download, Find, Logout, Help, Config,Admin
List Menu commands = New, Select, Find, Logout, Help, Config, Admin, Import, Download
Date Format = %d/%m/%Y
List conditions = 1
List display = Edit, Type, Created, StatusA, StatusB, Archived, Test Text, Public?

; Attributes
Attributes = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
Required Attributes = Type

; Attribute Types
Type Created = date
Type Archived = date

; Options & Tooltips
Options Type = Type1{0}, Type2{1}
Options StatusA = Status-A-red, Status-A-orange, Status-A
Options StatusB = Status-B-red, Status-B-orange, Status-B
Options Public? = yes,no

; Conditionals
{0}Show Attributes Edit = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
{1}Show Attributes Edit = Type, Created, StatusA, Archived, Test Text, Public?

The above logbook definition works. However, if I replace the Required Attributes = Type with Required Attributes = Type, Public?, the conditionals will no longer work. I can see the difference in the reactions of the browser - with the extra attribute, nothing happens when I change "Type". Without, the browser will spring into action and reload as soon as I change "Type". I've tested this with both Firefox 3.6.13 and Konqueror 4.4.5 on Kubuntu 10.04 as clients. Fortunately, this is not a showstopper for me, as it is not mandatory to have this attribute defined as required, but I find it a weird issue nonetheless.

Cheerio,

Thomas

P.S.: I'm currently running the latest SVN version of elogd on OPenBSD as I ran into the same problem as described in Message 66984. The above problem also happens with the 2.8.1 I was using before. Some feedback: The SVN version compiled and ran without any further intervention on OpenBSD - very nice!

We upgraded to Elog 2.9.0-2402 and since then mails sent by Elog when posting an item are from the default account, not from the logged in user's mail address.

The configuration is, for the mail part :

Default Email From = Olivier.Callot@cern.ch

Use Email Subject = ELOG Computing Operations - $Subject ($Site - $System - $Production number)

Thanks for telling me which flag/option I have to set to restore the proper mail 'From:' field.

When running openvas (a nessus fork) against elog 2.9.0 I provoked the following crash:

Apr  9 17:32:06 unixland elogd[1300]: POST / HTTP/1.0#015#012Host: unixland.home
#015#012Content-Length: -800#015#012#015#012XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Apr  9 17:32:06 unixland kernel: [664894.491242] elogd[1300]: segfault at b7713d
2e ip 080b6956 sp bf8d5ea0 error 4 in elogd[8048000+96000]

openvas reports that it was testing for CVE-2002-1212 when the crash occurred.

Startup info:

Apr  9 19:35:54 unixland elogd[21584]: elogd 2.9.0 built Apr  9 2011, 17:49:08 
Apr  9 19:35:54 unixland elogd[21584]: revision 2411

-- rouilj

I'm now running eLog  2.9.0 and seeing the same crashes. However, I've got some more information that may be helpful.

The crash seems to be directly related to the order of replies in the thread. For example, in this thread I am replying to the original entry. The original entry has 2 children (the entries are siblings) and no grandchildren.

In our installation, eLog crashes consistently under the following conditions:

       go to the "list" display

       set it to "threaded"

       "select" a thread that has siblings at any generation of replies

       choose "edit"

If the selected thread only has one entry at any generation, eLog does not crash.

Here's a horrible attempt at a display of two message threads. Note that in the first example, there are 2 replies at the same generation (siblings)--both the person who responded and the original submitter replied to the initial submission. After that, all replies were to successive generations.

-------------- Causes eLog to Crash ------------------
!   Full Name (submitter) module failure 
    =>   Full Name (submitter) Re: module failure 
    =>   Full Name (replier) Re: module failure 
               =>   Full Name (submitter) Re: Re: module failure 
                         =>   Full Name (submitter) Re: Re: Re: module failue

------------------------------------------------------



-------------- No eLog Problem  ------------------
!   Full Name (submitter) Labwide failure of mcc 
    =>   Full Name (replier) Re: Labwide failure of mcc 
           =>   Full Name (submitter) Re: Re: Labwide failure of mcc 
                     =>   Full Name (replier) Re: Re: Re: Labwide failure of mcc 
------------------------------------------------------

When I run a mirror server and both logbooks using SSL/KRB5 then the cron job causes a segmentation fault.

I haven't tried to check it with a simple configuration yet.
My set-up: two elogd on same server, one running "german" on port 444, the other "english" on port 445.
Both are behind an apache webserver configured reverse proxy, to hide the ports for external access.
I'll try to reproduce the fault with a "minimal configuration" soon and report again.


Debug output from GDB:

run -x -c /usr/local/elog/elogd_en.cfg
Starting program: /opt/elog-2.9.0/elog/elogd -x -c /usr/local/elog/elogd_en.cfg
elogd 2.9.0 built May 30 2011, 11:14:32 revision 2414
File "/var/run/elogd.pid" exists, using "/var/run/elogd.pid.445" instead.
Falling back to default group "elog"
Falling back to default user "elog"
User "elog" not found
Falling back to default user "nobody"
FCKedit detected
Falling back to default group "elog"
Falling back to default user "elog"
User "elog" not found
Falling back to default user "nobody"
ImageMagick detected
Indexing logbooks ... done
SSLServer listening on port 445 ...

Program received signal SIGSEGV, Segmentation fault.
0x0030b7b5 in SSL_write () from /lib/libssl.so.6

Hello,

We've been using ELOG 2.6.5 to 2.7.8 for 4 years without any major problems.

Recently we upgraded to version 2.9.0 and since we've had the daemon frequently crash with SEGV.

I've detached debugging output from one time when ELOG the crashed. We've had many crashes
it was a different logbook each time. Platform is Solaris 10 5/08 on SPARC.

Has anyone else experienced problems with 2.9.0?

Best Regards

Kester