| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
67706
|
Mon Sep 22 14:39:10 2014 |
 | Stefan Ritt | stefan.ritt@psi.ch | Info | All | V2.9.2-24 | Re: Sort by date prior to 2002 |
| Andreas Luedeke wrote: |
|
| Chris Jennings wrote: |
|
| Chris Jennings wrote: |
|
I have an attribute formatted as a date (but not labeled as date) and is sorted as second priority. The sort works fine until I enter a date older than Jan 1st 2002. When I do this it is sorted as the latest. Is this a bug or simply not designed to use dates this old?
Thanks in advance,
Chris
|
Sorry, my mistake. The cutoff date is anything before September 9th 2001 does not sort.
|
I think I remember that this has been discussed earlier: it is a little bug in elogd.
You can see where it comes from if you type in the little command 'date -d "9-Sep-2001 3:46:40" +%s'
Converted to "seconds of the epoche" (seconds since 1970-01-01 00:00:00 UTC) the date "9-Sep-2001 3:46:40" has one digit more than "9-Sep-2001 3:46:39".
Since elog makes a string comparison, suddenly 1'000'000'000 is less than 999'999'999; therefore the wrong sorting.
Workaround: you can modify your old entries and add a leading zero to all entries where your specific date field starts with a '9'.
Stefan: you should fix it at least well before 20-Nov-2286 18:46:40, when the same bug strikes again! 
|
Ok, well before 2286 approaches I fixed that bug and committed it to the GIT repository (master branch).
/Stefan |
|
67709
|
Fri Oct 24 12:51:00 2014 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug fix | All | ALL | POODLE vulnerability | IMPORTANT SECURITY ANNOUNCEMENT
Recently the POODLE vulnerability has been announced: http://en.wikipedia.org/wiki/POODLE
ELOG is prone to this vulnerability if it runs directly the SSL protocol and can be accessed from the internet. If ELOG runs behind an Apache proxy, and the Apache server has been correctly configured (disabled the SSLv23 protocols), ELOG is safe as well.
To fix this vulnerability, ELOG needs to be recompiled after the attached patch has been applied. This prohibits ELOG to fallback to the insecure SSLv2 & v3 protocols and only use the safe TLSv1 protocol.
If you do not know how to recompile ELOG, please do not run ELOG directly accessible from the internet until the next binary release has been published.
/Stefan Ritt |
| Attachment 1: elogd.patch
|
diff --git a/src/elogd.c b/src/elogd.c
index fac34f8..13c619f 100755
--- a/src/elogd.c
+++ b/src/elogd.c
@@ -2342,7 +2342,7 @@ int ssl_connect(int sock, SSL ** ssl_con)
SSL_library_init();
SSL_load_error_strings();
- meth = (SSL_METHOD *) SSLv23_method();
+ meth = (SSL_METHOD *) TLSv1_method();
ctx = SSL_CTX_new(meth);
*ssl_con = SSL_new(ctx);
@@ -28902,7 +28902,7 @@ SSL_CTX *init_ssl(void)
SSL_library_init();
SSL_load_error_strings();
- meth = (SSL_METHOD *) SSLv23_method();
+ meth = (SSL_METHOD *) TLSv1_method();
ctx = SSL_CTX_new(meth);
if (getcfg("global", "SSL Passphrase", pwd, sizeof(pwd))) {
|
|
67752
|
Fri Jan 16 13:41:18 2015 |
 | Eoin Butler | eoin.butler@cern.ch | Request | All | - | Configure default time range in 'Find' | Hello,
We have a very large elog database, and executing a 'Find' on the whole range takes several minutes, locking other users out of the elog for that time. It would be very nice if there could be an option to set the default value of the 'search last ...' option on the find page. Thanks in advance! |
|
67753
|
Fri Jan 16 14:29:58 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | All | - | Re: Configure default time range in 'Find' | Have you tried in the "Find" page to set a start date, or select "Show last: Month". This shoudl speed up searching quit a bit.
| Eoin Butler wrote: |
|
Hello,
We have a very large elog database, and executing a 'Find' on the whole range takes several minutes, locking other users out of the elog for that time. It would be very nice if there could be an option to set the default value of the 'search last ...' option on the find page. Thanks in advance!
|
|
|
67754
|
Mon Jan 19 11:09:31 2015 |
| Eoin Butler | eoin.butler@cern.ch | Request | All | - | Re: Configure default time range in 'Find' | Yes, this works, but users inevitably forget to select "last week" or whatever, and just leave it blank, which means their search unintentionally takes a long time. It would be much better if one could configure it to default to something "fast".
| Stefan Ritt wrote: |
|
Have you tried in the "Find" page to set a start date, or select "Show last: Month". This shoudl speed up searching quit a bit.
|
|
|
67755
|
Mon Jan 19 17:17:32 2015 |
 | David Pilgram | David.Pilgram@epost.org.uk | Request | All | - | Re: Configure default time range in 'Find' | Hi there, In the "Find" page, I changed the default of the "Show last" drop down box in the Entry Date section from the (unstated) "All time" to "Day", and added back in an "All Time" option at the very bottom. This gives a default of searching the last day, and one has to think and select the period of time to search back on.
I did this on my 2.9.2-2475 version, recompiled and it works. Two lines of code changed and even my cr*ppy coding was up to the task. I don't know if Stefan would want to put this into the Master copy (I'll forward the changes if you want Stefan, but it's pretty easy if I can do it), but if you can edit and recompile (Eoin) I can tell you which to lines for immediate functionality. Back up everything first, though!
| Eoin Butler wrote: |
|
Yes, this works, but users inevitably forget to select "last week" or whatever, and just leave it blank, which means their search unintentionally takes a long time. It would be much better if one could configure it to default to something "fast".
| Stefan Ritt wrote: |
|
Have you tried in the "Find" page to set a start date, or select "Show last: Month". This shoudl speed up searching quit a bit.
|
|
|
|
67756
|
Tue Jan 20 00:58:58 2015 |
| David Pilgram | David.Pilgram@epost.org.uk | Request | All | - | Re: Configure default time range in 'Find' | It has just occurred to me that you may also have to check the non-English files, (./resorces/eloglang_xxxx) as this change introduces a new term "All time" that would need translation into the other lexicons.
By the way, in further testing, the "Show last" selection over-rides whatever two dates are selected, so if you ask for any entry in Dec 2014, but the "Show last" selects "week", nothing is found - very quickly. I trust that is what you're after, Eoin. I'll keep my change to the coding, but that's personal choice.
David.
| David Pilgram wrote: |
|
Hi there, In the "Find" page, I changed the default of the "Show last" drop down box in the Entry Date section from the (unstated) "All time" to "Day", and added back in an "All Time" option at the very bottom. This gives a default of searching the last day, and one has to think and select the period of time to search back on.
I did this on my 2.9.2-2475 version, recompiled and it works. Two lines of code changed and even my cr*ppy coding was up to the task. I don't know if Stefan would want to put this into the Master copy (I'll forward the changes if you want Stefan, but it's pretty easy if I can do it), but if you can edit and recompile (Eoin) I can tell you which to lines for immediate functionality. Back up everything first, though!
| Eoin Butler wrote: |
|
Yes, this works, but users inevitably forget to select "last week" or whatever, and just leave it blank, which means their search unintentionally takes a long time. It would be much better if one could configure it to default to something "fast".
| Stefan Ritt wrote: |
|
Have you tried in the "Find" page to set a start date, or select "Show last: Month". This shoudl speed up searching quit a bit.
|
|
|
|
|
67757
|
Wed Jan 21 02:15:12 2015 |
 | dev | joshi868b@gmail.com | Question | All | 3.3 | filter with or operation/TIME DURATION CALCULATION | 1.I HAVE A ELOG BOOK WITH TWO ATTRIBUTE 'FROM' &'TO'. I WANT TO USE A FILTER WHICH WILL SEARCH FOR A VALUE IN BOTH ATTRIBUTE .KINDLY HELP ME.
2. HOW TO CALCULATE THE TIME DURATION AUTOMATICALLY BASED ON TWO ATTRIBUTES 'START TIME' AND 'STOP TIME' . |
|