Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 790 of 796  Not logged in ELOG logo
ID Date Icon Authordown Author Email Category OS ELOG Version Subject
  67216   Mon Mar 26 13:44:23 2012 Warning Achim Dreyerml10352@adreyer.comBug reportLinux2.9.1-2444segfault on empty, non-writable passwd file

 

Segfault when password file is empty and not writable a segmentation fault is generated when a new user tries to register:

 

root#  > passwd

root#  chown root.root passwd

root#  chmod 644 passwd

root#  grep -i usr elogd.cfg

root#


kernel: [515323.672377] elogd[31048]: segfault at 78 ip 00000000004ba780 sp 00007fff03cd2078 error 4 in elogd[400000+dc000]
 

I cannot reproduce this error when running within gdb.

 

  67232   Mon Apr 9 19:58:51 2012 Warning Achim Dreyerml10352@adreyer.comBug reportAll2.9.1wrong version number in spec file

localhost$ svn diff elog.spec

Index: elog.spec
===================================================================
--- elog.spec (revision 2446)
+++ elog.spec (working copy)
@@ -2,7 +2,7 @@
 
 Name:       elog
 Summary:    elog is a standalone electronic web logbook
-Version:    2.8.1
+Version:    2.9.1
 Release:    1
 License:    GPL
 Group:      Applications/Networking
 
  67486   Sat Apr 27 14:09:13 2013 Reply Achim Dreyerml10352@adreyer.comRequestLinux2.9.2Re: Support for modern Linux

Vinícius Ferrão wrote:

Hello folks,

Can we have a better support under modern Linux distributions?

I'm trying to install elog in our webserver and it's becoming a boring task. First of all theres only RPM packages. And we really don't like the Red Hat method, so we use Debian Servers. More package mainteners would be nice.

 

The software appears to be working correctly, but there are some bugs (or perhaps missing dependencies?); the init script put in /etc/rc.d/init.d is broken under Debian:

First of all because it's in /etc/rc.d.

 

The second problem is in this line:

 

# Source function library.

#. /etc/rc.d/init.d/functions

The file doesn't even exists.

 

The third problem is the echo_success; echo_failure commands that doesn't even exist. As I can see it's definitions are sourced in the functions file that doesn't exist.

 

After removing this missing commands or files from the init.d; I can call elogd script and start the daemon under root. Appears to be working...

 

And last but not least; there's a way to standardize the init script to run in other Linux distros, so we can put it to start automatically at boot time?

 

Many thanks in advance,

Vinícius Ferrão 

 

PS: I'm not asking to support any creepy distros, but to support the .deb package format and system style.

 

 

 

 

/etc/rc.d/init.d/functions is part of the initscripts.rpm - so only usable on RedHat/CentOS..

Can someone also update https://midas.psi.ch/elog/download.html ? It was last updated in 2001 and the download directory contains a debian package that was last updated 2004. If debian is not supported in a current version that bit should be removed from the page.

Kind regards,
Achim
  68497   Mon Dec 12 13:35:16 2016 Reply Aaron James Longal876@york.ac.ukQuestionWindows3.1.1-3f311c5Re: Highlight code?

Can I ask for some clarification; I would like to include code highlighting for some computational students who will be making use of ELOG. 

In the example you showed, my understanding is that you included a "Bottom text =... " entry in the forums elog config. This included the bare minimum remote call outlined by the highlightjs site. Can you clarify (as I'm having issues setting it up) should the "Bottom text=..." entry take this as a string, or should it be contained in a seperate html file in the same local directory as the cfg?

 

Daniel Sajdyk wrote:

Ok. Thanks a lot :)

Stefan Ritt wrote:

In the HTML editor, you can select the code text, then select from the "Styles" drop-down the style "Computer Code", and on the "Normal" drop-down the formatting "Formatted". This puts the code in <pre>  and <code> tags, so you don't have to manipulate HTML directly.

Daniel Sajdyk wrote:

Looks like it works :)

Code need to be put in tags:

<pre><code class="sql">...</code></pre>

but it works.

Thank you :D

 

Best Regards

Daniel Sajdyk

Stefan Ritt wrote:

I did not know about highlight.js . You can put it into any elog page with "Bottom text = ...". I tried it for this forum and put in some C code:

#include <stdio.h>
int main()
{
   // printf() displays the string inside quotation
   printf("C Programming");
   return 0;
}

Seems like this works nicely. Thanks for that hint.

 

Daniel Sajdyk wrote:

I thought so.

One  more question :) I want manually add that parser (https://highlightjs.org), but I'm newby in that and don't know where ....

I know that downloaded hightlight pack I must put into folder scripts, but where to add this line:

<script>hljs.initHighlightingOnLoad();</script>

 

Stefan Ritt wrote:

You can manually highlight code, but there is no automatic language parser.

Daniel Sajdyk wrote:

Hello :)

Is there any way to highlight code (for example php, SQL) in elogs entries?

Best Regards

Daniel Sajdyk

 

 

 

 

 

 

 

  68499   Mon Dec 12 14:04:32 2016 Reply Aaron James Longal876@york.ac.ukQuestionWindows3.1.1-3f311c5Re: Highlight code?

Thanks for the quicky reply Stefan. Yes, I had inut the same string! My error was not restarting the server; I've done this and code highlighting works fine.

Stefan Ritt wrote:

All I did was this:

Bottom Text = <link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.6.0/styles/default.min.css"><script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.6.0/highlight.min.js"></script><script>hljs.initHighlightingOnLoad();</script>

 

 

Aaron James Long wrote:

Can I ask for some clarification; I would like to include code highlighting for some computational students who will be making use of ELOG. 

In the example you showed, my understanding is that you included a "Bottom text =... " entry in the forums elog config. This included the bare minimum remote call outlined by the highlightjs site. Can you clarify (as I'm having issues setting it up) should the "Bottom text=..." entry take this as a string, or should it be contained in a seperate html file in the same local directory as the cfg?

 

Daniel Sajdyk wrote:

Ok. Thanks a lot :)

Stefan Ritt wrote:

In the HTML editor, you can select the code text, then select from the "Styles" drop-down the style "Computer Code", and on the "Normal" drop-down the formatting "Formatted". This puts the code in <pre>  and <code> tags, so you don't have to manipulate HTML directly.

Daniel Sajdyk wrote:

Looks like it works :)

Code need to be put in tags:

<pre><code class="sql">...</code></pre>

but it works.

Thank you :D

 

Best Regards

Daniel Sajdyk

Stefan Ritt wrote:

I did not know about highlight.js . You can put it into any elog page with "Bottom text = ...". I tried it for this forum and put in some C code:

#include <stdio.h>
int main()
{
   // printf() displays the string inside quotation
   printf("C Programming");
   return 0;
}

Seems like this works nicely. Thanks for that hint.

 

Daniel Sajdyk wrote:

I thought so.

One  more question :) I want manually add that parser (https://highlightjs.org), but I'm newby in that and don't know where ....

I know that downloaded hightlight pack I must put into folder scripts, but where to add this line:

<script>hljs.initHighlightingOnLoad();</script>

 

Stefan Ritt wrote:

You can manually highlight code, but there is no automatic language parser.

Daniel Sajdyk wrote:

Hello :)

Is there any way to highlight code (for example php, SQL) in elogs entries?

Best Regards

Daniel Sajdyk

 

 

 

 

 

 

 

 

 

  66660   Wed Jan 6 22:17:49 2010 Question Aaron Coutureacouture@lanl.govBug reportLinuxrev2280Problem with CRYPT+SSL and elog command line entries

I am in the process of setting up a new ELOG logbook.  I checked out rev2280 from svn.savannah.psi.ch.  I knew I wanted to encrypt passwords, so when I compiled, I used flags

 

USE_SSL=1

and

USE_CRYPT=1

 

I am running Red Hat enterprise linux 3, glibc-devel-2.3.2-95.50, openssl-devel-0.9.7a-33.25

Everything seemed to be working fine--I was able to set up logbooks using both a password file as well as write passwords and make entries to the logs.  Then I tried to use the command line 'elog' to make an entry which failed to both logbooks.

 

/opt/elog/pro/elogd -c /opt/elog/pro/dansce_fancy.cfg -l Demo1 -w <mypassword>

Would change the password in dansce_fancy.cfg and I could make entries through the web interface, but

 

elog -h acouture -s -p 8081 -w <mypassword> -l Demo1 -a Author="Aaron Couture" -a Type=Routine  -m Sampleinfo.txt -x -n 1

failed with

Error: Invalid user name or password

I got the same behaviour when I used a logbook with a user/password pair defined in a password file.

 

When I looked at the output from running elogd with the -v flag, I could see that everything was being received on the server side, but that the password did not agree with the write password in dansce_fancy.cfg

I then recompiled elog with

USE_SSL=1

USE_CRYPT=

And then the elog command line entries worked, both with write passwords and a password file (after recreating the password file and the write password).  Looking at the elog.c source code, it appears that it does not know to use crypt rather then base64_encode when USE_CRYPT is true.  elogd.c defined different behaviour if USE_CRYPT is defined.

 

Thanks,

 

Aaron Couture

 

 

  66661   Thu Jan 7 21:22:09 2010 Reply Aaron Coutureacouture@lanl.govBug reportLinuxrev2280Re: Problem with CRYPT+SSL and elog command line entries

I Aaron Couture wrote:

I have attached a possible patch--basically pirated from elogd.c  Because strlcpy needed for the crypt cares about size, do_crypt needed the size, which had not been a concern for base64_encode in elog.c   As a result, base64_encode changed slightly as well.  I think the implementation places a limit of 32 characters on passwords, which seemed to already be the limit in elogd.c  The elog.c limit appeared to be 80 characters.  I tested both SSL and SSL+CRYPT for commandline elog entries with both a logbook specific write password as well as username/password combo in a password file.

 

AJC

 

 

I am in the process of setting up a new ELOG logbook.  I checked out rev2280 from svn.savannah.psi.ch.  I knew I wanted to encrypt passwords, so when I compiled, I used flags

 

USE_SSL=1

and

USE_CRYPT=1

 

I am running Red Hat enterprise linux 3, glibc-devel-2.3.2-95.50, openssl-devel-0.9.7a-33.25

Everything seemed to be working fine--I was able to set up logbooks using both a password file as well as write passwords and make entries to the logs.  Then I tried to use the command line 'elog' to make an entry which failed to both logbooks.

 

/opt/elog/pro/elogd -c /opt/elog/pro/dansce_fancy.cfg -l Demo1 -w <mypassword>

Would change the password in dansce_fancy.cfg and I could make entries through the web interface, but

 

elog -h acouture -s -p 8081 -w <mypassword> -l Demo1 -a Author="Aaron Couture" -a Type=Routine  -m Sampleinfo.txt -x -n 1

failed with

Error: Invalid user name or password

I got the same behaviour when I used a logbook with a user/password pair defined in a password file.

 

When I looked at the output from running elogd with the -v flag, I could see that everything was being received on the server side, but that the password did not agree with the write password in dansce_fancy.cfg

I then recompiled elog with

USE_SSL=1

USE_CRYPT=

And then the elog command line entries worked, both with write passwords and a password file (after recreating the password file and the write password).  Looking at the elog.c source code, it appears that it does not know to use crypt rather then base64_encode when USE_CRYPT is true.  elogd.c defined different behaviour if USE_CRYPT is defined.

 

Thanks,

 

Aaron Couture

 

 

 

Attachment 1: elogc.patch
64c64
< void base64_encode(char *s, char *d)
---
> void base64_encode(unsigned char *s, unsigned char *d, int size)
66a67
>    unsigned char *p;
68c69
<    pad = 3 - strlen(s) % 3;
---
>    pad = 3 - strlen((char *) s) % 3;
70a72
>    p = d;
86a89,90
>       if (d - p >= size - 3)
>         return;
92a97,106
> void do_crypt(char *s, char *d, int size)
> {
> #ifdef HAVE_CRYPT
>    strlcpy(d, crypt(s, "el"), size);
> #else
>    base64_encode((unsigned char *) s, (unsigned char *) d, size);
> #endif
> }
> 
> 
382c396
<    char str[256], *ph, *ps;
---
>    char str[256], encrypted_passwd[32], *ph, *ps;
422,423c436,437
<       base64_encode(passwd, str);
<       sprintf(request + strlen(request), "wpwd=%s;", str);
---
>       do_crypt(passwd, encrypted_passwd, sizeof(encrypted_passwd) );
>       sprintf(request + strlen(request), "wpwd=%s;", encrypted_passwd);
439,440c453,454
<       base64_encode(upwd, str);
<       sprintf(request + strlen(request), "upwd=%s;", str);
---
>       do_crypt(upwd, encrypted_passwd, sizeof(encrypted_passwd) );
>       sprintf(request + strlen(request), "upwd=%s;", encrypted_passwd);
628c642
<    char host_name[256], boundary[80], str[80], *p, *old_encoding;
---
>    char host_name[256], boundary[80], str[80], encrypted_passwd[32], *p, *old_encoding;
801c815
<       base64_encode(upwd, str);
---
>       do_crypt(upwd, encrypted_passwd, sizeof(encrypted_passwd) );
803c817
<               "%s\r\nContent-Disposition: form-data; name=\"upwd\"\r\n\r\n%s\r\n", boundary, str);
---
>               "%s\r\nContent-Disposition: form-data; name=\"upwd\"\r\n\r\n%s\r\n", boundary, encrypted_passwd);
885,886c899,900
<       base64_encode(passwd, str);
<       sprintf(request + strlen(request), "Cookie: wpwd=%s\r\n", str);
---
>       do_crypt(passwd, encrypted_passwd, sizeof(encrypted_passwd) );
>       sprintf(request + strlen(request), "Cookie: wpwd=%s\r\n", encrypted_passwd);
  66663   Fri Jan 8 18:26:56 2010 Reply Aaron Coutureacouture@lanl.govBug reportLinuxrev2280Re: Problem with CRYPT+SSL and elog command line entries

Aaron Couture wrote:

I Aaron Couture wrote:

There was some sloppiness in the original patch--__USE_XOPEN wasn't defined, but worked when elog wasn't compiled alone.  Now the appropriate ifndef/define statements are in elog.c

 

I have attached a possible patch--basically pirated from elogd.c  Because strlcpy needed for the crypt cares about size, do_crypt needed the size, which had not been a concern for base64_encode in elog.c   As a result, base64_encode changed slightly as well.  I think the implementation places a limit of 32 characters on passwords, which seemed to already be the limit in elogd.c  The elog.c limit appeared to be 80 characters.  I tested both SSL and SSL+CRYPT for commandline elog entries with both a logbook specific write password as well as username/password combo in a password file.

 

AJC

 

 

I am in the process of setting up a new ELOG logbook.  I checked out rev2280 from svn.savannah.psi.ch.  I knew I wanted to encrypt passwords, so when I compiled, I used flags

 

USE_SSL=1

and

USE_CRYPT=1

 

I am running Red Hat enterprise linux 3, glibc-devel-2.3.2-95.50, openssl-devel-0.9.7a-33.25

Everything seemed to be working fine--I was able to set up logbooks using both a password file as well as write passwords and make entries to the logs.  Then I tried to use the command line 'elog' to make an entry which failed to both logbooks.

 

/opt/elog/pro/elogd -c /opt/elog/pro/dansce_fancy.cfg -l Demo1 -w <mypassword>

Would change the password in dansce_fancy.cfg and I could make entries through the web interface, but

 

elog -h acouture -s -p 8081 -w <mypassword> -l Demo1 -a Author="Aaron Couture" -a Type=Routine  -m Sampleinfo.txt -x -n 1

failed with

Error: Invalid user name or password

I got the same behaviour when I used a logbook with a user/password pair defined in a password file.

 

When I looked at the output from running elogd with the -v flag, I could see that everything was being received on the server side, but that the password did not agree with the write password in dansce_fancy.cfg

I then recompiled elog with

USE_SSL=1

USE_CRYPT=

And then the elog command line entries worked, both with write passwords and a password file (after recreating the password file and the write password).  Looking at the elog.c source code, it appears that it does not know to use crypt rather then base64_encode when USE_CRYPT is true.  elogd.c defined different behaviour if USE_CRYPT is defined.

 

Thanks,

 

Aaron Couture

 

 

 

 

Attachment 1: elogc.patch
26a27,30
> #ifndef __USE_XOPEN
> #define __USE_XOPEN             /* needed for crypt() */
> #endif
> 
64c68
< void base64_encode(char *s, char *d)
---
> void base64_encode(unsigned char *s, unsigned char *d, int size)
66a71
>    unsigned char *p;
68c73
<    pad = 3 - strlen(s) % 3;
---
>    pad = 3 - strlen((char *) s) % 3;
70a76
>    p = d;
86a93,94
>       if (d - p >= size - 3)
>         return;
92a101
> 
182a192,201
> 
> void do_crypt(char *s, char *d, int size)
> {
> #ifdef HAVE_CRYPT
>    strlcpy(d, crypt(s, "el"), size);
> #else
>    base64_encode((unsigned char *) s, (unsigned char *) d, size);
> #endif
> }
> 
382c401
<    char str[256], *ph, *ps;
---
>    char str[256], encrypted_passwd[32], *ph, *ps;
422,423c441,442
<       base64_encode(passwd, str);
<       sprintf(request + strlen(request), "wpwd=%s;", str);
---
>       do_crypt(passwd, encrypted_passwd, sizeof(encrypted_passwd) );
>       sprintf(request + strlen(request), "wpwd=%s;", encrypted_passwd);
439,440c458,459
<       base64_encode(upwd, str);
<       sprintf(request + strlen(request), "upwd=%s;", str);
---
>       do_crypt(upwd, encrypted_passwd, sizeof(encrypted_passwd) );
>       sprintf(request + strlen(request), "upwd=%s;", encrypted_passwd);
628c647
<    char host_name[256], boundary[80], str[80], *p, *old_encoding;
---
>    char host_name[256], boundary[80], str[80], encrypted_passwd[32], *p, *old_encoding;
801c820
<       base64_encode(upwd, str);
---
>       do_crypt(upwd, encrypted_passwd, sizeof(encrypted_passwd) );
803c822
<               "%s\r\nContent-Disposition: form-data; name=\"upwd\"\r\n\r\n%s\r\n", boundary, str);
---
>               "%s\r\nContent-Disposition: form-data; name=\"upwd\"\r\n\r\n%s\r\n", boundary, encrypted_passwd);
885,886c904,905
<       base64_encode(passwd, str);
<       sprintf(request + strlen(request), "Cookie: wpwd=%s\r\n", str);
---
>       do_crypt(passwd, encrypted_passwd, sizeof(encrypted_passwd) );
>       sprintf(request + strlen(request), "Cookie: wpwd=%s\r\n", encrypted_passwd);
ELOG V3.1.5-2eba886