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. |
Mail are no longer sent from the logged in user in 2.9.0, posted by Olivier Callot on Wed Mar 23 10:01:01 2011
|
We upgraded to Elog 2.9.0-2402 and since then mails sent by Elog when posting an item are from the default account, not from the logged in user's mail address.
The configuration is, for the mail part :
Default Email From = Olivier.Callot@cern.ch
Use Email Subject = ELOG Computing Operations - $Subject ($Site - $System - $Production number)
Thanks for telling me which flag/option I have to set to restore the proper mail 'From:' field. |
|
Re: Mail are no longer sent from the logged in user in 2.9.0, posted by Stefan Ritt on Fri Apr 1 10:54:29 2011
|
| Olivier Callot wrote: |
|
We upgraded to Elog 2.9.0-2402 and since then mails sent by Elog when posting an item are from the default account, not from the logged in user's mail address.
The configuration is, for the mail part :
Default Email From = Olivier.Callot@cern.ch
Use Email Subject = ELOG Computing Operations - $Subject ($Site - $System - $Production number)
Thanks for telling me which flag/option I have to set to restore the proper mail 'From:' field.
|
Thanks for reporting this bug. I have fixed it in SVN revision 2407. |
|
Elog 2.9.0 buffer overflow crash bug ubuntu linux, posted by John Rouillard on Sun Apr 10 01:49:01 2011
|
When running openvas (a nessus fork) against elog 2.9.0 I provoked the following crash:
Apr 9 17:32:06 unixland elogd[1300]: POST / HTTP/1.0#015#012Host: unixland.home
#015#012Content-Length: -800#015#012#015#012XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Apr 9 17:32:06 unixland kernel: [664894.491242] elogd[1300]: segfault at b7713d
2e ip 080b6956 sp bf8d5ea0 error 4 in elogd[8048000+96000]
openvas reports that it was testing for CVE-2002-1212 when the crash occurred.
Startup info:
Apr 9 19:35:54 unixland elogd[21584]: elogd 2.9.0 built Apr 9 2011, 17:49:08
Apr 9 19:35:54 unixland elogd[21584]: revision 2411
-- rouilj |
Self Register = 3 doesn't work any longer, posted by Olivier Callot on Wed Apr 13 10:51:34 2011
|
With the recent Elog 2.9.0 rev 2412 the Self Register = 3 option doesn't work as expected: The user is immediately allowed to login. This is not what this option was doing, which is to wait for an approval by the administrator. Can this behaviour be restored, or should I change the value of the Self Register flag? Thanks |
Re: Self Register = 3 doesn't work any longer, posted by Stefan Ritt on Fri Apr 15 08:37:21 2011 
|
| Olivier Callot wrote: |
|
With the recent Elog 2.9.0 rev 2412 the Self Register = 3 option doesn't work as expected: The user is immediately allowed to login. This is not what this option was doing, which is to wait for an approval by the administrator. Can this behaviour be restored, or should I change the value of the Self Register flag? Thanks
|
Are you sure about that (maybe used an older revision of elogd where this indeed was a problem?). The current V2.9.0-2412 gives me this:
If I then log in as the admin user, I see the configuration of the new user, but the account is not activated:
So the user cannot log in. The config file is:
[global]
port = 8080
password file = passwd
smtp host = mail.psi.ch
Self register = 3
Admin user = stefan
[demo1]
Attributes = Project, Category
Can you double check?
|
|
Re: Elog 2.9.0 buffer overflow crash bug ubuntu linux, posted by Stefan Ritt on Fri Apr 15 08:49:26 2011
|
> When running openvas (a nessus fork) against elog 2.9.0 I provoked the following crash:
>
> Apr 9 17:32:06 unixland elogd[1300]: POST / HTTP/1.0#015#012Host: unixland.home
> #015#012Content-Length: -800#015#012#015#012XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> Apr 9 17:32:06 unixland kernel: [664894.491242] elogd[1300]: segfault at b7713d
> 2e ip 080b6956 sp bf8d5ea0 error 4 in elogd[8048000+96000]
>
> openvas reports that it was testing for CVE-2002-1212 when the crash occurred.
>
> Startup info:
>
> Apr 9 19:35:54 unixland elogd[21584]: elogd 2.9.0 built Apr 9 2011, 17:49:08
> Apr 9 19:35:54 unixland elogd[21584]: revision 2411
>
> -- rouilj
I haven't tried openvas, but added a check for the negative content-length you have in the request
above in SVN revision 2413. Can you try if it still crashes?
- Stefan |