Re: Cloning, posted by Gerfried Kumbartzki on Wed Jun 22 18:34:18 2005
|
Thank you for the suggestions; I commented the read and write passwd in elogd.cfg out and only then I was able to clone
(elogd -v -C http://laptop:8080) the logbook to the new server.
But this is only part of the story. The logbook on the labtop is owned by the
default user elog and default group elog, that is needed to start up the elogd. Only a user "elog" can do the cloning, unless temporarily the owner ship in /usr/local/elog is changed. I made it work by temporarily changing the owner ship on both machines, did the cloning, changed back to owner elog, started elogd and all was running.
I setup synchronizing and here too it works only if the read passwd in elogd.cfg is commented out.
Sync works fine from the RedHat linux laptop (rpm installed), but crashes the elogd on the alpha Linux machine (compiled from src) most of the time. elogd hast to be restarted and the sync had not finished.
So for now I settled to do the synchronize only from the laptop but have to remove the read passwd each time. That is tolerable but not
convenient.
Here I have another question: My Elog is passwd protected, encrypted passwd in elogd.cfg (read and write). When connecting to the elog the window
pops up asking for a user name and the passwd. I donot remember exactly, what was done to set name and passwd. But I find it "strange" that the user name can be anything as long as the passwd is right to access the ELog.
I think I have to learn more about the whole user and passwd protection schema.
Thanks again
Gerfried |
|
Re: Cloning, posted by Stefan Ritt on Fri Jun 24 21:24:55 2005
|
| Gerfried Kumbartzki wrote: | But this is only part of the story. The logbook on the labtop is owned by the
default user elog and default group elog, that is needed to start up the elogd. Only a user "elog" can do the cloning, unless temporarily the owner ship in /usr/local/elog is changed. I made it work by temporarily changing the owner ship on both machines, did the cloning, changed back to owner elog, started elogd and all was running. |
The /usr/local/elog files should be owned by user elog on both machines, and both elogd daemons should be started under user elog. Since only the two elogd daemons communicate with each other during synchronization, that should be fine. Only after the initial cloning (which you presumably do under your own user account), you have to do a "chmod" to change ownership of all files to uid/gid "elog/elog".
| Gerfried Kumbartzki wrote: | | I setup synchronizing and here too it works only if the read passwd in elogd.cfg is commented out. |
As I said, the read password is not really supported for synchronization. It is there historically, from the times when there was no user level password access. If you use synchronization, you should use that authentication (by putting a "password file = ..." into your config.
| Gerfried Kumbartzki wrote: | | Here I have another question: My Elog is passwd protected, encrypted passwd in elogd.cfg (read and write). When connecting to the elog the window pops up asking for a user name and the passwd. I donot remember exactly, what was done to set name and passwd. But I find it "strange" that the user name can be anything as long as the passwd is right to access the ELog. I think I have to learn more about the whole user and passwd protection schema. |
If you switch to user level password access, this problem goes away as well.
- Stefan |
|
Re: Cleaning up attachments, posted by Stefan Ritt on Fri Mar 18 11:07:50 2011
|
| Louis de Leseleuc wrote: |
|
I noticed a behavior that might be irritating.
After attaching/uploading files to an entry and before submitting it, one might press 'Back' or close the browser window.
This in effect cancels the entry and sends into oblivion. HOWEVER the attachments and their thumbnail files remain on the server forever.
Would there be a way to either delete attachments after some time if they don't show up in an entry? Or some other magic trick with the browser? My logbook directories are already full of orphan files that I need to seek and destroy.
Also, any thoughts on automatically cleaning up a logbook directory when the damage is done?
Louis
|
Well, this is not so easy. When you leave the browser (via 'Back' or just by closing), it has no way to communicate with the elog server. I could put in some JavaScript, but if people switch off JavaScript there is no way. On the other hand it might be simple to write just a little shell script, which goes through all files on the server and checks if the file name occurs in some elog entry. This can probably be done with some combination of "find" and "grep", but I'm not a shell script expert. |
|
Re: Cleaning up attachments, posted by Louis de Leseleuc on Mon Mar 21 17:42:15 2011
|
| Stefan Ritt wrote: |
|
| Louis de Leseleuc wrote: |
|
I noticed a behavior that might be irritating.
After attaching/uploading files to an entry and before submitting it, one might press 'Back' or close the browser window.
This in effect cancels the entry and sends into oblivion. HOWEVER the attachments and their thumbnail files remain on the server forever.
Would there be a way to either delete attachments after some time if they don't show up in an entry? Or some other magic trick with the browser? My logbook directories are already full of orphan files that I need to seek and destroy.
Also, any thoughts on automatically cleaning up a logbook directory when the damage is done?
Louis
|
Well, this is not so easy. When you leave the browser (via 'Back' or just by closing), it has no way to communicate with the elog server. I could put in some JavaScript, but if people switch off JavaScript there is no way. On the other hand it might be simple to write just a little shell script, which goes through all files on the server and checks if the file name occurs in some elog entry. This can probably be done with some combination of "find" and "grep", but I'm not a shell script expert.
|
How about this:
Whenever a new file is uploaded, it would first be stored in a temporary directory. When the entry gets submitted, the files would be moved to the logbook directory and the entry edited accordingly.
Any wrongfully stored file would remain in that temp dir. Starting/restarting the daemon would cleanup that directory. Seems like a simpler approach and does not involve scripting the browser. |
|
Re: Checks on datetime seconds field generate warning in IE7, posted by Stefan Ritt on Thu Jul 2 08:36:57 2009
|
| Richard Stamper wrote: |
|
When adding a log entry containing a datetime field using the IE7 browser a Javascript warning is displayed - see the attachment. This is due to a change in the naming of the "seconds" field of a datetime entry (made in version 2143) not being propagated to the code that generates the Javascript that checks the supplied values.
Suggested patch follows.
Change "s%d" to "c%d" in lines 9675 and 9678.
Showing lines 9675-9680 below, change from:
rsprintf(" if (document.form1.s%d.value == \"\") {\n", i);
sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
rsprintf(" alert(\"%s\");\n", str);
rsprintf(" document.form1.s%d.focus();\n", i);
rsprintf(" return false;\n");
rsprintf(" }\n");
to:
rsprintf(" if (document.form1.c%d.value == \"\") {\n", i);
sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
rsprintf(" alert(\"%s\");\n", str);
rsprintf(" document.form1.c%d.focus();\n", i);
rsprintf(" return false;\n");
rsprintf(" }\n");
Regards,
Richard Stamper
|
This is absolutely correct, even the right fix. I put that into the distribution. Thanks a lot. |
|
Re: Checking logging before posting, posted by Stefan Ritt on Fri Apr 5 10:07:57 2013
|
| Daniel Campora wrote: |
|
Hi there,
Here's a bit of a special scenario. There's no server-side check the user is logged in upon posting, but it rather seems the server relies on the post data sent from the form.
An example of this can be triggered on a write restricted elog, by hitting on New and logging out in another tab. Then posting, from the first tab, will post as if the user was logged on. Hitting back and posting again also works.
Cheers
|
Yes the credentials are stored in the form where you enter your text. This has following reason: In a shared environment (several people sitting around a computer) we want to identify who submits an elog entry, but not bother the person to enter his/her password every few minutes. So in our experiment I set the time-out to 15 min, meaning after 15 minutes of inactivity a user gets logged out. If the user accesses ELOG every ten minutes or so, he/she stays logged in for a whole shift, which is what you want. Now the problem is that one starts an elog entry, waits twenty minutes, then wants to submit it, but you are bought back to the login screen and your entry is gone. Therefore I store the credentials (encrypted) in the form, so that the form can even be submitted after 20 minutes. Users at our lab are pretty happy with this solution.
In fact there is no way you can 100% ensure that the logged in user submits an entry without asking for his/her password during the submit. Even if the time span above is only very short, it still can happen that someone starts an entry, leaves the room, and someone else submits it. So people got used to the good practice not to leave any unfinished elog entry open when they go or leave the browser (to another tab for example). If I would implement to password request during the submit, there would be two problems: 1) Users will heavily complain and 2) I have to store the form data temporary (together with some optional attachments) on the server side, start a password query, and only if that succeeds submit the entry. This is somehow complicated to implement since I cannot use the normal elog database. Then I have to care about dangling entries (like if the password was wrong I should delete the temporary data???) and so on.
I plan for the future a kind of "draft" mode, where entries can be stored as "drafts" (like in most email systems). You get an auto-save every few minutes, and can work on the draft before actually submitting it. In that case your password query could be implemented more easily. But implementing the draft mode needs a change of the database system, so I have to find time to do that.
Best regards,
Stefan |
Re: Changing width in entry mode, posted by Stefan Ritt on Fri Nov 18 21:30:44 2005 
|
| Ulrich Trüssel wrote: | | Problem: see pic "Eingabe.jpg", if thre are more MOptions to select in entry mode, I have to scroll from right to left all the time. Ti s isn't really comfortable. |
I had a nowrap statement in the MOptions check boxes, which should not be there. I removed that and now the options are wrapped nicely: The problem is that in HTML, the check boxes and the associated text are sometimes ripped apart, i.e. the box appears at the right corner and the text at the next line. That's why I had the nowrap statement there.This fix will be contained in the next release of elog. |
Re: Changing width in entry mode, posted by Ulrich Trüssel on Sat Nov 19 11:57:49 2005
|
| Stefan Ritt wrote: |
| Ulrich Trüssel wrote: | | Problem: see pic "Eingabe.jpg", if thre are more MOptions to select in entry mode, I have to scroll from right to left all the time. Ti s isn't really comfortable. |
I had a nowrap statement in the MOptions check boxes, which should not be there. I removed that and now the options are wrapped nicely:
The problem is that in HTML, the check boxes and the associated text are sometimes ripped apart, i.e. the box appears at the right corner and the text at the next line. That's why I had the nowrap statement there.
This fix will be contained in the next release of elog. |
Thank you Stefan!!! 
Just as an idea: Some People may find it usefull to have the norap statement in the code. If it's possible for a future release it may be nice to have a flag for this feature! |
|