Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 211 of 801  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Versiondown Subject
  69373   Sat Jun 19 18:38:21 2021 Question Christian Ospelkauschristian.ospelkaus@iqo.uni-hannover.deQuestionAll3.1.3when using webserver authentication, how can I restrict the users that can edit any given elog?

Dear elog users & developers,

the subject line says it all: when using webserver authentication, how is it possible to restict access of users to any given elog? Only using the apche rules? Admin user and Login user do not seem to be doing anything for me. I am using elog as packaged by debian for buster, using an apache ssl proxy. Thank you for providing this software,

Christian

  69374   Sun Jun 20 14:38:06 2021 Reply Christian Ospelkauschristian.ospelkaus@iqo.uni-hannover.deQuestionAll3.1.3Re: when using webserver authentication, how can I restrict the users that can edit any given elog?

Dear all,

I figured it out. Current global config is (using kerberos instead)

[global]
port = 8081
Default encoding = 0
SSL = 0
Authentication = Kerberos
URL = https://my_url_here/
interface = 127.0.0.1
Password file = global.pwd
SMTP host = my_mail_host
Logfile = /var/log/elog.log
Logging level = 3
User = elog
Grp = elog

Best,

Christian

 

 

Christian Ospelkaus wrote:

Dear elog users & developers,

the subject line says it all: when using webserver authentication, how is it possible to restict access of users to any given elog? Only using the apche rules? Admin user and Login user do not seem to be doing anything for me. I am using elog as packaged by debian for buster, using an apache ssl proxy. Thank you for providing this software,

Christian

 

  69449   Thu Dec 16 08:23:22 2021 Reply Sergio Navarretesergionavarrete@gmail.comQuestionWindows3.1.3Re: Logfile not registering entry numbers?

It seems that the latest Windows binary still predates this fix. Will there be a new installer soon? Thanks for your support.

Stefan Ritt wrote:

I finally found some time to fix that bug. Was just that the log file hat #0, the bug should not have had any ohter side effects. Now the logfile is fine.

David Pilgram wrote:

As a regular elog (ab)user, I have seen this behaviour from time to time.  So far as I recall, the cause actually is that a normal entry is looking for the entry in the "Reply to" field of the normal entry in the yymmdda.log file.  When that entry does not exist, then I see a duplicate line of an entry with entry "#0", in emboldened black type.  I did have a screenshot, but cannot find it for now. 

A quick (relative term, that) search usually finds the entry which references the missing "Reply to" line, and editing that, all is well.  I'm not sure how this can happen, but it does.  NB, I'm still on elog 2.9.2 so I don't know how the draft facility works and possibly enhances the possibility of this issue.

 

Note that this is different to the case (rather more frequent) where the entry in  the "In reply to" field is missing.  This causes elog to go into a continuous loop and only the strongest measures  ("kill -9 xxxx in linux) will break this out.  This can happen more frequently as if you delete a thread with a large number (>40?) of entries, elog crashes, but more importantly, hasn't finished the job.  Clicking on the remenents of the thread (which are usually the later entries) causes the endless loop.

Andreas Luedeke wrote:

It looks like you've found a bug in ELOG. I've checked my elog.log and see that all NEW entry lines show "#0".

I've looked into the code: the message is written before the new entry is submitted, and only then the entry ID is defined.
For new entries one would need to make the logging print line later - but that would blow up the code.
The message IDs are correct for saving drafts and editing entries. I'll discuss with Stefan if that should be fixed.
 
Andreas
 
Sergio Navarrete wrote:

I have configured a logbook with the logfile on, but when a user replies to an entry the line logged goes

Date Time [User@IP] {Logbook} NEW entry #0

How can I make the #0 be the real entry number for the reply?

 

 

 

 

 

  69455   Mon Jan 3 19:11:08 2022 Question Phil Rubinrubinp@cern.chQuestionLinux3.1.3Re: Spurious characters in the searched string

Hi,

Ten years later...this problem shows up in my installation behind Apache, affecting only drop-down menu searches.  Test installations with elog serving itself do not show the problem, so I presume it has something to do with Apache configuration, re-routing, etc.  Unfortunately, this thread did not provide any details of the solution.

The problem looks like this:

Type:    %255ERoutine%2524
or, in the url:

https://servername/?Type=%25255ERoutine%252524

Removing 2525 from front and back of the url makes everything work.

The only rewrite entries in the configuration file(s) are:

  ## Rewrite rules
  RewriteEngine On

  #redirect non-SSL traffic to SSL site
  RewriteCond %{HTTPS} off
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Perhaps there's a rewrite rule that could be added to block the 2525?  Something like:

    RewriteCond %{QUERY_STRING} 2525
    RewriteRule .* - [F,L]

I don't have a lot of experience configuring Apache, so any suggestions would be welcome.

Thanks.

Phil

Olivier Callot wrote:

 

Olivier Callot wrote:

 

Stefan Ritt wrote:

 

Olivier Callot wrote:

Hi,

We have a problem with the search command: Since our last upgrade to v2.9.0-2418 the searched string is pre- and postfixed with ASCII character expressed in % format, see the attached image. The searched string is prefied with %255E and postfxed by %2524 in the URL. And teh search fails. This affects searches from drop-down menus.

Thanks in advance.

Strange. In this forum it works without extra characters. Just try it yourself. Do you have any strange configuration? Can you send me a minimal elogd.cfg which produces that error, maybe derived from the example elogd.cfg from the distribution.

- Stefan 

 Well, It may be our implementation of re-routing web requests: The requested string in elog  is prefixed by %5E (^) and postfixed by %24 ($). But in my case, the '%' is again escaped as %25 so the prefix becomes %255E that is not understood by elog as being '^' ...

I will see with my experts in routing if this is something that can be fixed in our configuration. But when elog processes the input string, it should un-escape these characters and find back the '^', no?

 It turned out to be a setting of our re-routing of requests that re-escaped the '%'. Sorry for the noise. Cheers

 

  69539   Mon Jul 4 12:34:13 2022 Question Vasiovasio.william@gmail.comInfoWindows3.1.3Paid version

Good day all ,

does Elog has a paid version that is not open soureced 

 

regards


William Vasio 

  69541   Thu Jul 7 10:56:39 2022 Reply Stefan Rittstefan.ritt@psi.chInfoWindows3.1.3Re: Paid version

There is only an open source version.

Vasio wrote:

Good day all ,

does Elog has a paid version that is not open soureced 

 

regards


William Vasio 

 

  69542   Tue Jul 19 11:01:00 2022 Question Tamas Galtgal@km3net.deQuestionLinux3.1.3Too many redirects when running behind load balancer?

We were running ELOG for many many years in our experiments and the instance was operated on a Debian XEN server as a container. I am now trying to migrate it into our Docker Swarm cluster and I am using the https://hub.docker.com/r/de1lz/elog-docker Docker image, which works very well with our logbooks when I run it as a single container. However, when I put the container behind my load balancer (HAProxy) using the simple HTTP mode (which works very well for all the other HTTP-based services) with this simple configuration:

backend be_elog.km3net.de
    mode http
    server-template km3net-elog- 1 km3net-elog_elog:8080 check resolvers docker init-addr libc,none

I get a "too many redirects" error when I try to access one of the logbooks. The starting page works fine, but every other link leads to a pile-up of redirects.

Here is the current instance running, where you can see the behaviour: https://elog.test.km3net.de (all log entries deleted and only two logbooks activated)

My question is: what kind of redirect could go wrong here? I don't know how the internal HTTP server of ELOG works, but maybe someone faced similar issues.

My ELOG configuration is also pretty basic, and as I wrote above, everything works when I run it without the load balancer (single instance at the moment). Here is the top part of the configuration, it contains a few dozens of logbooks but they are configured the very same way. 

;User Settings
;=============
Password file = login.xml
Admin user = km3net_admin
Self register = 0
Allow password change = 0
Allow config = km3net_admin

;Group Settings:
;====
Group ELOGKM3NET = Operations IT, Operations FR

[Operations IT]
Subdir = Operations_IT
Theme = default
Default encoding = 0
Comment = KM3NeT IT Detector Operations
Attributes = Author, Type, Subject
Options Author = A, B, C
Options Type = PPM-DOM, PPM-DU, Comment, Power cut, New run
Extendable Options = Type
Required Attributes = Author, Type, Subject
Page Title = ELOG - $subject
;Sort Attributes = Author, Type
Quick filter = Date, Type, Author
Resubmit default = 2
Reverse sort = 1
Menu commands = List, New, Edit, Reply, Duplicate, Find, Config, Help, Logout
Preset on first reply Subject = Re: $Subject
Preset on reply author =

 

  69543   Tue Jul 19 11:13:09 2022 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux3.1.3Re: Too many redirects when running behind load balancer?

Probably you need a setting

URL = https://elog.test.km3net.de

or so in your elogd.cfg file.

Stefan

Tamas Gal wrote:

We were running ELOG for many many years in our experiments and the instance was operated on a Debian XEN server as a container. I am now trying to migrate it into our Docker Swarm cluster and I am using the https://hub.docker.com/r/de1lz/elog-docker Docker image, which works very well with our logbooks when I run it as a single container. However, when I put the container behind my load balancer (HAProxy) using the simple HTTP mode (which works very well for all the other HTTP-based services) with this simple configuration:

backend be_elog.km3net.de
    mode http
    server-template km3net-elog- 1 km3net-elog_elog:8080 check resolvers docker init-addr libc,none

I get a "too many redirects" error when I try to access one of the logbooks. The starting page works fine, but every other link leads to a pile-up of redirects.

Here is the current instance running, where you can see the behaviour: https://elog.test.km3net.de (all log entries deleted and only two logbooks activated)

My question is: what kind of redirect could go wrong here? I don't know how the internal HTTP server of ELOG works, but maybe someone faced similar issues.

My ELOG configuration is also pretty basic, and as I wrote above, everything works when I run it without the load balancer (single instance at the moment). Here is the top part of the configuration, it contains a few dozens of logbooks but they are configured the very same way. 

;User Settings
;=============
Password file = login.xml
Admin user = km3net_admin
Self register = 0
Allow password change = 0
Allow config = km3net_admin

;Group Settings:
;====
Group ELOGKM3NET = Operations IT, Operations FR

[Operations IT]
Subdir = Operations_IT
Theme = default
Default encoding = 0
Comment = KM3NeT IT Detector Operations
Attributes = Author, Type, Subject
Options Author = A, B, C
Options Type = PPM-DOM, PPM-DU, Comment, Power cut, New run
Extendable Options = Type
Required Attributes = Author, Type, Subject
Page Title = ELOG - $subject
;Sort Attributes = Author, Type
Quick filter = Date, Type, Author
Resubmit default = 2
Reverse sort = 1
Menu commands = List, New, Edit, Reply, Duplicate, Find, Config, Help, Logout
Preset on first reply Subject = Re: $Subject
Preset on reply author =

 

 

ELOG V3.1.5-3fb85fa6