ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68640
|
Fri Jul 14 19:26:06 2017 |
| Phil Rubin | rubinp@cern.ch | Question | Linux | 2.9.2 | Email Notification (Not) Initiated by elog Client Utility | 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" |
68643
|
Wed Jul 19 08:59:52 2017 |
| Phil Rubin | rubinp@cern.ch | Question | Linux | 2.9.2 | Re: Email Notification (Not) Initiated by elog Client Utility | 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
Andreas Luedeke wrote: |
Yes, parentheses in field content might be difficult to pass from a shell command. You did not even mention which Linux shell you are using and you did not show the actual elog command. Maybe you want to add that information?
Phil Rubin wrote: |
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"
|
|
|
68645
|
Wed Jul 19 10:25:08 2017 |
| Phil Rubin | rubinp@cern.ch | Question | Linux | 2.9.2 | Re: Email Notification (Not) Initiated by elog Client Utility | 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"
Andreas Luedeke wrote: |
If that is your command then it is obvious why no email is send:
you do set "Type=Type", but only for "Type=Problem(s)" and "Category=TDAQ" you would send an email.
Instead of writing "-h host" you should as well define the actual hostname, like "-h midas.psi.ch", likewise for all other parameter.
Phil Rubin wrote: |
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
Andreas Luedeke wrote: |
Yes, parentheses in field content might be difficult to pass from a shell command. You did not even mention which Linux shell you are using and you did not show the actual elog command. Maybe you want to add that information?
Phil Rubin wrote: |
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"
|
|
|
|
|
69366
|
Sat May 22 20:44:33 2021 |
| Phil Rubin | rubinp@cern.ch | Question | Linux | 3.1.3 | Naming a Notebook KTAG Wipes Out Formatting. Why? | 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"? |
69455
|
Mon Jan 3 19:11:08 2022 |
| Phil Rubin | rubinp@cern.ch | Question | Linux | 3.1.3 | Re: 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
|
|
67071
|
Tue May 31 13:48:41 2011 |
| Peter de Mol | pcwdemol@gmail.com | Bug report | Windows | 2.7.8-2280 | Find page resets quick filters if fields with user defined (drop-down)lists are selected. | Hi Stefan,
First : Compliments with your fine application !
The issue : A user wants to search the database. He selects one of the quick filters (e.g. "Show Last / Month"). Next he fills in the form and as long as text boxes are used there is no problem. But when he chooses a value from a populated drop-down list, the quick filter disappears. Other way round (first drop-down list and then the quick filter) no problem.
Kind regards,
Peter de Mol

|
65632
|
Thu Oct 25 12:04:02 2007 |
| Peter Rienstra | peter.rienstra@gmail.com | Bug report | Other | 2.6.5:1946 | Date attribute in Quick filter | Stefan,
I downloaded the latest source (ELOG V2.6.5-1946) to solve another problem. But now I get:
Error: "Attribute "Date" for quick filter not found", see attachment.
In the configfile I have: Quick filter = Date
A bug?
(It works fine, so it's not really a big problem.) |
Attachment 1: error.jpg
|
|
2093
|
Mon Nov 27 17:29:41 2006 |
| Peter Kovac | kovac@gwu.edu | Question | Linux | 2.6.1+r164 | elog (2.6.1+r1642 ubuntu/debian) regularly becomes non-responsive (w/o crashing) | Greetings~
First, the problem. Fairly regularly (at least once a week, perhaps more), our elog daemon seems to quietly die. The process is still running but anyone attempting to access the server gets "connection refused." The elog log doesn't show anything and the apache logs just show "proxy: Error reading from remote server returned by [path]". Calling a daemon restart doesn't seem to kill the daemon -- I get a "could not bind to port" error. Using kill and then starting the daemon again fixes the problem for a few days and then we start over.
The particulars:
We are running elog on an Ubuntu (6.06 Dapper Drake LTS) web server.
It's currently version 2.6.1+r1642 pulled via apt-get from the Debian repositories.
elog is hiding behind an apache2+SSL proxy.
Any thoughts? Has anyone else seen this behavior? My next step is probably to compile 2.6.2 and remove the packaged flavor but I wanted to see if this was a known bug...
Thanks,
-Peter |
|