Problems with elog client, posted by Yoshio Imai on Wed Apr 9 14:41:12 2008
|
Hi!
Since our upgrade to elog 2.7.3, it is not possible any more to edit an existing elog entry using the elog client with -e <id> option. The only console output is "Error transmitting message". Submitting an entry via the client is not problem.
Running the server with -v option does not yield any output at the time of the edit attempt. Running the client with -v option also doesn't help, because whatever the other options, only the help page is printed out and nothing else done. Btw, there is now a conflict between -s for "use SSL" and -s for the "subdir" option.
Any ideas?
Yoshio |
Re: Problems with elog client, posted by Yoshio Imai on Thu Apr 10 14:21:13 2008
|
I have tried the new revision, recompiling both client and server.
Unfortunately, the overall situation has not changed. We can still create new entries using the elog client, but editing an existing entry still does not work. However, thanks to your patch, the -v option now works again for the client side:
> elog -s -h <elog server> -p 443 -l current -u <user> <password> -a <Attributes> "TEST ENTRY"
Message successfully transmitted, ID=1
> elog -s -h <elog server> -p 443 -l current -u <user> <password> -e 1 "EDIT THIS ENTRY" -v
Successfully connected to host <elog server>, port 443
Request sent to host:
GET /current/1?cmd=download HTTP/1.0
User-Agent: ELOG
Cookie: unm=<user>;upwd=<password>;
Response received:
ET
Error transmitting message
Again, there is no output on the server side even when running with -v in console mode. There is the expected output when an entry is successfully created using the elog client. One aspect about this output is strange, though: the "Return" statement==== Return ================================
HTTP/1.1 302 Found contains the wrong "Location" header. It is notLocation: https://elog-server.domainname/logbook/ID but ratherLocation: https://client-host.domainname/logbook/ID where "client-host" is the hostname of the computer where the elog client was called. But, since the logbook entry is correctly created, this is perhaps not a problem at all.
Another thing: I have noticed that when using conditional preset texts, the "Preset Text =" statements have to be declared for each logbook of a logbook group; it is not sufficient to only declare it in the "[global]" section of the logbook group. This means that we only need to declare the conditions once, e.g.
Options Category = .... , Shift {1} , ....
{1} Options Subject = Shift start {a}, Shift end {b}, ....
but the preset text declarations{1&a} Preset text = shift_checklist.txt
{1&b} Preset text = shift_summary.txthave to be declared in every individual logbook section for the logbooks of this group. Is this expected behaviour, or a bug?
Cheers
Yoshio |
Re: Problems with elog client, posted by Yoshio Imai on Thu Apr 10 15:56:12 2008
|
| Stefan Ritt wrote: | | As I wrote in my previous message, the "SSL part has not been tested" (=means: does not work). |
Sorry for the misunderstanding. I was probably confused because the creation of new entries already worked, even with SSL.
Now, the editing also works.
Thank you very much!
Yoshio |
|
Re: Problems with elog client, posted by Yoshio Imai on Thu Apr 17 19:11:36 2008
|
I have tried your sample config file, and this one also works for me.
The problem arises when using top groups. I have produced a minimal config file including a top group, of the form
[global]
logbook tabs = 1
SSL = 1
Theme = default
Top group testgroup = demo1, demo2
Show top groups = 1
[global testgroup]
Attributes = Author, Subject, Type
Options Subject = ThisOne{1}, Shift info {2}, ThatOne{3}
{1} Options Type = OneType1, OneType2, OneType3
{2} Options Type = Shift start {a}, Shift end {b}, Info
{3} Options Type = TwoType1, TwoType2, TwoType3
Required Attributes = Author, Subject, Type
{2&a} Preset Text = shift_checklist.txt
{2&b} Preset Text = shift_summary.txt
[demo1]
Comment = DemoLog 1
[demo2]
Comment = DemoLog 2
Although the conditional attributes work for the logbooks demo1 and demo2, the preset text does not work. It works when the Preset Text= statement is (also) places in the individual logbook sections. Can you check if it behaves the same on your side?
Yoshio |
|
Re: Problems with elog client, posted by Yoshio Imai on Fri Apr 18 14:17:52 2008
|
| Stefan Ritt wrote: | | I fixed that in SVN revision 2103, please download and test it. |
I just downloaded and tested it. It works!!
Thank you for all the work.
Yoshio |
|
Re: Access Control, posted by Yoshio Imai on Tue May 13 16:58:40 2008
|
| Grant Jeffcote wrote: | | At present we can give others a full view by adding them to the 'Users' list for each individual logbook, this unfortunately also gives them 'write' access. |
I think the solution to your problem would be to use Deny statements in the configuration sections for the logbooks.
Assume user1, user2 and user3 are in the "owners'" group of logbook1, and user4 and user5 only have "privileged read" access. Then a configuration as follows might help:
Login user = user1, user2, user3, user4, user5
Deny New = user4, user5
Deny Reply = user4, user5
Deny Duplicate = user4, user5
Deny Edit = user4, user5
Deny Delete = user4, user5
Deny Select = user4, user5
Deny CSV Import = user4, user5
This should give them the same read permissions as the logbook owners but should deny any writing operations. I recognize that this is a little bit of admin work if the lists of such "privileged readers" gets long, but each user would have his/her individual password (even the same as for access to his/her "own" logbook).
Perhaps you can give it a try. |
|
Error messages while creating thumbnails, posted by Yoshio Imai on Wed Jul 9 19:57:50 2008
|
Hi again!
I have recently noticed that elog often creates large accumulations of the following group of error messages in our syslog:
Jul 9 19:05:00 elogd[27009]: Falling back to default group "elog"
Jul 9 19:05:00 elogd[27009]: Falling back to default user "elog"
Jul 9 19:05:02 elogd[27009]: Cannot restore original GID/UID.
Jul 9 19:05:02 elogd[27009]: Cannot remove pidfile "/var/run/elogd.pid" ; Permission denied
Jul 9 19:05:05 elogd[27013]: Falling back to default group "elog"
Jul 9 19:05:05 elogd[27013]: Falling back to default user "elog"
Jul 9 19:05:05 elogd[27013]: Cannot restore original GID/UID.
Jul 9 19:05:05 elogd[27013]: Cannot remove pidfile "/var/run/elogd.pid" ; Permission denied
Jul 9 19:05:05 elogd[27016]: Falling back to default group "elog"
Jul 9 19:05:05 elogd[27016]: Falling back to default user "elog"
Jul 9 19:05:06 elogd[27016]: Cannot restore original GID/UID.
Jul 9 19:05:06 elogd[27016]: Cannot remove pidfile "/var/run/elogd.pid" ; Permission denied
I have further found out that these coincide with the generation of attachment thumbnails (i.e. every time a user displays an entry generated before the advent of ImageMagick support for the first time, and every time the preview pictures are scaled/rotated while editing an entry).
The PID-file is indeed owned by the root user and not elog, but is correctly cleaned up at termination of the elog server.
Jul 9 19:47:08 elogd[27335]: elogd server aborted.
Jul 9 19:47:16 elogd[27359]: elogd 2.7.3 built Apr 18 2008, 14:08:31
Jul 9 19:47:16 elogd[27359]: revision 2104
Jul 9 19:47:16 elogd[27359]: Falling back to default group "elog"
Jul 9 19:47:16 elogd[27359]: Falling back to default user "elog"
Jul 9 19:47:16 elogd[27360]: Falling back to default group "elog"
Jul 9 19:47:16 elogd[27360]: Falling back to default user "elog"
Jul 9 19:47:16 elogd[27360]: Cannot restore original GID/UID.
Jul 9 19:47:16 elogd[27360]: Cannot remove pidfile "/var/run/elogd.pid" ; Permission denied
Jul 9 19:47:16 elogd[27359]: ImageMagick detected
Does this point at some sort of problem?
Another question concerning the thumbnails of multi-page PDF-files: would it make sense to restrict the thumbnail generation to the first page? Since this is the title page, which in most cases is the only relevant page (really reading the file from the thumbnails is usually not possible anyway), this could help keep the attachment display less crowded ...
Thanks for the work and continuing support!
Yoshio |
|
Re: 2 questions :: different colors in list view based on "type" + change verbage of "type", posted by Yoshio Imai on Fri Aug 8 14:20:27 2008
|
| dale cooper wrote: | | I'd love to display in the LIST VIEW (full, summary, or threaded views) different color's based on which TYPE was selected... |
You can achieve this by using a "style" directive for this attribute. E.g. if your attribute is called "Shift" and entries with value "Day" should be green, value "Swing" should be blue, you should addStyle Shift Day = background-color:green
Style Shift Swing = background-color:blue (and so on) to the config file.
| Quote: | | really I am just wondering if I can change the verbage that ELOG is using for the term TYPE? Is that doable? |
As long as I am not missing a key point in your problem, you should be able to define the names of your logbook attributes simply with the "Attribute" directive. So, if you want the users to enter the shift and the name of the shift leader, you would put a lineAttributes = Shift, Shift leader
Options Shift = Day, Swing, ... <and so on>
Options Shift leader = Mike, Edward, John, ... <and so on> and the logbook display should correctly show "Shift" and "Shift leader" in the header line of each entry ... |
|