ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
462
|
Thu Jan 29 09:25:45 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Mac OSX | 2.3.9 | Re: Strange timezone in email sent with Postfix | > Instead of something like "Date: Wed, 28 Jan 2004 14:46:16 -0600", the
> "-0600" is replaced by a large number that doesn't correspond with anything
> I can figure out. This is the sort of thing that does no real harm, but the
> notebook users keep complaining.
This is caused by the elogd program itself. To produce the "-0600", it uses the
variable "timezone", which is defined as difference in seconds between local time
and coordinated universl time. This works find under Windows, Linux, FreeBSD, but
apparently not under MacOSX. Although this variable is defined, it's unassigned.
The code where this is used is in sendmail(), at the lines
time(&now);
ts = localtime(&now);
strftime(buf, sizeof(buf), "%a, %d %b %Y %H:%M:%S", ts);
offset = (-(int) timezone);
if (ts->tm_isdst)
offset += 3600;
The current localtime gets written into "buf", then the timzone offset gets
corrected by the daylight savings time, then the offset is used to produce the
"-0600".
So if anybody being familiar with MacOSX has some idea, please let me know.
- Stefan |
67007
|
Fri Feb 4 10:20:12 2011 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Other | 2.8.1 | Re: Strange problem with dates - need debugging help |
T. Ribbrock wrote: |
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...
|
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. The result of the function should be the time zone in seconds relative to GMT. So for central Europe, it should give "-3600".
Let me know if you find something out, I can then include it in the distribution.
Best regards,
Stefan |
67008
|
Fri Feb 4 11:52:45 2011 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Question | Other | 2.8.1 | Re: 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. |
67854
|
Wed Apr 1 20:25:21 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | ELOG V2.9. | Re: Strange browser behaviour with chrome? </table> |
Andreas Luedeke wrote: | Now I'm confused: if I create an entry with "elog -n 2 ...", then I put HTML code into elog and it is displayed as HTML. This HTML code does NOT convert a "<" into "<", otherwise you could not display any HTML.
But of course this code can be wrongly formatted, for example it can contain a </table> tag without a <table> tag before it. This will definitely spoil the display in ELOG, and that was what I was refering to.
I agree that html tags in plain text entries will not have this problem. |
Sure, in the main body text you can insert arbitrary HTML if this type of encoding is not prohibited. The < encoding I meant was for attribute values. Proof of principe above in the Subject field. |
67843
|
Mon Mar 30 17:48:06 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | ELOG V2.9. | Re: Strange browser behaviour with chrome? | The (correct) display tells me that the colours are user-defined, probably by the configuration option
Style <attribute> <value> = <style>
which selects different styles for different rows. Now I do not know why your browser should change behaviour all over sudden, but I would double check the configuration. Like removing all style additions in the config file, then try again, then add one by one. There could also be a class defined with the "style" option which has not been added to the default style file themes directory of the elog installation.
Stefan |
67844
|
Tue Mar 31 11:36:25 2015 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Question | Windows | ELOG V2.9. | Re: Strange browser behaviour with chrome? |
Stefan Ritt wrote: | The (correct) display tells me that the colours are user-defined, probably by the configuration option
Style <attribute> <value> = <style>
which selects different styles for different rows. Now I do not know why your browser should change behaviour all over sudden, but I would double check the configuration. Like removing all style additions in the config file, then try again, then add one by one. There could also be a class defined with the "style" option which has not been added to the default style file themes directory of the elog installation.
Stefan |
Just my two cent:
the content of a particular entry can change the rendering. If you have an HTML end tag like </table> or </font> in your entry, then the display after that entry may be spoiled.
You could try to select the very same entries in both browsers, to see if it does depend on the specific entry content.
If the problem persists, then I would suggest that you post the following:
- a minimal configuration for a logbook that reproduces the problem; and
- the actual entries, exported in XML or RAW format; and
- screenshots on how it displays with IE (add version number) and with Chrome (add version number).
Cheers
Andreas |
67845
|
Tue Mar 31 11:44:27 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | ELOG V2.9. | Re: Strange browser behaviour with chrome? |
Andreas Luedeke wrote: | the content of a particular entry can change the rendering. If you have an HTML end tag like </table> or </font> in your entry, then the display after that entry may be spoiled. |
Actually not. If you have HTML statements in entries, they will be rendered using escape characters (like </table> -> </table>). This is necessary to avoid cross-side-script vulnerabilities (XSS). If this is not working in some case, let me know and I have to fix it. The only exception is if you explicitly allow this via Allow HTML = 1 |
67846
|
Wed Apr 1 10:54:27 2015 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Question | Windows | ELOG V2.9. | Re: Strange browser behaviour with chrome? |
Stefan Ritt wrote: |
Andreas Luedeke wrote: | the content of a particular entry can change the rendering. If you have an HTML end tag like </table> or </font> in your entry, then the display after that entry may be spoiled. |
Actually not. If you have HTML statements in entries, they will be rendered using escape characters (like </table> -> </table>). This is necessary to avoid cross-side-script vulnerabilities (XSS). If this is not working in some case, let me know and I have to fix it. The only exception is if you explicitly allow this via Allow HTML = 1 |
If the content has been added with the "elog" command as HTML then it can contain mismatching HTML tags, can't it?
I don't see how this could be avoided by ELOG, unless you want to do a full HTML syntax check of all new and modified entries. |
|