I have a really odd issue with elog...

My setup:

elogd.cfg:
[global]
port = 2109
SMTP host = localhost
Resource dir = /usr/share/elog
Logbook dir = /srv/www/elog
charset = UTF-8
Main Tab = main
URL = https://elog.codemages.net
Relative redirection = 1
Usr = www
Grp = www
Resolve host names = 0
Self register = 0 
Admin user = ruskie
SSL = 0
Login expiration = 20

[links]
Subdir = links
Theme = default
Comment = Link spam
Attributes = Author, Category, Link, Comment
Options Category = General, Law, IT, Odds, Linux
Required Attributes = Link, Comment
Page Title = ELOG - Link spam
Reverse sort = 1
Quick filter = Date, Category
Time format = %Y-%m-%dT%H:%M
Date format = %Y-%m-%d
Password file = links.pwd
Admin user = ruskie
RSS Title = $logbook $entry time :$Author :$Link :$Comment

[notes]
Subdir = notes
Theme = default
Comment = Various notes
Attributes = Category, Comment
Options Category = General, Law, IT, Odds, Linux
Required Attributes = Comment
Page Title = ELOG - Various notes
Reverse sort = 1
Quick filter = Date, Category
Time format = %Y-%m-%dT%H:%M
Date format = %Y-%m-%d
Password file = notes.pwd
Admin user = ruskie
RSS Title = $logbook $entry time :$Comment


lighttpd.conf:
$HTTP["host"] =~ "elog.*" {
  proxy.server = ( "" =>
                   ( "10.0.0.10" =>
                     (
                       "host" => "10.0.0.10",
                       "port" => 2109
                     )
                   )
                 )

}

If I access elog directly on 2109 I get no issues but when I use this configuration it takes minutes to access
any elog page at all. But the odd thing is this only happens when I'm using a gecko based browser(firefox,
xulrunner based etc...) if I use webkit-gtk or elinks all the pages load up with no noticable delay.

I have tried this on different computers, different configurations and so on... And always the same behaviour
when it comes to a gecko based browser. Elinks and webkit-gtk load up fine.

Marking this as Other so far. If anyone knows anything about running elog and lighttpd togheter please speak up.

Hello,

Please could you help me.

We have 2 elog servers synchronized every minute via Elog mirroring function.

2 or 3 times a week, the slave crashes and we have to restart Elogd. I have found in /var/log/messages the same message every time elogd crash :

xmalloc: not enough memory

Thanks.

Dominique Bolla.

Hi,

Is there a way perhaps of implementing an email recall feature into E-Log? In other words, to recall an email before the recipient (s) read the email originating from the e-log. Something perhaps along the lines of what exists in something like Outlook.

Thks in advance.

Regards,

Niall

No, this is not implemented. What I usually do is to check "Suppress Email notification", submit and revise my entry. Once I'm satisfied, I edit again and do not check "Suppress Email notification" so that the email is finally sent out.

Hello,

I have installed the latest elog version from your web site.

My Admin user and my Login user are set in the elog.cfg to use the Self register process within the first login.

The issue is that I get only one time access to my log on the server (XP) and that is direct after the Selfregister process.

If I log out and login to test my admin and user account I will not get access to my server anymore.

My login page stays without any error message.

1 Notebook  XP Client internet explorer http://host ip:8080/demo------> 2nd Notebook XP Server

I have the deleted the cookies after each try.

I have retested later the accounts several times (login/logout) successful with the internet explorer http://host ip:8080/ on the server itself.

 Please could you help me to identify the issue?

Great, you found it! The original problem is probably related to your cookie handling. If you don't check the "keep me logged it" box, elog generates a temporary cookie, which is used for the duration of your browser session, then the browser discards it. If you theck the box, a persistent cookie is created, which your browser stores in the cookie database and reuses it for the coming 41 days. I believe you have a problem there (persistent cookies not allowed, disk full, whatever...) which does not allow handling of persistent cookies. Try from anohter browser/computer and you will see that it works.

Hi,

I'm curious is it possible to send email notificaitons from elog through an smtp server that requires SSL/TLS authentication? I think it's not but I thought I'd ask.

-Val

ps. sorry for the initial blank post...

This is currently not implemented and will probably not implemented in the next time, but it's on my (very long) to-do list.

Hi,

elogd sometimes crashes when there are large cookies. Or I'd guess it has something to do with the cookies, elogd crashed over and over again until I cleaned out cookies and authenticated sessions in firefox, then it stopped.

When I run "elogd -v" in gdb, and someone does:

GET / HTTP/1.1
Host: bba.eld.ki.sw.home.se:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; sv-SE; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: urem=0; TWIKISID=ecaa5a39e8446a27ec5a34bcbb9d4bcb; unm=erirone; upwd=c3w5MTg1; ipplanNoAuth=yes; SMSESSION=oKvAAv/J9WoCo6KoVdEJkhxz44G10x7TXigffOaAjLrSf0iOFrRJq97oWl32/UBQMvFslc4BgxN/VCz2K7/IRaKdFgmU4CHq/1UUv2RvdHB2HUbYbph+JgKUpAG+kN6Cc4BTwRWhmemUNhONXMRJUCfa6Tq9/osID2AT1wBFInFNww2xVmJPDSi1oltxtT345RgdGQIZbHzG2HBi1GijpiaD+4FI3WLLRzJOj3Art92BLlVDWSaPxKSdSZgVNfRSw33SupUqwD0Is2pc+ufKn4cg0azyOTLNDFOl0U5RI7K9AVgYM0NBsfDoEyBfK8pYIZTMqFFQsnWAdwYz9M2RLDBKyfMXdfGb3rrnOdPH0zvvkkoT01pZObI7dSqHD7IXLbjN/8Pt0O4eo5/SSQ7uKRGpBip0pKe3mxZYI4hsJejYwVBFegovS4qSUiL8UGDhG+lB20WEmDwIQfTG2ZtpckLC6t1CNfa5eFLWCOm+yESU+3AmP4zdJLJSqbznEl2SQTePP5NzI1R5WTAvBbsgX+N9Ab1g0Yui/i042qWNQPLg3/5c/WCHqzImi45+ov42C4mj9OcjGcAf7kaWBMwfdwfChREWkSpMrC2RRndlw+iVbShSK7lVfoCvIqk4491uQBT3bz3S0e56Vin+Oj8qbmEA/5Hp1x9b80qTRy/8lj7KLgbhV60BBvX7ahOkrIFCSjTi8y87K/u4b3KQHesNZgA7SyWRuT+vY4XCb8ANVl8eIui7vK5NNSiFFqLZ1IoeFaVu+gS/hhDu3m/rmK2t5iR2YW/aKmnGTVQsPPy/POVY/zXWgf7c6ps/sSMwTk9sy5Yr8yGYBSUrtZkn1/gK0wpqlRCcjuG991sfgr/UKbhK1dU0rI9E9PBPhvLQpjUHT49AAHL9A9S3FOs66CAFsoVo00WNqKuZcmLpEgXdpbW+mj43tiNugCT98Ec8+Iq0rZYKhYdqFu9AUOdJVXk2udBx9VkOVcRYteFICtwz3fvR02KCU3Sn3a0HKZ4wWOujUnH4nThZGVlUNyg/Of+9GKXY4mxqv/5ocEkO4q8xmAP/OJHrvgJ42kTAjaVgjlSG3b5iJTcu4jvqfC/yKU88Sw==


*** stack smashing detected ***: /root/elogd_2.7.5_2142 terminated
 

*** stack smashing detected ***: /root/elogd_2.7.5_2142 terminated

Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7dad875 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7daf201 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7de4e5c in ?? () from /lib/tls/i686/cmov/libc.so.6
#4  0x00000000 in ?? ()
(gdb)

 Stefan,

perhaps there should be something like the bold text below in elogd.c:

int process_http_request(const char *request, int i_conn)^M
...

   /* extract cookies */^M
   if ((p = strstr(request, "Cookie:")) != NULL) {^M
      p += 6;^M
      do {^M
         p++;^M
         while (*p && *p == ' ')^M
            p++;^M
         strlcpy(str, p, sizeof(str));^M
         for (i = 0; i < (int) strlen(str); i++)^M
            if (str[i] == '=' || str[i] == ';')^M
               break;^M
         if (str[i] == '=') {^M
            str[i] = 0;^M
            p += i + 1;^M
            for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' && i < (int) sizeof(cookie); i++)
                      cookie[i] = *p++;

...

Wow, where did you get that long cookie from? Certainly not from elogd. You must run elogd under Apache, and have some other service next to it on your server which distributes this long cookies, that's why other people did not experience this problem yet. I appreciate your fix. It's alwasy nice to see users not only complain about things, but try to fix them. Your fix is almost correct, you need a

i<(int) sizeof(cookie)-1

since there is the trailing zero for terminating the cookie string. I applied your fix to SVN revision #2146.

i<(int) sizeof(cookie)-1

I the cookie is used for single-sign-on for multiple sites within company.com. So the cookie is issued for "company.com" i.e. all websites gets it even elog.company.com:8080..

I mostly fibble little bit in perl (dont need to bother with trailing zeros there ).

BR, Niklas

i<(int) sizeof(cookie)-1

 Just noticed that this fix does not work. Elog cookies e.g. "upwd" may be after other long cookies its not seen, as now it stops reading the cookie-string after 256 chars. There needs to be something that goes through the cookies and saves only elog cookies... Would probably be better if you code that, if you have time  =D

BR, niklas

Stefan,

To solve the problem I suggest following change to elogd.c (2.7.5 2159).

Create a list of elog cookies, and store only these as parameters. Example diff:

---
$ diff elog/src/elogd.c elogd_niho.c
26557a26558
>    const char *cookie_list[] = { "upwd", "unm", "elmode", "urem", "wpwd", "apwd", "uname", NULL };
26603c26604,26610
<          setparam(str, cookie);
---
>          for(i=0; cookie_list[i]; i++) {
>             if(strcmp(cookie_list[i], str) == 0) {
>                setparam(str, cookie);
>                break;
>             }
>          }
>
---

In a more readable fashion:
int process_http_request(const char *request, int i_conn)
{
...
const char *cookie_list[] = { "upwd", "unm", "elmode", "urem", "wpwd", "apwd", "uname", NULL };
...
...
...
         /* store cookie as parameter */
         for(i=0; cookie_list[i]; i++) {
            if(strcmp(cookie_list[i], str) == 0) {
               setparam(str, cookie);
               break;
            }
         }

...

Not sure if I got all the cookies used by elog.

BR, niklas

I'm not sure if this works, since your test

i < (int) sizeof(cookie)

still will stop parsing cookies if there is one which is too long. So I added your test plus changed the parsing to:

for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; )

   if (i < (int) sizeof(cookie)-1)

      cookie[i++] = *p++;

   cookie[i] = 0;

The modification is in the curren SVN revision (# 2162). So have a look and check that it works.

Tried 2178 and I seem to hit some endless loop when I have big cookies. The loop seems to be in this for-loop (from gdb).

I perhaps you should have:

for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; )

   if (i < (int) sizeof(cookie)-1)

      cookie[i++] = *p++;

   else
      break;

   cookie[i] = 0;

... Seems to be working for me =)

Yepp, you're right. I applied your change to the distribution code. 

Hi Stefan,

In the past I have requested the "mark whole thread" feature, not yet implimented.  At present, I 
edit (in my case) the icon on the first entry to indicate current status of the thread.  I have 
had an idea connected to this.

If you view a page, in threaded form, and collapsed, the header of the first entry of each thread is 
shown.  The order, however, is that of the timed order of the latest entry in that thread.


As an option, under the same circumstances (threaded, collapsed), if the header of the most recent 
entry was shown, then that could also be an indicator of closed thread, or of "marking whole thread" 
option (maybe would be enough for those who desire those features).  It also gives an indication of 
the current status of the thread without having to edit the original entry of the thread to edit 
(for example) the icon. 

Just a thought on how to improve a wonderful program ;-)

> In the past I have requested the "mark whole thread" feature, not yet implimented.

That's not correct, it is implemented. Just add an attribute for that. Assume you have problem reports, so you 
add

Attributes = ..., Fixed
Options Fixed = boolean
Quick filter = Fixed

If you add a new entry, "Fixed" is false by default. All replies to that entry will contain then the same flag. 
Now if you want to mark the whole thread as fixed, do the following:

- go into list display
- display all entries in threaded mode
- click on "Select"
- select the thread you want to mark as fixed and click "Edit"
- now keep all attributes, but check the "Fixed" check box

and voila, the whole thread will contain "Fixed = 1". Using the quick filter, you can now show all fixed threads 
with one click.

Hi Stefan,

Must have missed it when the fixed/not fixed thread marking got implimented.

Anyhow, my main point would still apply for where the thread is not yet fixed, but is in one of a number of possible
states  (waiting, panic, work-in-progress....).  Clearly you can label the latest entry in a thread with the latest
status, and icon, but when in collapsed mode, you only see the initial entry.  If the latest entry were shown
(optionally), then one can tell at a glance in the collapsed listings which entry may need direct attention.



> > In the past I have requested the "mark whole thread" feature, not yet implimented.
> 
> That's not correct, it is implemented. Just add an attribute for that. Assume you have problem reports, so you 
> add
> 
> Attributes = ..., Fixed
> Options Fixed = boolean
> Quick filter = Fixed
> 
> If you add a new entry, "Fixed" is false by default. All replies to that entry will contain then the same flag. 
> Now if you want to mark the whole thread as fixed, do the following:
> 
> - go into list display
> - display all entries in threaded mode
> - click on "Select"
> - select the thread you want to mark as fixed and click "Edit"
> - now keep all attributes, but check the "Fixed" check box
> 
> and voila, the whole thread will contain "Fixed = 1". Using the quick filter, you can now show all fixed threads 
> with one click.

> Hi Stefan,
> 
> Must have missed it when the fixed/not fixed thread marking got implimented.
> 
> Anyhow, my main point would still apply for where the thread is not yet fixed, but is in one of a number of possible
> states  (waiting, panic, work-in-progress....).  Clearly you can label the latest entry in a thread with the latest
> status, and icon, but when in collapsed mode, you only see the initial entry.  If the latest entry were shown
> (optionally), then one can tell at a glance in the collapsed listings which entry may need direct attention.

If you always mark the whole thread with states (waiting, panic, work-in-progress,...) as described in my last posting, 
then you will see this from the thread initial entry as well. If you use icons, then even more. The only disadvantage 
is that you have to discipline yourself always modifying the whole thread and not only one entry in that thread.

Apologies if these are known bugs, I'm very busy at the moment but I wanted to post this before I forget:

I'm using Safari on a Mac to make Elog entries.

1) The preview of some pdf attachments in edit mode displays huge areas of white space around each page. I can send examples if you'd like - please email me directly, for some reason I never get email notifications from this forum (and they aren't being tagged as spam, so I don't know where they go).

2) When that happens, the text entry area for ELcode format expands horizontally to match the huge pdf file width. Text without line feeds then doesn't wrap until the huge window width is filled, so I have to scroll horizontally all the time while editing to see what I've written.

3) So I turned off attachment previewing as a workaround (Preview attachments = 0 ). That worked fine by not expanding the entry area, but I noticed some odd behavior. The list of attachments below the text entry area is badly formatted. Here's a screen shot:

I tried to reproduce this with a new entry but the text was formatted properly for that entry.

P.S. While editing this entry, I see that the text area width is again being set by the width of the picture I've attached - try it yourself; if you try to resize your browser window smaller while editing, the text will only wrap until the width of the attachment is reached - the text no longer wraps at smaller widths than the attachment. 

Your problem 1) is probably caused by ImageMagick. I use that package to convert PDFs to images. If this package estimates the paper size from the PDF incorrectly, you're screwed. You can go and actually locate the thumbnail pictures in the ELOG directory (should be named  xxxxxx_yyyyyy_<name>-0.png). If you check these pictures, they are probably already huge.

Problem 3) indeed is a small bug in elogd, which I fixed in revision #2178. If you can download the SVN version and recompile elogd, you should be fine:

 Thanks for the bug fix, we'll get our installation updated ASAP. And I will look into why some of my pdf file image sizes are interpreted incorrectly by ImageMagick, it might having something to do with how I've generated them.

Is it possible to set the default image size to always scale to fit the browser window? For example, this entry has a png attachment, but it still suffers from the fact that the text window size is set by the width of the png image.

If I'm forgetting something, sorry, I'm writing in a hurry!

Dennis