Is there anything I can do about this?

kernel:  2.6.32-279.14.1.el6.x86_64

ldd (GNU libc) 2.12

/lib64/libc.so.6

/usr/lib64/libssl.so.10

rpm -i elog-latest.i386.rpm

error: Failed dependencies:

libc.so.6 is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.0) is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.1) is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.1.3) is needed by elog-3.1.1-1.i386

libc.so.6(GLIBC_2.3) is needed by elog-3.1.1-1.i386

libssl.so.6 is needed by elog-3.1.1-1.i386

I attempted instead to build from the tar ball, and, except for a "fatal" git error, make built elogd, elog, and elconv.  I put the first in /usr/local/sbin, and the latter two in /usr/local/bin, and then restarted elogd, but this didn't work:

Service Temporarily Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.

So, I backed these out and restored the previous executables, and access to the elog was restored, and the elogd.cfg accessed is the original one, but all logbooks are empty and requiring authentication.  The logbook directories still contain all the old entries, so I'm not sure what has happened.

Thanks for your advice.

Phil

OK.  I found the source of the logbook problem in an exchange from May 2015, so no need to answer this one.

But I would like to be able to upgrade to 3.x from 2.9, so any help with this will be much appreciated.

Phil

Our configuration sends out e-mail notifications based on a hierarchy of attributes, and works fine with WEB submissions, but not with client utility submissions (no notifications are sent; the log doesn't show it even trying to send any: 14-Jul-2017 18:36:01 [rubinp@nn.nn.nn.nn] {Notebook} NEW entry #0) .  Since notification is the default (suppression requires -x), I presume there is something wrong with the way we're going about this.  Can you see what it is?  Could it be the parentheses in the type Problem(s), which have to be sent at the shell in the client command as Type=Problem\(s\)?

[global]

.

Suppress Email to users = 1
.

[Notebook]

.

Attributes = Author, Type, Category, Subject
Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = ... TDAQ ...

.

{1} Email Category TDAQ =
{2} Email Category TDAQ = user1@aa.bb, user2@cc.dd,...

{3} Email Category TDAQ =
.

Use Email Subject = Elog Notice: $subject
 

Command:  /usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"

Thank you for responding.

I thought I provided the command at the end of the note:

/usr/local/bin/elog -h host -p port -l Notebook -u user passwd -a Author="Author" -a Type=Type -a Category=Category -a Subject="subject" "text"

This results in an entry being appropriately logged in Notebook with the correct author, type, category, subject, and text.  The only problem is that, when the type is such that email notification should be sent to the list associated with category, it is not sent.

For the record, I reconfigured elogd.conf so that parentheses are no longer there, but this made no difference, so this isn't the problem.

Sorry for forgetting these details:  bash shell; linus version 2.6.32-696.el6.x86_64

I didn't realize you required every detail of the command, since the entry is being logged, but here is an example (only the user information is blanked out):

/usr/local/bin/elog -h vmna62s1 -p 8080 -l NA62Logbook -u xxxx xxxx -a Author=Rubin -a Type=Problem\(s\) -a Category=Elog -a Subject="Client Initiated E-mail Notification" "Tests"

From elogd.cfg:

Options Type = Routine{1}, Problem(s){2}, Other{3}
Options Category = Access, Beam, CHANTI, CHOD, Computer/Network, DCS/DSS, Elog, 
GTK, HASC, IRC/SAC, KTAG, LAV, LKr, MUV, NewCHOD, Online Monitor, RICH, Run, Run
 Control, Shift, STRAW, TDAQ

{1} Email Category Elog =
{2} Email Category Elog = Philip.Rubin@cern.ch
{3} Email Category Elog =
 

The TDAQ-category command that is misbehaving is essentially identical:

/usr/local/bin/elog -h vmna62s1 -p 8080 -l NA62Logbook -u xxxx xxxx -a Author="Run Control" -a Type=Problem\(s\) -a Category=TDAQ -a Subject="Board Reload" "KTAG4"

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

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