Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 112 of 806  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Version Subject
  68949   Tue Apr 30 05:52:44 2019 Question Johnsecondcomingtechnologies@fastmail.comQuestionLinux3.1.2-bd75964How to sort on any field?

Hi, I was wondering if this is possible. I've tried to sort on anything other than the first few fields and although the screen refreshes like it is 'doing something', it does NOT sort. Sometimes it will take me to the last page of my data, but still no sorting. I use Debian Linux verson of Elog. There have been no other issues. I need to figure out how to do this without parsing it to another program first. Thanks again for this wonderful program :)

John

  68948   Mon Apr 29 17:48:13 2019 Reply Alan Grantagrant@winnipeg.caQuestionWindows3.1.2Re: Last default = <n>

I just changed to Last default = 31 and even restarted elogd.exe but it still finds a given string older than 31 days. Also the default Select Period box value next to the QF's remains at All Entries. My understanding is it shoud behave like Find, where Show Last Default = 31 should default the display to Month, and also only search within the last month of entries.

Stefan Ritt wrote:

Indeed the description of the "Last default = <n>" option is not clear. I just updated that. If you have a quick filter "Date", then you have different options there like "Last day", "Last 3 days", "Last week", "Last month", "Last 3 months", "Last 6 months", "Last year". Each of these options has an underlying number of days, which are 1, 3, 7, 31, 92, 182, 364. In the "Last default = <n>" option you can only choose one of these seven options. Then this option is selected by default and the filter is applied accordingly. This lets you still change the date filter to a longer time period for example, but then with the penalty of longer search times.

So what you need is "Last default = 31" instead of 28 and it should work.

Stefan

Alan Grant wrote:

According to the doc on the setting "Last default = <n>" it is intended to restrict Quick Filter searches to the last (n) days of entries, however when I add "Last default = 28" to config it still returns entries far older then 28 days when using the filter search. Am I misunderstanding, or implementing it wrong? We must restrict searches through QF to reduce load.

A couple other side questions which are related:

The doc on this setting says: "Last default = <n>
Some logbooks are very big ans searching through all entries with quick filter can be time consuming. This option sets a default value for the Date quick filter, so that by default only the <n> days are displayed." ...... I'm assuming that by saying "only the <n> days are displayed" that it has actually only searched <n> days ................ vs seaching ALL the logbooks but only displaying <n> days. Please confirm.

Also, why wouldn't the "28" days spec display in the Select Period box beside the Quick Filters? Otherwise it appears to me to be a separate and conflicting item. Best regards!

 

 

  68947   Mon Apr 29 13:12:56 2019 Reply Stefan Rittstefan.ritt@psi.chQuestionWindows3.1.2Re: Last default = <n>

Indeed the description of the "Last default = <n>" option is not clear. I just updated that. If you have a quick filter "Date", then you have different options there like "Last day", "Last 3 days", "Last week", "Last month", "Last 3 months", "Last 6 months", "Last year". Each of these options has an underlying number of days, which are 1, 3, 7, 31, 92, 182, 364. In the "Last default = <n>" option you can only choose one of these seven options. Then this option is selected by default and the filter is applied accordingly. This lets you still change the date filter to a longer time period for example, but then with the penalty of longer search times.

So what you need is "Last default = 31" instead of 28 and it should work.

Stefan

Alan Grant wrote:

According to the doc on the setting "Last default = <n>" it is intended to restrict Quick Filter searches to the last (n) days of entries, however when I add "Last default = 28" to config it still returns entries far older then 28 days when using the filter search. Am I misunderstanding, or implementing it wrong? We must restrict searches through QF to reduce load.

A couple other side questions which are related:

The doc on this setting says: "Last default = <n>
Some logbooks are very big ans searching through all entries with quick filter can be time consuming. This option sets a default value for the Date quick filter, so that by default only the <n> days are displayed." ...... I'm assuming that by saying "only the <n> days are displayed" that it has actually only searched <n> days ................ vs seaching ALL the logbooks but only displaying <n> days. Please confirm.

Also, why wouldn't the "28" days spec display in the Select Period box beside the Quick Filters? Otherwise it appears to me to be a separate and conflicting item. Best regards!

 

  68946   Mon Apr 29 02:41:15 2019 Question Alan Grantagrant@winnipeg.caQuestionWindows3.1.2Last default = <n>

According to the doc on the setting "Last default = <n>" it is intended to restrict Quick Filter searches to the last (n) days of entries, however when I add "Last default = 28" to config it still returns entries far older then 28 days when using the filter search. Am I misunderstanding, or implementing it wrong? We must restrict searches through QF to reduce load.

A couple other side questions which are related:

The doc on this setting says: "Last default = <n>
Some logbooks are very big ans searching through all entries with quick filter can be time consuming. This option sets a default value for the Date quick filter, so that by default only the <n> days are displayed." ...... I'm assuming that by saying "only the <n> days are displayed" that it has actually only searched <n> days ................ vs seaching ALL the logbooks but only displaying <n> days. Please confirm.

Also, why wouldn't the "28" days spec display in the Select Period box beside the Quick Filters? Otherwise it appears to me to be a separate and conflicting item. Best regards!

  68945   Fri Apr 26 17:22:46 2019 Reply Stefan Rittstefan.ritt@psi.chBug reportAllelogd 3.1.4Re: elog program does not respect "Allow edit" list

Ok, I found the issue. The "Restrict edit time" is only checked when one clicks on "Edit" in the browser. The elog command line tool does not really an edit, but just submits an entry with an (old) ID. I added a check also for that case so now it should work. The commit is in git.

Stefan

Heinz Junkes wrote:

Stefan, will send the info off this forum.

Heinz

Heinz Junkes wrote:

I ask my users where they had the problems and then create a demo for testing.
Thanks Heinz

Stefan Ritt wrote:

So you are telling me that "Restrict edit time" is not working correctly? In order to fix any problem, I have to reproduce it. Can you post a minimel elogd.cfg file with which I can reproduce the problem?

Stefan

Heinz Junkes wrote:

Sorry, 

I meant "read only" by using "Restrict edit time" settings. e.g.

Restrict edit time = 24

I understand this to mean that an entry should not be able to be modified after 24 hours.

Heinz

Stefan Ritt wrote:

There is no "read only" flag. Please describe what you exactly did. Probably you want "Restrict edit time" for that.

Stefan

Heinz Junkes wrote:

Thanks for the answer. The real problem is that you can overwrite existing entries even if you have set an entry to "read only", i.e. you have forbidden further editing.

Heinz

Stefan Ritt wrote:

There are two ways:

1) Use different password files for different logbooks. Each password file contains only those users which have access to that logbook.

2) Use "Login user = <usr list>" to restrict access to certain users in that list.

Stefan

Heinz Junkes wrote:

Since there's no answer to that.
I am the only one with the problem? Did I just configure something wrong?
Thanks Heinz

Heinz Junkes wrote:

submissions via the elog - program can overwrite entries even if the user has no edit rights

 

 

 

 

 

 

 

 

 

  68944   Fri Apr 26 11:24:21 2019 Reply Heinz Junkesjunkes@fhi-berlin.mpg.deBug reportAllelogd 3.1.4Re: elog program does not respect "Allow edit" list

Stefan, will send the info off this forum.

Heinz

Heinz Junkes wrote:

I ask my users where they had the problems and then create a demo for testing.
Thanks Heinz

Stefan Ritt wrote:

So you are telling me that "Restrict edit time" is not working correctly? In order to fix any problem, I have to reproduce it. Can you post a minimel elogd.cfg file with which I can reproduce the problem?

Stefan

Heinz Junkes wrote:

Sorry, 

I meant "read only" by using "Restrict edit time" settings. e.g.

Restrict edit time = 24

I understand this to mean that an entry should not be able to be modified after 24 hours.

Heinz

Stefan Ritt wrote:

There is no "read only" flag. Please describe what you exactly did. Probably you want "Restrict edit time" for that.

Stefan

Heinz Junkes wrote:

Thanks for the answer. The real problem is that you can overwrite existing entries even if you have set an entry to "read only", i.e. you have forbidden further editing.

Heinz

Stefan Ritt wrote:

There are two ways:

1) Use different password files for different logbooks. Each password file contains only those users which have access to that logbook.

2) Use "Login user = <usr list>" to restrict access to certain users in that list.

Stefan

Heinz Junkes wrote:

Since there's no answer to that.
I am the only one with the problem? Did I just configure something wrong?
Thanks Heinz

Heinz Junkes wrote:

submissions via the elog - program can overwrite entries even if the user has no edit rights

 

 

 

 

 

 

 

 

  68943   Thu Apr 25 11:27:21 2019 Reply Stefan Rittstefan.ritt@psi.chBug reportMac OSX3.1.4Re: elogd Service exited with abnormal code: 1

What you recommend is enough. Just make sure to compile elogd with the flags mentioned before, and when you get the segment violation, do a stack trace inside the debugger to learn where the fault happend. Maybe also print the contents of some variables at the current location.

Stefan

Alessio Sarti wrote:

Thanks for the prompt feedback.

a) I confirm that the problems shows up also when running interactively the elog through  elogd -p 8080

b) I am trying to catch the exit using lldb on the mac machine. I will be able to give you some feedback on that I hope in the next week (not easy access to the server)

c) What is the clean - recommended way to port everything on the linux machine and debug? I would do the following: download/install elog on a linux server, 'copy' all that now lives under /usr/local/elog on the mac one on the linux server, start the elog... is this ok? or there's anything else that I need to copy from the mac server to be sure to have the same environment?

Thanks again.

Alessio

 

Stefan Ritt wrote:

This kind of behavior we typically see if some elog entry is corrupt. After a few hours you might access this corrupt entry by accident, and then the server stops. If you see however this behavior on a fresh logbook with no corrupt entries, then the problem must lie somewhere else.

Do you see the same problem running under linux?

Do you see the same problem if you run elogd interactively (not through launchd)?

If you run elogd inside a debugger (like gdb or lldb), what does the debugger tell you when it crashes and you show the stack frames? Make sure to compile with -O0 and -g flags to include debug information in the executable.

Stefan 

Alessio Sarti wrote:

Dear all.

I am running elog 

elogd 3.1.4 , revision ead6bbc6

on Macosx Mojave

Darwin arpg-serv.ing2.uniroma1.it 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64

I managed to compile and run without problems the elog source code.

I can run it and have it properly displayed at boot time. After the server boot, for few hours, I have the elog ready at http://arpg-serv.ing2.uniroma1.it/elog  but then, after few hours.. I get that the service stops and the elog is no longer accessible.

So far I was able to track down the problems only to the 

/var/log/system.log

file in which I find a not useful error message:

Eg: Apr 23 14:00:46 arpg-serv com.apple.xpc.launchd[1] (ch.psi.elogd[85248]): Service exited with abnormal code: 1

I do not know I can I debug this nor why the code runs for few hours without problems... I just re-downloaded the code from scratch today, unloaded and then re-loaded the daemon but still it fails with the same error.

I am sure that I can get it running again for few hours by re-booting. But I want to understand the source of the problem.. Anyone can be of help on this long standing issue?

Thanks

 

 

 

  68942   Thu Apr 25 11:16:06 2019 Reply Alessio Sartialessio.sarti@uniroma1.itBug reportMac OSX3.1.4Re: elogd Service exited with abnormal code: 1

Thanks for the prompt feedback.

a) I confirm that the problems shows up also when running interactively the elog through  elogd -p 8080

b) I am trying to catch the exit using lldb on the mac machine. I will be able to give you some feedback on that I hope in the next week (not easy access to the server)

c) What is the clean - recommended way to port everything on the linux machine and debug? I would do the following: download/install elog on a linux server, 'copy' all that now lives under /usr/local/elog on the mac one on the linux server, start the elog... is this ok? or there's anything else that I need to copy from the mac server to be sure to have the same environment?

Thanks again.

Alessio

 

Stefan Ritt wrote:

This kind of behavior we typically see if some elog entry is corrupt. After a few hours you might access this corrupt entry by accident, and then the server stops. If you see however this behavior on a fresh logbook with no corrupt entries, then the problem must lie somewhere else.

Do you see the same problem running under linux?

Do you see the same problem if you run elogd interactively (not through launchd)?

If you run elogd inside a debugger (like gdb or lldb), what does the debugger tell you when it crashes and you show the stack frames? Make sure to compile with -O0 and -g flags to include debug information in the executable.

Stefan 

Alessio Sarti wrote:

Dear all.

I am running elog 

elogd 3.1.4 , revision ead6bbc6

on Macosx Mojave

Darwin arpg-serv.ing2.uniroma1.it 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64

I managed to compile and run without problems the elog source code.

I can run it and have it properly displayed at boot time. After the server boot, for few hours, I have the elog ready at http://arpg-serv.ing2.uniroma1.it/elog  but then, after few hours.. I get that the service stops and the elog is no longer accessible.

So far I was able to track down the problems only to the 

/var/log/system.log

file in which I find a not useful error message:

Eg: Apr 23 14:00:46 arpg-serv com.apple.xpc.launchd[1] (ch.psi.elogd[85248]): Service exited with abnormal code: 1

I do not know I can I debug this nor why the code runs for few hours without problems... I just re-downloaded the code from scratch today, unloaded and then re-loaded the daemon but still it fails with the same error.

I am sure that I can get it running again for few hours by re-booting. But I want to understand the source of the problem.. Anyone can be of help on this long standing issue?

Thanks

 

 

ELOG V3.1.5-3fb85fa6