Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 74 of 238  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
icon5.gif   elogd lost entry database without restart during file system trouble, posted by Andreas Luedeke on Thu Apr 30 09:54:17 2015 
I'm running ELOG since several years with rather heavy usage.
Last week I've upgrades from 3.0.0 to 3.1.0 and this week I had twice the same problem:
elogd lost the index for old entries and showed empty logbooks, without having restarted.
The logbooks appeared to be empty; new entries started with index "1".
The first time the origin of the problem were network troubles;
the second time it had been caused by a severe problem of our AFS file system service.
I never experienced this consequence for ELOG in the past when we had AFS problems.

Since the logbooks are used for the operation log of a user facility they continued to do new entries.
The next day I had to re-number the new entries and restart elogd and everything was fine.

I could understand if elogd crashes when the filesystem of the logbook goes away.
And when it restarts with an (temporarily) empty filesystem, that would explain what happened.
But it did not restart and the log file does not contain any information about any problem, 
just that suddenly all new entries in each logbook started with ID "1" again.

Stefan, any idea?
Anyone else ever experienced that with the new ELOG version (or older ones)?
    icon2.gif   Re: elogd lost entry database without restart during file system trouble, posted by Stefan Ritt on Thu Apr 30 13:01:29 2015 
First, I can only fix problems which are reproducible. Can we do another power outage at PSI again?

But seriously, I guess what happened is that elog sees an empty directory when the AFS server
goes down. If this happens, it rebuilds its internal (RAM based) indes, and sees no entries there.
So the next entry will be ID 1. That should be independent of the ELOG version. I guess if PSI
would have a power outage a year ago, you could have had the same problem.

I had problem some long time a go with AFS, where the network access blocked the program
for several minutes. I decided then to ONLY use local filesystems for elog servers, and do the
backup via rsync to an AFS account. Since then I never had problems.

Now it is hard for me to develop code which avoids the mentioned problem. I could maybe
check if there are many entries, and all over sudden there are no entries any more, the server
just stops with some detailed error message. But it is hard for me to mimic the AFS server 
outage. I can try to manually delete elog files and see what happens, but this only partially
mimics network problems.

/Stefan

> I'm running ELOG since several years with rather heavy usage.
> Last week I've upgrades from 3.0.0 to 3.1.0 and this week I had twice the same problem:
> elogd lost the index for old entries and showed empty logbooks, without having restarted.
> The logbooks appeared to be empty; new entries started with index "1".
> The first time the origin of the problem were network troubles;
> the second time it had been caused by a severe problem of our AFS file system service.
> I never experienced this consequence for ELOG in the past when we had AFS problems.
> 
> Since the logbooks are used for the operation log of a user facility they continued to do new entries.
> The next day I had to re-number the new entries and restart elogd and everything was fine.
> 
> I could understand if elogd crashes when the filesystem of the logbook goes away.
> And when it restarts with an (temporarily) empty filesystem, that would explain what happened.
> But it did not restart and the log file does not contain any information about any problem, 
> just that suddenly all new entries in each logbook started with ID "1" again.
> 
> Stefan, any idea?
> Anyone else ever experienced that with the new ELOG version (or older ones)?
icon5.gif   Odd behaviour when attaching a file to an entry, posted by David Pilgram on Sun Apr 12 21:12:29 2015 

Having installed v3.1.0 on a test logbook, I find that I can browse and select a file, but when I click on the "Upload" button, I get a pop-up message from the browser asking me:

"This page is asking you to confirm that you want to leave - data you have entered may not be saved."

 

The stay on page does nothing, the leave page option does what one expects from elog - that is the attachment thumbnail is generated etc. 

I guess this is something to do with the drag and drop feature, but wondered if others have this issue or whether it may just be some mystery setting of the browser (firefox).

 

    icon2.gif   Re: Odd behaviour when attaching a file to an entry, posted by Stefan Ritt on Thu Apr 23 15:13:06 2015 

This problem has been fixed in Version 3.1.0-2. Please upgrade.

David Pilgram wrote:

Having installed v3.1.0 on a test logbook, I find that I can browse and select a file, but when I click on the "Upload" button, I get a pop-up message from the browser asking me:

"This page is asking you to confirm that you want to leave - data you have entered may not be saved."

 

The stay on page does nothing, the leave page option does what one expects from elog - that is the attachment thumbnail is generated etc. 

I guess this is something to do with the drag and drop feature, but wondered if others have this issue or whether it may just be some mystery setting of the browser (firefox).

 

 

       icon2.gif   Re: Odd behaviour when attaching a file to an entry, posted by David Pilgram on Thu Apr 23 15:37:37 2015 

Thanks Stefan, that did the trick.

Had a bit of an effort with the git repository, though, kept getting 403 errors when tried the

git clone https://bitbucket.org/ritt/elog as per the "download" page.

error: The requested URL returned error: 403 while accessing https://bitbucket.org/ritt/elog/info/refs

Stefan Ritt wrote:

This problem has been fixed in Version 3.1.0-2. Please upgrade.

David Pilgram wrote:

Having installed v3.1.0 on a test logbook, I find that I can browse and select a file, but when I click on the "Upload" button, I get a pop-up message from the browser asking me:

"This page is asking you to confirm that you want to leave - data you have entered may not be saved."

 

The stay on page does nothing, the leave page option does what one expects from elog - that is the attachment thumbnail is generated etc. 

I guess this is something to do with the drag and drop feature, but wondered if others have this issue or whether it may just be some mystery setting of the browser (firefox).

 

 

 

icon8.gif   Max Logbooks for Email notify, posted by Oliver Kleinau on Wed Apr 8 11:40:27 2015 

Hi,

we've got 109 logbooks in Elog. Whenever I set a notify for all logbooks in configuration menu it is limited to 73 entrys. After saving the changes the rest of the entrys are cut off.
I've already searched in the sourcecode if I can find some limitation for that but without success.

When I change the password file by hand, it is working as long as I don't change anything in the configuration that rewrites the file.

Regards,
Oliver

 

    icon2.gif   Re: Max Logbooks for Email notify, posted by Oliver Kleinau on Fri Apr 10 08:37:19 2015 

It seems to be the GET buffer of the elog-Server. The GET statement is cut off after &sub_lb72=1&sub_ eg. 1000 chars.

Oliver Kleinau wrote:

Hi,

we've got 109 logbooks in Elog. Whenever I set a notify for all logbooks in configuration menu it is limited to 73 entrys. After saving the changes the rest of the entrys are cut off.
I've already searched in the sourcecode if I can find some limitation for that but without success.

When I change the password file by hand, it is working as long as I don't change anything in the configuration that rewrites the file.

Regards,
Oliver

 

 

       icon2.gif   Re: Max Logbooks for Email notify, posted by Oliver Kleinau on Fri Apr 10 09:59:42 2015 

It was str variable in function process_http_request in elogd.c.

This should have the size of received buffer.

PROBLEM SOLVED!!!

Oliver Kleinau wrote:

It seems to be the GET buffer of the elog-Server. The GET statement is cut off after &sub_lb72=1&sub_ eg. 1000 chars.

Oliver Kleinau wrote:

Hi,

we've got 109 logbooks in Elog. Whenever I set a notify for all logbooks in configuration menu it is limited to 73 entrys. After saving the changes the rest of the entrys are cut off.
I've already searched in the sourcecode if I can find some limitation for that but without success.

When I change the password file by hand, it is working as long as I don't change anything in the configuration that rewrites the file.

Regards,
Oliver

 

 

 

          icon2.gif   Re: Max Logbooks for Email notify, posted by Stefan Ritt on Wed Apr 22 13:40:19 2015 

Ok, I fixed this in the current GIT version. You might check if that works for you.

Oliver Kleinau wrote:

It was str variable in function process_http_request in elogd.c.

This should have the size of received buffer.

PROBLEM SOLVED!!!

Oliver Kleinau wrote:

It seems to be the GET buffer of the elog-Server. The GET statement is cut off after &sub_lb72=1&sub_ eg. 1000 chars.

Oliver Kleinau wrote:

Hi,

we've got 109 logbooks in Elog. Whenever I set a notify for all logbooks in configuration menu it is limited to 73 entrys. After saving the changes the rest of the entrys are cut off.
I've already searched in the sourcecode if I can find some limitation for that but without success.

When I change the password file by hand, it is working as long as I don't change anything in the configuration that rewrites the file.

Regards,
Oliver

 

 

 

 

icon3.gif   ELOG Version 3.1.0 announcement, posted by Stefan Ritt on Thu Apr 2 15:44:33 2015 

This is an announcement for the ELOG version 3.1.0 being released just now. Among several bug fixes and an improved Drag & Drop interface for attachments, it contains a long awaited "autosave" feature.

Let's assume that you write an ELOG entry, and keep the window open for a longer time (like to write some shift notes over several hours). If your browser crashes or closes for some reason, you will loose your entered text. To avoid that, ELOG starting from version 3.1.0 has an autosave feature. Whenever you enter some text, it is saved in the background as a draft message to the server. If your browser is closed by accident, you always can go back to the logbook, click "New" and ELOG will tell you that there is a draft message and asks you if you want to edit it. When you edit and regularly submit this message, it becomes a "normal" entry and the draft flas is removed. In addition to the background saving, there is now also a "Save" button so you can manually save your text to the draft entry.

I have tested this to some extent, but I might not have seen all browser/OS combinations, so in case there is a problem, please report it here.

Happy Easter,
Stefan

    icon2.gif   Re: ELOG Version 3.1.0 announcement, posted by Banata Wachid Ridwan on Wed Apr 15 04:02:41 2015 

congrats, any detail changelog? I assume in software packages?

is it save just install and overwrite the old version?

Stefan Ritt wrote:

This is an announcement for the ELOG version 3.1.0 being released just now. Among several bug fixes and an improved Drag & Drop interface for attachments, it contains a long awaited "autosave" feature.

Let's assume that you write an ELOG entry, and keep the window open for a longer time (like to write some shift notes over several hours). If your browser crashes or closes for some reason, you will loose your entered text. To avoid that, ELOG starting from version 3.1.0 has an autosave feature. Whenever you enter some text, it is saved in the background as a draft message to the server. If your browser is closed by accident, you always can go back to the logbook, click "New" and ELOG will tell you that there is a draft message and asks you if you want to edit it. When you edit and regularly submit this message, it becomes a "normal" entry and the draft flas is removed. In addition to the background saving, there is now also a "Save" button so you can manually save your text to the draft entry.

I have tested this to some extent, but I might not have seen all browser/OS combinations, so in case there is a problem, please report it here.

Happy Easter,
Stefan

 

       icon2.gif   Re: ELOG Version 3.1.0 announcement, posted by Stefan Ritt on Wed Apr 15 09:01:04 2015 

The changelog is here: http://midas.psi.ch/elog/download/ChangeLog

It is save to install the new version over the old one.

 

Banata Wachid Ridwan wrote:

congrats, any detail changelog? I assume in software packages?

is it save just install and overwrite the old version?

Stefan Ritt wrote:

This is an announcement for the ELOG version 3.1.0 being released just now. Among several bug fixes and an improved Drag & Drop interface for attachments, it contains a long awaited "autosave" feature.

Let's assume that you write an ELOG entry, and keep the window open for a longer time (like to write some shift notes over several hours). If your browser crashes or closes for some reason, you will loose your entered text. To avoid that, ELOG starting from version 3.1.0 has an autosave feature. Whenever you enter some text, it is saved in the background as a draft message to the server. If your browser is closed by accident, you always can go back to the logbook, click "New" and ELOG will tell you that there is a draft message and asks you if you want to edit it. When you edit and regularly submit this message, it becomes a "normal" entry and the draft flas is removed. In addition to the background saving, there is now also a "Save" button so you can manually save your text to the draft entry.

I have tested this to some extent, but I might not have seen all browser/OS combinations, so in case there is a problem, please report it here.

Happy Easter,
Stefan

 

 

icon5.gif   Strange browser behaviour with chrome?, posted by Tim Schel on Mon Mar 30 14:46:28 2015 2015-03-30_14_25_52-ELOG_Amadou.png2015-03-30_14_25_32-ELOG_Kandidaten.png
Hello there,

I have been using ELOG for 4 years now and all of a sudden I see a strange behaviour.
As you can see in the screenshots below I have configured 6 logbooks (tabs) ... only 2
display (colors in CSS?) correctly as configured.
There haven't been any changes recently configuration wise .. but I suspect my chrome
has been upgraded silently.

Any ideas why one logbook (see screenshot 2) called Kandidaten would display
correctly and the other called DSP doesn't?
The first screenshot displays all rows in blue and purple letters ....
The Logbook Stagiairs even has multiple behaviours .... some of it sub books display correctly
and some don't.

I have a new colleague since a few days who uses the ELOG as well but using Internet Explorer
and she doesn't have this strange behaviour. I can rule out configuration error since
I stripped configuration and added verbosity logging level up and nothing was detected.

Is this possible solely due to chrome update (of which I am not even sure).
I looked at the CSS source of both screenshots and I notice that in the first case (wrong!)
there is no CSS class attributed to the TD elements.

Anyway I can understand that the browser displays everything wrong ... but this behaviour
I cannot explain.
    icon2.gif   Re: Strange browser behaviour with chrome?, posted by Stefan Ritt on Mon Mar 30 17:48:06 2015 
The (correct) display tells me that the colours are user-defined, probably by the configuration option

Style <attribute> <value> = <style>

which selects different styles for different rows. Now I do not know why your browser should change behaviour all over sudden, but I would double check the configuration. Like removing all style additions in the config file, then try again, then add one by one. There could also be a class defined with the "style" option which has not been added to the default style file themes directory of the elog installation.

Stefan
       icon2.gif   Re: Strange browser behaviour with chrome?, posted by Andreas Luedeke on Tue Mar 31 11:36:25 2015 

Stefan Ritt wrote:
The (correct) display tells me that the colours are user-defined, probably by the configuration option

Style <attribute> <value> = <style>

which selects different styles for different rows. Now I do not know why your browser should change behaviour all over sudden, but I would double check the configuration. Like removing all style additions in the config file, then try again, then add one by one. There could also be a class defined with the "style" option which has not been added to the default style file themes directory of the elog installation.

Stefan


Just my two cent:
the content of a particular entry can change the rendering. If you have an HTML end tag like </table> or </font> in your entry, then the display after that entry may be spoiled.
You could try to select the very same entries in both browsers, to see if it does depend on the specific entry content.
If the problem persists, then I would suggest that you post the following:
- a minimal configuration for a logbook that reproduces the problem; and
- the actual entries, exported in XML or RAW format; and
- screenshots on how it displays with IE (add version number) and with Chrome (add version number).

Cheers
Andreas
          icon2.gif   Re: Strange browser behaviour with chrome?, posted by Stefan Ritt on Tue Mar 31 11:44:27 2015 

Andreas Luedeke wrote:
the content of a particular entry can change the rendering. If you have an HTML end tag like </table> or </font> in your entry, then the display after that entry may be spoiled.


Actually not. If you have HTML statements in entries, they will be rendered using escape characters (like </table> -> &lt;/table&gt;). This is necessary to avoid cross-side-script vulnerabilities (XSS). If this is not working in some case, let me know and I have to fix it. The only exception is if you explicitly allow this via Allow HTML = 1
             icon2.gif   Re: Strange browser behaviour with chrome?, posted by Andreas Luedeke on Wed Apr 1 10:54:27 2015 

Stefan Ritt wrote:

Andreas Luedeke wrote:
the content of a particular entry can change the rendering. If you have an HTML end tag like </table> or </font> in your entry, then the display after that entry may be spoiled.


Actually not. If you have HTML statements in entries, they will be rendered using escape characters (like </table> -> &lt;/table&gt;). This is necessary to avoid cross-side-script vulnerabilities (XSS). If this is not working in some case, let me know and I have to fix it. The only exception is if you explicitly allow this via Allow HTML = 1


If the content has been added with the "elog" command as HTML then it can contain mismatching HTML tags, can't it?
I don't see how this could be avoided by ELOG, unless you want to do a full HTML syntax check of all new and modified entries.
                icon2.gif   Re: Strange browser behaviour with chrome?, posted by Stefan Ritt on Wed Apr 1 11:41:31 2015 

Andreas Luedeke wrote:
If the content has been added with the "elog" command as HTML then it can contain mismatching HTML tags, can't it?
I don't see how this could be avoided by ELOG, unless you want to do a full HTML syntax check of all new and modified entries.


It works also with entries submitted by the "elog" command. The reason is that for the OUTPUT, all "<" characters are transformed into &gt;, which "inactivates" any HTML code, no matter where it came from.
                   icon2.gif   Re: Strange browser behaviour with chrome?, posted by Andreas Luedeke on Wed Apr 1 18:31:28 2015 

Stefan Ritt wrote:

Andreas Luedeke wrote:
If the content has been added with the "elog" command as HTML then it can contain mismatching HTML tags, can't it?
I don't see how this could be avoided by ELOG, unless you want to do a full HTML syntax check of all new and modified entries.


It works also with entries submitted by the "elog" command. The reason is that for the OUTPUT, all "<" characters are transformed into &gt;, which "inactivates" any HTML code, no matter where it came from.


Now I'm confused: if I create an entry with "elog -n 2 ...", then I put HTML code into elog and it is displayed as HTML. This HTML code does NOT convert a "<" into "&lt;", otherwise you could not display any HTML.
But of course this code can be wrongly formatted, for example it can contain a </table> tag without a <table> tag before it. This will definitely spoil the display in ELOG, and that was what I was refering to.
I agree that html tags in plain text entries will not have this problem.
                      icon2.gif   Re: Strange browser behaviour with chrome?, posted by Andreas Luedeke on Wed Apr 1 18:39:14 2015 

Proof of principle ;-)

                      icon2.gif   Re: Strange browser behaviour with chrome? </table>, posted by Stefan Ritt on Wed Apr 1 20:25:21 2015 

Andreas Luedeke wrote:
Now I'm confused: if I create an entry with "elog -n 2 ...", then I put HTML code into elog and it is displayed as HTML. This HTML code does NOT convert a "<" into "&lt;", otherwise you could not display any HTML.
But of course this code can be wrongly formatted, for example it can contain a </table> tag without a <table> tag before it. This will definitely spoil the display in ELOG, and that was what I was refering to.
I agree that html tags in plain text entries will not have this problem.


Sure, in the main body text you can insert arbitrary HTML if this type of encoding is not prohibited. The &lt; encoding I meant was for attribute values. Proof of principe above in the Subject field.
          icon2.gif   Re: Strange browser behaviour with chrome?, posted by Tim Schelfhout on Wed Apr 1 11:01:14 2015 
Thank you all of you for your notes ...
Anyway I have no time at the present to debug this ... at the level of configuration file.
I discovered however that the Incognito Mode of Chrome does NOT seem to have this problem??
Chrome version is 41.0.2272.101

Don't know why ??? ... tried disabling all of the added extensions in chrome but to no avail.
Don't know what else can be different in both modes.


Andreas Luedeke wrote:

Stefan Ritt wrote:
The (correct) display tells me that the colours are user-defined, probably by the configuration option

Style <attribute> <value> = <style>

which selects different styles for different rows. Now I do not know why your browser should change behaviour all over sudden, but I would double check the configuration. Like removing all style additions in the config file, then try again, then add one by one. There could also be a class defined with the "style" option which has not been added to the default style file themes directory of the elog installation.

Stefan


Just my two cent:
the content of a particular entry can change the rendering. If you have an HTML end tag like </table> or </font> in your entry, then the display after that entry may be spoiled.
You could try to select the very same entries in both browsers, to see if it does depend on the specific entry content.
If the problem persists, then I would suggest that you post the following:
- a minimal configuration for a logbook that reproduces the problem; and
- the actual entries, exported in XML or RAW format; and
- screenshots on how it displays with IE (add version number) and with Chrome (add version number).

Cheers
Andreas
icon5.gif   Permission to view, posted by Banata Wachid Ridwan on Fri Mar 20 08:22:38 2015 

Hello,

related to the permission, is it possible to set permission ?, so only the owner or certain people can view list all logbok and regular member can only see their own logbook, not the others.

thanx for the help
 

    icon2.gif   Re: Permission to view, posted by Andreas Luedeke on Fri Mar 20 09:25:11 2015 

Yes, it is possible. And explained in ELOG documentation.

Banata Wachid Ridwan wrote:

Hello,

related to the permission, is it possible to set permission ?, so only the owner or certain people can view list all logbok and regular member can only see their own logbook, not the others.

thanx for the help
 

 

       icon2.gif   Re: Permission to view, posted by Banata Wachid Ridwan on Fri Mar 27 05:39:29 2015 

I just read all administrator guide especially in :

http://midas.psi.ch/elog/config.html#access

and I didnt find it that exactly match with my need, or maybe I read wrong section :P

maybe my explanation little bit general.

I'll try to explain in detail, In my office, I just create 1 logbook for all employee,

one of my friend ask me if it possible to only give few people the ability to read all entry inside the logbook (all members), and the others (rest of the members) only able to input entry in the logbook and read their own.

please guide us.

Andreas Luedeke wrote:

Yes, it is possible. And explained in ELOG documentation.

Banata Wachid Ridwan wrote:

Hello,

related to the permission, is it possible to set permission ?, so only the owner or certain people can view list all logbok and regular member can only see their own logbook, not the others.

thanx for the help
 

 

 

          icon2.gif   Re: Permission to view, posted by Stefan Ritt on Fri Mar 27 07:26:45 2015 

You need

Password file = logbook.pwd
Login user = <name of allowed user(s)>

Banata Wachid Ridwan wrote:

I just read all administrator guide especially in :

http://midas.psi.ch/elog/config.html#access

and I didnt find it that exactly match with my need, or maybe I read wrong section :P

maybe my explanation little bit general.

I'll try to explain in detail, In my office, I just create 1 logbook for all employee,

one of my friend ask me if it possible to only give few people the ability to read all entry inside the logbook (all members), and the others (rest of the members) only able to input entry in the logbook and read their own.

please guide us.

Andreas Luedeke wrote:

Yes, it is possible. And explained in ELOG documentation.

Banata Wachid Ridwan wrote:

Hello,

related to the permission, is it possible to set permission ?, so only the owner or certain people can view list all logbok and regular member can only see their own logbook, not the others.

thanx for the help
 

 

 

 

             icon2.gif   Re: Permission to view, posted by Banata Wachid Ridwan on Fri Mar 27 08:19:56 2015 

so if that is the solution, all user that not allowed cannot login and cannot fill logbook

in my case, user still can login and fill logbook but cannot see other user's data on the same logbook, so user only see their own data.

but few members have a special permission to see all.

is that possible?

Stefan Ritt wrote:

You need

Password file = logbook.pwd
Login user = <name of allowed user(s)>

 

 

                icon2.gif   Re: Permission to view, posted by Stefan Ritt on Fri Mar 27 08:24:47 2015 

No.

Banata Wachid Ridwan wrote:

so if that is the solution, all user that not allowed cannot login and cannot fill logbook

in my case, user still can login and fill logbook but cannot see other user's data on the same logbook, so user only see their own data.

but few members have a special permission to see all.

is that possible?

Stefan Ritt wrote:

You need

Password file = logbook.pwd
Login user = <name of allowed user(s)>

 

 

 

icon1.gif   test, posted by Tim Schel on Wed Mar 25 10:36:15 2015 

zezerze

icon4.gif   Trouble to install ELOG V3.0.0-72a8401 in XP SP3, posted by Pedro Acosta on Mon Mar 23 17:02:03 2015 

Hi,

It´s not possible to install the last version V3.0.0-72a8401 over XP SP3, the previous version works well.  For Windows Vista Home Basic SP2 work fine the last version. 

I´m not sure if this the correct site to post this.

 

Regards

Pedro Acosta

 

    icon2.gif   Re: Trouble to install ELOG V3.0.0-72a8401 in XP SP3, posted by Pedro Acosta on Tue Mar 24 19:08:34 2015 

Maybe, nobody uses XP SP3 but i get Win32 invalid aplication error.  Not work!

Pedro Acosta wrote:

Hi,

It´s not possible to install the last version V3.0.0-72a8401 over XP SP3, the previous version works well.  For Windows Vista Home Basic SP2 work fine the last version. 

I´m not sure if this the correct site to post this.

 

Regards

Pedro Acosta

 

 

Goto page Previous  1, 2, 3 ... 73, 74, 75 ... 236, 237, 238   Next  
ELOG V3.1.5-3fb85fa6