Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 228 of 796  Not logged in ELOG logo
ID Date Icon Author Author Emailup Category OS ELOG Version Subject
  66464   Mon Jul 27 10:20:14 2009 Entry T. Ribbrockemgaron+elog@ribbrock.orgBug reportLinux2.7.6Wrong error message if invalid attribute is used

I just ran into this little bug: I had defined a new logbook in my config file and suddenly got the message Attribute "Date" not allowed. While I did have several attributes starting with the word "Date" (e.g. "Date In Service", "Date Retired") I had no attribute "Date" in there. After some pondering and wildly commenting out lines, it finally dawned on me: I had used an attribute "ID" - which is also not allowed. However, it would be very helpful if the error message actually reflected that...

  66472   Tue Jul 28 16:30:46 2009 Entry T. Ribbrockemgaron+elog@ribbrock.orgBug reportLinux2.7.6r2233Odd problem (bug?) with certain attribute

I have the following simple test logbook:

; General
List display = Edit, Hostname, OS, Size
Entries per page = 150
Quick filter = OS
Date Format = %d/%m/%Y
Summary Lines = 0

; Attributes
Attributes = Hostname, OS, CPU,Size
Required Attributes = Hostname
Sort Attributes = Hostname

; Message part: log is text only, but elog is allowed
Default encoding = 0
Allowed encoding = 2

For some strange reasons, I'm having problems with the "Size" attribute, which I have added later. If I start adding/editing entries, at some point, the "Size" attribute will stay at "0" and will not accept any further changes. I've tried to pare down the config to maybe find which statement could be causing this, but to no avail. The only thing I can say is taht id doesn not seem to happen if the configuration consist of the sole line

Attributes = Hostname, OS, CPU,Size

I'm quite puzzled as to what is going on here (the original problems stems from a more complicated logbook) - I'm not even 100% sure whether this happens due to a bug or not.

 

Regards,

 

Thomas

  66474   Tue Jul 28 17:10:13 2009 Reply T. Ribbrockemgaron+elog@ribbrock.orgBug reportLinux2.7.6r2233Re: Odd problem (bug?) with certain attribute

Stefan Ritt wrote:

That's indeed a strange bug, and thanks to your detailed explanation I could easily reproduce it. The problem was that in the ELCode toolbar there is already a "SIZE" parameter, which gets submitted instead of your "size" attribute. Therefore whatever you submit as "size", gets replaced by zero (since the SIZE drop-down box usually sits at zero). So you can either go and change your "size" attribute into someting else like "Memory Size", or you upgrade to version 2244, where I fixed this problem.

 Very nice, thank you! Given that I also still have to test the fix you made for the crash problem with "shared" logbooks (I assume it's also present in 2244), I'll upgrade and report back (probably tomorrow).

  66482   Wed Jul 29 13:23:41 2009 Agree T. Ribbrockemgaron+elog@ribbrock.orgBug reportLinux2.7.6r2233Re: Odd problem (bug?) with certain attribute

T. Ribbrock wrote:

 Very nice, thank you! Given that I also still have to test the fix you made for the crash problem with "shared" logbooks (I assume it's also present in 2244), I'll upgrade and report back (probably tomorrow).

 2244 is now running, and indeed, the "Size" attribute works now. Thank you!

  66483   Wed Jul 29 14:48:34 2009 Agree T. Ribbrockemgaron+elog@ribbrock.orgBug reportLinux2.7.6r2233Re: Crashes when editing entries

By now, I've installed 2244 and ran some rudimentary tests. So far, I was not able to reproduce the crash anymore. Looking good!

  67006   Fri Feb 4 00:11:09 2011 Question T. Ribbrockemgaron+elog@ribbrock.orgQuestionOther2.8.1Strange problem with dates - need debugging help

I have just installed elog 2.8.1 on my OpenBSD 4.8 server (I've added the necessary Makefile patch to "Contributions"). Everything seems to work fine, however, I ran into a very odd problems with the dates of the logbook entries: When I start a new entry, the current date/time is displayed correctly. When I submit the entry and look at it again, the date has changed to some value in 1996 . I've checked the actual logbook file and there, the entry has a Date line like this:

Date: Thu, 03 Feb 2011 23:53:28 -13049141
 

The "-13049141" looks very suspicious to me - but I have no idea whatsoever why this happens. I had elogd running with -v, but that did not give me any hints. Any ideas how to debug/resolve this would be much appreciated...

 

  67008   Fri Feb 4 11:52:45 2011 Agree T. Ribbrockemgaron+elog@ribbrock.orgQuestionOther2.8.1Re: Strange problem with dates - need debugging help

Stefan Ritt wrote:

The problem is most probably related to the time zone. elogd contains a function:

/* workaround for wong timezone under MAX OSX */
long my_timezone()
{
#if defined(OS_MACOSX) || defined(__FreeBSD__)
   time_t tp;
   time(&tp);
   return -localtime(&tp)->tm_gmtoff;
#else
   return timezone;
#endif
}
 
from which you can see that there is a different behavior between different Linux flavors and OSX/FreeBSD. Maybe you need an additional
 
|| defined(__OpenBSD__)
 
if the pre-compiler directive __FreeBSD__ is not defined on your system.
[...]
 

 BINGO! That was it - thank you! I've added the || defined(__OpenBSD__) in the place you described above and now the dates are correct. While I was at it, I also had a look at what other ifdefs there are for FreeBSD and the only other one I found was also in elogd.c:

#if defined (_BSD_VA_LIST_) && defined (__FreeBSD__)

I'm far from being a C programmer, but I did some quick and dirty compile tests with various ifdefs set and apparently, _BSD_VA_LIST_ is not set on OpenBSD, so I guess that this statement does not need modification. I will keep my eyes peeled for strange behaviour, though...

Cheerio,

Thomas

P.S.: One thing I noticed is that the OpenBSD variant of gcc throws these warnings when compiling elogd.c:

gcc -g -funroll-loops -fomit-frame-pointer -W -Wall -DHAVE_SSL -I../mxml -o elogd src/elogd.c crypt.o regex.o mxml.o strlcpy.o -lcrypto -lssl
/tmp//ccHhMZfy.o(.text+0xd2f): In function `int_vasprintf':
src/elogd.c:826: warning: vsprintf() is often misused, please use vsnprintf()
/tmp//ccHhMZfy.o(.text+0xae8): In function `xstrdup':
src/elogd.c:736: warning: strcpy() is almost always misused, please use strlcpy()
/tmp//ccHhMZfy.o(.text+0x13c7): In function `my_shell':
src/elogd.c:1197: warning: sprintf() is often misused, please use snprintf()
/tmp//ccHhMZfy.o(.text+0xf0ae): In function `el_correct_links':
src/elogd.c:5178: warning: strcat() is almost always misused, please use strlcat()

I'm not certain whether this is specific to this gcc variant, but I seem to remember that the OpenBSD folks added some extra warnings and suchlike as part of their overall code audit, so I thought I'd mention it.

  67009   Fri Feb 4 23:48:54 2011 Warning T. Ribbrockemgaron+elog@ribbrock.orgBug reportOther2.9.0-2384Odd bug with conditional and required attributes

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!

ELOG V3.1.5-2eba886