Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 215 of 806  Not logged in ELOG logo
icon5.gif   Naming a Notebook KTAG Wipes Out Formatting. Why?, posted by Phil Rubin on Sat May 22 20:44:33 2021 

An experiment's ELOG installation, using the default theme, names logbooks after its subsystem's acronyms.  One subsystem is referred to as KTAG, but when this name (or its lowercase version) is used for a logbook name, the logbook appears unformatted.  Changing the name, even to K-TAG, works fine.  Nothing close to KTAG appears in elog.css.  Does anyone know why this happens and whether it is possible or worth the while to get around the "problem"?

icon5.gif   when using webserver authentication, how can I restrict the users that can edit any given elog?, posted by Christian Ospelkaus on Sat Jun 19 18:38:21 2021 

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

    icon2.gif   Re: when using webserver authentication, how can I restrict the users that can edit any given elog?, posted by Christian Ospelkaus on Sun Jun 20 14:38:06 2021 

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

 

    icon2.gif   Re: Logfile not registering entry numbers?, posted by Sergio Navarrete on Thu Dec 16 08:23:22 2021 

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?

 

 

 

 

 

    icon5.gif   Re: Spurious characters in the searched string, posted by Phil Rubin on Mon Jan 3 19:11:08 2022 

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

 

icon5.gif   Paid version , posted by Vasio on Mon Jul 4 12:34:13 2022 

Good day all ,

does Elog has a paid version that is not open soureced 

 

regards


William Vasio 

    icon2.gif   Re: Paid version , posted by Stefan Ritt on Thu Jul 7 10:56:39 2022 

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 

 

icon5.gif   Too many redirects when running behind load balancer?, posted by Tamas Gal on Tue Jul 19 11:01:00 2022 

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