ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66724
|
Wed Feb 24 15:54:40 2010 |
| Ulf Helmersson | ulfhe@ifm.liu.se | Bug report | Other | V2.7.8-227 | Show Attributes | This programing have stoped working, I guess after last update.
Elog is running on Solaris.
Ulf Helmersson
Options Type = Journal Article{1}, Proceeding Article{2}, Book chapter{3}, Book{4}, Patent{5}
{1} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Abbrivated journal name, Volume, First page, Year, Elsevier format, AIP/APS format, IOP format
{2} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Conference name, Place, Country, First page, Year, Month.Days, Volume, Elsevier format Proceeding
{3} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Book Title, Editors, Publisher, Place, First page, Year, Elsevier format Book chapter
{4} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Publisher, Place, First page, Year, Elsevier format Book, IOP format Book
{5} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Patent number, Year, First page, Elsevier format Patent
|
66754
|
Fri Mar 12 12:59:25 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Other | V2.7.8-227 | Re: Show Attributes |
Ulf Helmersson wrote: |
This programing have stoped working, I guess after last update.
Elog is running on Solaris.
Ulf Helmersson
Options Type = Journal Article{1}, Proceeding Article{2}, Book chapter{3}, Book{4}, Patent{5}
{1} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Abbrivated journal name, Volume, First page, Year, Elsevier format, AIP/APS format, IOP format
{2} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Conference name, Place, Country, First page, Year, Month.Days, Volume, Elsevier format Proceeding
{3} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Book Title, Editors, Publisher, Place, First page, Year, Elsevier format Book chapter
{4} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Publisher, Place, First page, Year, Elsevier format Book, IOP format Book
{5} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Patent number, Year, First page, Elsevier format Patent
|
The option
Show Attributes =
has been changed to
Show Attributes Edit =
to distinguish between normal entry display an edit mask. So please adjust your configuration file and everything will be fine again. |
66921
|
Wed Oct 27 23:43:37 2010 |
| Morion Black | morion.estariol@gmail.com | Question | Other | 2.8.0 | Can anyone help compile ELog 2.8.0 on SunOS 5.11? | I have server with SunOS 5.11:
uname -a
SunOS *** 5.11 snv_134 i86pc i386 i86pc
when I try to compile ELog I get error:
gmake
gcc -DHAVE_SSL -w -c -o crypt.o src/crypt.c
gcc -DHAVE_SSL -I../mxml -o elog src/elog.c crypt.o -lsocket -lnsl -lssl
Undefined first referenced
symbol in file
MAX crypt.o
MIN crypt.o
mempcpy crypt.o
_ast_strtoul crypt.o
_ast_realloc crypt.o
ld: fatal: symbol referencing errors. No output written to elog
collect2: ld returned 1 exit status
gmake: *** [elog] Error 1
Can anyone help to compile Elog?
|
66938
|
Tue Nov 16 10:00:48 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Other | 2.8.0 | Re: Can anyone help compile ELog 2.8.0 on SunOS 5.11? |
Morion Black wrote: |
I have server with SunOS 5.11:
uname -a
SunOS *** 5.11 snv_134 i86pc i386 i86pc
when I try to compile ELog I get error:
gmake
gcc -DHAVE_SSL -w -c -o crypt.o src/crypt.c
gcc -DHAVE_SSL -I../mxml -o elog src/elog.c crypt.o -lsocket -lnsl -lssl
Undefined first referenced
symbol in file
MAX crypt.o
MIN crypt.o
mempcpy crypt.o
_ast_strtoul crypt.o
_ast_realloc crypt.o
ld: fatal: symbol referencing errors. No output written to elog
collect2: ld returned 1 exit status
gmake: *** [elog] Error 1
Can anyone help to compile Elog?
|
The crypt.c file is not from me, so there might be some issues on other OSes. I defined now at least MIN/MAX by hand, and also removed mempcpy. The new version is attached. Can you try again to compile it? The strtoul and realloc are nomal C functions, maybe you have to add some other libraries for linking, but I'm not an expert for SunOS. |
Attachment 1: crypt.c
|
/* SHA256-based Unix crypt implementation.
Released into the Public Domain by Ulrich Drepper <drepper@redhat.com>.
Adapted for MS Windows by Stefan Ritt <stefan.ritt@psi.ch>
$Id: crypt.c 2334 2010-11-16 08:59:45Z ritt $ */
#ifdef _MSC_VER
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define __alignof__(x) sizeof(x)
#define alloca(x) malloc(x)
#define ERANGE 34
typedef unsigned int uint32_t;
#else
#include <errno.h>
#include <limits.h>
#include <stdint.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/param.h>
#include <sys/types.h>
#endif
#ifndef MAX
#define MAX(x,y) ((x)>(y)?(x):(y))
#define MIN(x,y) ((x)<(y)?(x):(y))
#endif
/* Structure to save state of computation between the single steps. */
struct sha256_ctx {
uint32_t H[8];
uint32_t total[2];
uint32_t buflen;
char buffer[128]; /* NB: always correctly aligned for uint32_t. */
};
#if __BYTE_ORDER == __LITTLE_ENDIAN
# define SWAP(n) \
(((n) << 24) | (((n) & 0xff00) << 8) | (((n) >> 8) & 0xff00) | ((n) >> 24))
#else
# define SWAP(n) (n)
#endif
/* This array contains the bytes used to pad the buffer to the next
64-byte boundary. (FIPS 180-2:5.1.1) */
static const unsigned char fillbuf[64] = { 0x80, 0 /* , 0, 0, ... */ };
/* Constants for SHA256 from FIPS 180-2:4.2.2. */
static const uint32_t K[64] = {
0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5,
0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3,
0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc,
0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7,
0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13,
0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3,
0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5,
0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208,
0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
};
/* Process LEN bytes of BUFFER, accumulating context into CTX.
It is assumed that LEN % 64 == 0. */
static void sha256_process_block(const void *buffer, size_t len, struct sha256_ctx *ctx)
{
const uint32_t *words = buffer;
size_t nwords = len / sizeof(uint32_t);
uint32_t a = ctx->H[0];
uint32_t b = ctx->H[1];
uint32_t c = ctx->H[2];
uint32_t d = ctx->H[3];
uint32_t e = ctx->H[4];
uint32_t f = ctx->H[5];
uint32_t g = ctx->H[6];
uint32_t h = ctx->H[7];
/* First increment the byte count. FIPS 180-2 specifies the possible
length of the file up to 2^64 bits. Here we only compute the
number of bytes. Do a double word increment. */
ctx->total[0] += len;
if (ctx->total[0] < (int) len)
++ctx->total[1];
/* Process all bytes in the buffer with 64 bytes in each round of
the loop. */
while (nwords > 0) {
uint32_t W[64];
unsigned int t;
uint32_t a_save = a;
uint32_t b_save = b;
uint32_t c_save = c;
uint32_t d_save = d;
uint32_t e_save = e;
uint32_t f_save = f;
uint32_t g_save = g;
uint32_t h_save = h;
/* Operators defined in FIPS 180-2:4.1.2. */
#define Ch(x, y, z) ((x & y) ^ (~x & z))
#define Maj(x, y, z) ((x & y) ^ (x & z) ^ (y & z))
#define S0(x) (CYCLIC (x, 2) ^ CYCLIC (x, 13) ^ CYCLIC (x, 22))
#define S1(x) (CYCLIC (x, 6) ^ CYCLIC (x, 11) ^ CYCLIC (x, 25))
#define R0(x) (CYCLIC (x, 7) ^ CYCLIC (x, 18) ^ (x >> 3))
#define R1(x) (CYCLIC (x, 17) ^ CYCLIC (x, 19) ^ (x >> 10))
/* It is unfortunate that C does not provide an operator for
cyclic rotation. Hope the C compiler is smart enough. */
#define CYCLIC(w, s) ((w >> s) | (w << (32 - s)))
/* Compute the message schedule according to FIPS 180-2:6.2.2 step 2. */
for (t = 0; t < 16; ++t) {
W[t] = SWAP(*words);
++words;
}
for (t = 16; t < 64; ++t)
W[t] = R1(W[t - 2]) + W[t - 7] + R0(W[t - 15]) + W[t - 16];
/* The actual computation according to FIPS 180-2:6.2.2 step 3. */
for (t = 0; t < 64; ++t) {
uint32_t T1 = h + S1(e) + Ch(e, f, g) + K[t] + W[t];
uint32_t T2 = S0(a) + Maj(a, b, c);
h = g;
g = f;
f = e;
e = d + T1;
d = c;
c = b;
b = a;
a = T1 + T2;
}
/* Add the starting values of the context according to FIPS 180-2:6.2.2
step 4. */
a += a_save;
b += b_save;
c += c_save;
d += d_save;
e += e_save;
f += f_save;
g += g_save;
h += h_save;
/* Prepare for the next round. */
nwords -= 16;
}
/* Put checksum in context given as argument. */
ctx->H[0] = a;
ctx->H[1] = b;
ctx->H[2] = c;
ctx->H[3] = d;
ctx->H[4] = e;
ctx->H[5] = f;
ctx->H[6] = g;
ctx->H[7] = h;
}
/* Initialize structure containing state of computation.
(FIPS 180-2:5.3.2) */
static void sha256_init_ctx(struct sha256_ctx *ctx)
{
ctx->H[0] = 0x6a09e667;
ctx->H[1] = 0xbb67ae85;
ctx->H[2] = 0x3c6ef372;
ctx->H[3] = 0xa54ff53a;
ctx->H[4] = 0x510e527f;
ctx->H[5] = 0x9b05688c;
ctx->H[6] = 0x1f83d9ab;
ctx->H[7] = 0x5be0cd19;
ctx->total[0] = ctx->total[1] = 0;
ctx->buflen = 0;
}
/* Process the remaining bytes in the internal buffer and the usual
prolog according to the standard and write the result to RESBUF.
IMPORTANT: On some systems it is required that RESBUF is correctly
aligned for a 32 bits value. */
static void *sha256_finish_ctx(struct sha256_ctx *ctx, void *resbuf)
{
/* Take yet unprocessed bytes into account. */
uint32_t bytes = ctx->buflen;
size_t pad;
unsigned int i;
/* Now count remaining bytes. */
ctx->total[0] += bytes;
if (ctx->total[0] < bytes)
++ctx->total[1];
pad = bytes >= 56 ? 64 + 56 - bytes : 56 - bytes;
memcpy(&ctx->buffer[bytes], fillbuf, pad);
/* Put the 64-bit file length in *bits* at the end of the buffer. */
*(uint32_t *) & ctx->buffer[bytes + pad + 4] = SWAP(ctx->total[0] << 3);
*(uint32_t *) & ctx->buffer[bytes + pad] = SWAP((ctx->total[1] << 3) | (ctx->total[0] >> 29));
/* Process last bytes. */
sha256_process_block(ctx->buffer, bytes + pad + 8, ctx);
/* Put result from CTX in first 32 bytes following RESBUF. */
for (i = 0; i < 8; ++i)
((uint32_t *) resbuf)[i] = SWAP(ctx->H[i]);
return resbuf;
}
static void sha256_process_bytes(const void *buffer, size_t len, struct sha256_ctx *ctx)
{
/* When we already have some bits in our internal buffer concatenate
both inputs first. */
if (ctx->buflen != 0) {
size_t left_over = ctx->buflen;
size_t add = 128 - left_over > len ? len : 128 - left_over;
memcpy(&ctx->buffer[left_over], buffer, add);
ctx->buflen += add;
if (ctx->buflen > 64) {
sha256_process_block(ctx->buffer, ctx->buflen & ~63, ctx);
ctx->buflen &= 63;
/* The regions in the following copy operation cannot overlap. */
memcpy(ctx->buffer, &ctx->buffer[(left_over + add) & ~63], ctx->buflen);
}
buffer = (const char *) buffer + add;
len -= add;
}
/* Process available complete blocks. */
if (len >= 64) {
/* To check alignment gcc has an appropriate operator. Other
compilers don't. */
#if __GNUC__ >= 2
# define UNALIGNED_P(p) (((uintptr_t) p) % __alignof__ (uint32_t) != 0)
#else
# define UNALIGNED_P(p) (((uintptr_t) p) % sizeof (uint32_t) != 0)
#endif
if (UNALIGNED_P(buffer))
while (len > 64) {
sha256_process_block(memcpy(ctx->buffer, buffer, 64), 64, ctx);
buffer = (const char *) buffer + 64;
len -= 64;
} else {
sha256_process_block(buffer, len & ~63, ctx);
buffer = (const char *) buffer + (len & ~63);
len &= 63;
}
}
/* Move remaining bytes into internal buffer. */
if (len > 0) {
size_t left_over = ctx->buflen;
memcpy(&ctx->buffer[left_over], buffer, len);
left_over += len;
if (left_over >= 64) {
sha256_process_block(ctx->buffer, 64, ctx);
left_over -= 64;
memcpy(ctx->buffer, &ctx->buffer[64], left_over);
}
ctx->buflen = left_over;
}
}
/* Define our magic string to mark salt for SHA256 "encryption"
replacement. */
static const char sha256_salt_prefix[] = "$5$";
/* Prefix for optional rounds specification. */
static const char sha256_rounds_prefix[] = "rounds=";
/* Maximum salt string length. */
#define SALT_LEN_MAX 16
/* Default number of rounds if not explicitly specified. */
#define ROUNDS_DEFAULT 5000
/* Minimum number of rounds. */
#define ROUNDS_MIN 1000
/* Maximum number of rounds. */
... 275 more lines ...
|
67006
|
Fri Feb 4 00:11:09 2011 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Question | Other | 2.8.1 | Strange 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...
|
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. |
67009
|
Fri Feb 4 23:48:54 2011 |
| T. Ribbrock | emgaron+elog@ribbrock.org | Bug report | Other | 2.9.0-2384 | Odd 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! |
|