Recently I have had problems with ELOG not accepting the certificates (in this case from https://letsencrypt.org/) probably due to the old version of the SSL library of the binary distribution for Windows.
I have tried to follow the instructions to set up ELOG to work with Apache but they are probably old.
I have a simple solution for the Apache installation of XAMPP, the example is for two separate logbooks using each its own ELOG service on the same server:

1. I have set up the two ELOG to run as http://my.server.example.com:8080/ and as http://my.server.example.com:8081/

2. in c:\xampp\apache\conf\httpd.conf I have enabled the following (I am not sure if all the modules are really needed but this works for me):

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule headers_module modules/mod_headers.so
LoadModule proxy_html_module modules/mod_proxy_html.so
LoadModule xml2enc_module modules/mod_xml2enc.so

3. still in c:\xampp\apache\conf\httpd.conf, at the very end of the file I added the following:

ProxyRequests off

Redirect permanent /app1 https://my.server.example.com/app1/
ProxyPass /app1/ http://my.server.example.com:8080/
ProxyHTMLURLMap http://my.server.example.com:8080 /app1

Redirect permanent /app2 https://my.server.example.com/app2/
ProxyPass /app2/ http://my.server.example.com:8081/
ProxyHTMLURLMap http://my.server.example.com:8081 /app2

This way I can now connect to the two ELOG using https://my.server.example.com/app1/ and https://my.server.example.com/app2/ without troubles and no additional setting to either the configuration files of ELOG nor any need for virtual hosts, ...

I hope this might be of use.

Our setup uses "Authentication=Webserver" + no automatic user registration. Thus, logbook admins should add a user by clicking "Config"  and then "New user". However, no matter what they fill in in the "new user " dialog, as soon as they hit "Save" an error pops up saying that their username (the admin one, not the new one) already exists. I found the following code:

int save_user_config(LOGBOOK * lbs, char *user, BOOL new_user)
{
   char file_name[256], str[256], *pl, user_enc[256], new_pwd[80], new_pwd2[80], smtp_host[256],
       email_addr[256], mail_from[256], mail_from_name[256], subject[256], mail_text[2000], str2[256],
       admin_user[80], url[256], error[2000], sid[32];
   int i, self_register, code, first_user;
   PMXML_NODE node, subnode, npwd; 

   /* if we outsourced the authentication, use external username */
   getcfg(lbs->name, "Authentication", str, sizeof(str));
   if (stristr(str, "Webserver")) {
      /* do not allow HTML in user name */
      strencode2(user_enc, http_user, sizeof(user_enc));
   } else {
      strencode2(user_enc, user, sizeof(user_enc));
   }
 

which seems to be the culprit:  the admin user is logged using his/her Webserver (http_user) credentials and this overrides anything that he/she might fill in.  If I remove the "Authentication" check then I can create a new user without problems.  So, how to fix this? should the "Authentication=Webserver" check be extended with a self/auto registration check?

Unfortunately I locallly don't have Webserver authentication, so I cannot check or debug. If you send me a diff that works for you, I'm happy to incorporate it.

Stefan

here's the patch that I use to enable  use creation and deletion in combination with Webserver authentication.

The idea behind the patch is that if the user logged in via  "http_user" is an elog admin, then {s}he is allowed to save a random user configuration, including creating or deleting a user.

Thanks for your patch, I committed it.

Stefan

I expanded an elog server from 1 to 3 logbooks. For each logbook there is a separate password file defined. 

When I try to add a new user in one of the 2 new logbooks using config => new user, it adds the user to the password file for the original logbook.

Have verified that access to the logbooks is controlled via the separate password files. If it would help to provide an example of the elogd.cfg or if I need to clarify further, let me know. 

Any suggestions welcome.

Thanks. Mark.

Can you try the "top groups" option, which means putting each logbook into a separate top group as described in the documentation. For us this works well, new users are only added to the right password file. There is however the problem that as admin you might be logged in to several logbooks (as remembered in your browser via cookies), so you might want to log out from all logbooks first (or clear all cookies of elog), then log in to one logbook and add the user there. In worst case you still can modify the password file by hand, they are plain ASCII files. Only the password has to be entered later since it's encrypted.

Stefan

what is the default value for "Author" when replying to a log entry ?  I now see that for each reply to a log entry, the value of "Author" is set to the value of the author of the original entry - this makes it very hard to see which user has replied to a particular log entry, especially when users start replying to replies etc.

This is with elog 3.1.4-3 on CentOS 7

As you can see, on this forum the author for replies is correct. This is done via the config option:

Preset on reply Author = $long_name

Excellent, exactly what I was looking for, many thanks!

Hello,

I try to start elog at Ubuntu 18.04. When I run sudo /usr/local/sbin/elogd -D -c /usr/local/elog/elogd.cfg I get following error:
/usr/lib/libssl.so.10: version `libssl.so.10' not found (required by /usr/local/sbin/elogd)

I checked following:
ls -l /usr/lib/libssl.so.10
lrwxrwxrwx 1 root root 41 Jan 29 08:24 /usr/lib/libssl.so.10 -> /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
ls -l /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
-rw-r--r-- 1 root root 424664 Aug 24 18:16 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

What's going wrong? And how to solve the problem?

Best,
Carsten

Looks like you don't have shared libraries correctly configured on your system. Try "ldconfig" on your system or link elogd statically (google how to do that).

Stefan

sudo ldconfig didn't solve the problem

Is there any other solution than elog static linking?

downloading the sources and building them on the target system solved the problem

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