Hello!

How can I make appear the text formatting panel (above the main text body field) inside entries?
In my logbook I do not have it (also in minimized form) and I do not find a way to enable it via elogd.cfg.

Thank you!
- Mariia

You can manually modify the CSS style to adjust column widths. Locate elog.css which resides under elog/themes/default/elog.css, then find the class “.listtitle”, and modify the line

width: 0%;

to something like

width: 10%;

you can play with the width until it suits your needs. After each change, you have to reload the page in the browser to see the effect.

If you only want to change the width of a specific column, add following lines to your elog.css:

.listtitle:nth-child(4) {
  width:30%;
}

where ‘4” is for example the 4th column. You can have several of these statements for different columns.

To hide the text, use the option 'summary lines' as described in the manual.
 

Thank you!

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

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

Hello,

I am trying first time to use the tool /usr/bin/elog. From the documentation is not clear to if everything must be in quotes or not, if every attribute requires -a.

Here is how my attempt looks like (changing actual data by fake one):

      /usr/bin/elog -h elog-1.matrix.com -l LogBook -u jcaballero mypassword -a Team='Team Name Here' Category='Category Here' -a 'Affected service'='Name of affected service here' -a Criticality=Normal -a 'Oncall Documentation'='No modifications required' -a Subject='here is the subject line' 'here is the text'

I just get "Error transmitting message". 

Attributes Team and Category are of checkbox type. Attributes Criticality and Oncall Documentation are of radio type.

What is wrong with my command attempt?

Thanks a lot in advance.

Cheers,

Jose

Please issue the elog command with an added "-v" flag and post the output here.

Stefan

Hi Stefan,

Here is the, I believe, relevant part of the output:

-------------------------------------------------

Response received:
HTTP/1.1 404 Not Found
Date: Tue, 07 Dec 2021 07:26:07 GMT
Server: Apache/2.4.6 (Scientific Linux) OpenSSL/1.0.2k-fips PHP/5.4.16
Content-Length: 204
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /LogBook/ was not found on this server.</p>
</body></html>

-------------------------------------------------

Note that the URL https://elog-1.matrix.com/LogBook/ exists and works. That's how we create all our log entries via web browser. 

Thanks,

Jose

If you need HTTPS then you must specify the "-s" option.

You could have looked into the help of the elog command:

This is what I get with -s:

---------------------------------

Successfully connected to host elog-1.matrix.com, port 80
elogd server does not run SSL protocol

---------------------------------

And the entry has not been created. 

If you use HTTPS, you have to connect to port 443 of your server, using the "-p" option.

Furthermore, you run under an Apache server, right? How do you do the redirecting to elogd? I guess you specified a subdir in the URL named /LogBook to redirect to elogd. The you use another part of the URL to select the logbook, which again might be "LogBook". Is that correct? So your full URL in the browser would be https://elog-1.matrix.com/LogBook/LogBook. If that's the case, you have to tell the elog tool that you use a subdir in the URL using the "-d" option.

Stefan

Not really. The full URL in the browser is https://elog-1.matrix.com/LogBook. That's why I am trying with "-h elog-1.matrix.com -l LogBook"

I have just tried with -p, here is the full output:

The reply from the server

Response received:
HTTP/1.1 404 Not Found
Date: Tue, 07 Dec 2021 07:26:07 GMT
Server: Apache/2.4.6 (Scientific Linux) OpenSSL/1.0.2k-fips PHP/5.4.16
Content-Length: 204
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /LogBook/ was not found on this server.</p>
</body></html>

comes definitively from the Apache browser (See the "Server" line). So apparently it does not succeed in forwarding your request to the elogd server. Look into the Apache log and see what's wrong there.

I don't see anything in httpd logs.

I am just reusing an entry I created via web, so the attributes are correct. Nothing is missing, correct spelling, etc.  I keep trying. 

BTW, I have just realized that the output of "elog -h" does not "man log", which is the one I have been using so far. Which one is correct? 

But this is real progress! Now elog successfully connected, and all your data was transmitted, but elogd refused your content.

A possible explanation is that one required attribute of this logbook was not provided in your elog command, or that one value of an attribute does not match any allowed value for that attribute.
Here we can only help if you post the config of your logbook.

Cheers, Andreas

PS: you did not provide the -s option?!? Just in case you lack the knowledge: providing a port number 443 does not imply the use of the SSL protocoll.

Ok, you Apache listes on two ports. On port 80 with HTTP and on port 443 with HTTPS. If you connect to port 80, there is no fowarding to elogd, that's why Apach complains 

The requested URL /LogBook/ was not found on this server.

On port 443 using the HTTPS protocol (with -s) you apparently get forwarded to elogd. The fact that you succeeded to connect to Apache without the "-s" flag tells me that your Apache listens on port 443 with the HTTP protocol, not HTTPS. First I would configure Apache such that is also forwards port 80 to elogd. Then you don't have to use HTTPS at all (at least for testing). 

Then I agree with Andreas that you might be missing an attribute or so. You can also use "curl" instead of "elog" which might tell you more details. See https://elog.psi.ch/elogs/Forum/68597

Thanks for the comments. I will pass them to the admins. 

With curl, I get this as part of the output:

Hopefully the admins can help. Fingers crossed. 

That reply indicates that the login was not successful. So something went wrong with the authentication. You can try to switch off passwords to see if that makes a difference.

Have you tried to connect directly to elogd and not going through Apache? 

Nope. How? Is it documented? 

It is the default. If you install ELOG on your PC and run it, then every access will be directly to the ELOG web service. If you want to have Apache inbetween, it is some extra effort.

Hi Andreas,

I realize from your response that my question was not clear. I was not asking how to get it. Note that I am just a regular user, I am not the administrator of the service.

My question was about how to use it. From the man page, or from the explanation in the Administration Guide, it is not clear to me how to pass the same arguments I have been trying for /usr/bin/elog. For example, how to pass the list of attributes. I don't see a "-a" option for elogd. 

Thanks.

Now you've totally lost me.

elogd is a web service. You connect to it with a web browser. You don't pass arguments at startup of the service that refers to specific atrributes. I have no idea what you intend to do, you need to explain a lot more.

Hi Andreas. 

It seems I didn't fully understand the comment by Stefan when he said "Have you tried to connect directly to elogd and not going through Apache?". My bad. 

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?

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".

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.

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.

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

Is there any potential impact/concern with the Log4j exploit in Elog applications?

ELog does not use the Log4j library so no issue there. If you run a web server like Apache in front of ELog, you however have to check if you use log4j there.

Hello,

I am interested in finding a preferrably single-click way to capture a screenshot and posting it automatically to a new elog entry . I would be doing this from Windows. Is this possible?

Thanks

I am no Windows expert. An option is to write your own application and use the "elog" command to post the output of the application to your ELOG.
There is as well a python library to access ELOG via http: https://github.com/paulscherrerinstitute/py_elog

Hi,

In our setup we have multiple logbooks. I want a convenient way to search all logbooks for an attribute (in our case with the name Sample-ID) by just clicking it in the list display of any logbook.Therefore, in the [global] section I put "List Change Sample-ID = <a href="https://ourelog.com/$logbook/?all=1&Sample-ID=$Sample-ID"</a>. This transforms the attribute in list display into a hyperlink to the search results page. So far this works fine. In the results page, of course the option also applies, meaning the attribute is replaced by the link as well. But here something odd happens and the replacement does not work. The intended behavior is to replace $logbook in the link with the name of the logbook. Sometimes, however, the replacement yields something like "logbook" (missing $ and thus not replacing anything) or even weirder something like "60logbook". I have no idea what causes this.

This problen drives me crazy. Under some circumstances the List Change <attribute> function does not replace $attribute. It happens at random circumstances when I use the Find function to search all logbooks. In the resulting list, it fails reproducibly for certain entries of certain logbooks. But I cannot find what is special about those lokbooks or entries. In different Find requests it works perfectly fine. 

I have added a screenshot. The yellow button is created by this command in [global] for all logbooks. It makes no difference to define it in all [logbook] sections. I would really appreciate help to debug this. 

List Change Sample-ID        = <a href="page?mode=summary&reverse=1&all=1&Sample-ID=$Sample-ID$&sort=Date" class="id_div">$Sample-ID</a>