ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68407
|
Thu Aug 25 19:04:11 2016 |
| Darren Hollinrake | hollinrakedp@gmail.com | Question | Windows | V3.1.1-3f311c5 | Re: elog client cmd line submission of attributes with spaces. | Agreed, I just wanted to clarify for anyone else though that the issue seems to be centered on my "Start Time" attribute which is a datetime field. All the other attributes (with spaces) allowed submission of the entry so long as the "Start Time" attribute wasn't set to required. That appears to be the one with the actual issue. Giving a valid epoch time when that field isn't required allows the field to be populated correctly. However, if the "Start Time" attribute is required (same epoch time used when it wasn't a required field), I again receive the error that the "Start Time" attribute is missing.
Rudy Taraschi wrote: |
Darren Hollinrake wrote: | Thanks for the response. You are indeed correct that the issue disappears when I comment out my required attributes line. If I just remove my "Start Time" attribute, all the other attributes work as well. |
I used to just comment out that one field in Required Attributes as well, but it was a pain to edit the CFG file, so I took the lazy approach and just commented out the whole line - less typing |
|
66053
|
Mon Nov 17 11:20:28 2008 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.7.5-2135 | Re: elog client can set arbitrary values to locked attributes |
David Potterveld wrote: |
When submitting entries via the elog client, I find that I can set arbitrary values for attributes that are supposedly "preset" and "locked".
As an example, I have in my elogd.cfg file:
[global]
...
Group Operations = Accelerator
Top group ATLAS = Operations
...
[global ATLAS]
Attributes = Experiment, Author, Author Email, Category, Subject
Required Attributes = Category, Subject
Options Category = Routine entry, Shift summary, Problem, Fix, Question, Info, Other
Extendable Options = Category
Preset Experiment =
Preset Author = $long_name
Preset Author Email = $user_email
Locked Attributes = Experiment, Author, Author Email
...
[Accelerator]
Attributes = Author, Author Email, Category, Subject
Options Category = Routine entry, Shift summary, Problem, Fix, Question, Info, Other
...
This works as intended with a web client (firefox). The Author and Author Email attributes are preset and unchangeable.
However, if I use the elog client, as in:
elog -v -h my.apache-proxy.server -d elog -l Accelerator -p 443 -s -u johndoe xxxxx -a Category=LN -a Subject=Test -a Author=IDoNotExist -n 1 -m entry.txt
(johndoe is an existing user)
The entry is created with "IDoNotExist" as the Author name, instead of the correct name for the user johndoe,
and the Author Email attribute is blank.
Is there a way to enforce preset and locked attributes in the elogd server? (As a client could connect
with any arbitrary software, not just elog.)
|
Indeed "preset" and "locked" attributes are not obeyed if entries are submitted via the elog tool. The is because if you use a browser, the input form is created by elogd. If you use a locked attribute, the input filed for that attribute is not shown for example. If you use the elog tool, it directly submits an entry not knowing anything about the input form. To make this work, elog would first have to request the input form, then interprete all the HTML, figure out if an attribute is locked or not, then display an error if you try to submit that attribute. Since parsing of HTML is not implemented in elog, this is currently not possible.
Originally I thought that this is not such a problem. Mostly elog is used to produce some automatic entries, where the authorship is of minor interest. But I guess you are afraid that one use could submit an entry under another user's name, right? Well, I hoped that in scientific collaborations nobody is that evil ;-)
Well, I will try to do something here in order to fix this. Will come back to you. |
66054
|
Mon Nov 17 11:39:03 2008 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.7.5-2135 | Re: elog client can set arbitrary values to locked attributes | Actually I found a way around. The "Subst xxx" is evaluated after you submit an entry, so it also works for the elog tool. So all you need in your config file is:
Subst Author = $long_name
and it will do the job. |
1801
|
Fri Apr 7 10:29:49 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.6.1-1671 | Re: elog client authentication and attachment comment |
Yoshio Imai wrote: | Until revision 1642, it was possible to submit entries to a password-protected logbook using the elog client without supplying authentication information. With revision 1671 this is no longer possible. In principle this is good. However, many of our run control programs use the elog client (via rsh to the elog server computer) to submit automatic entries, which fails now. In order for this mechanism to work again, we would have to change the command-line call in the sources, including now the password in clear text. Since this can be considered a security issue, we would like to avoid it if at all possible. I guess my request would go in the direction of PAM support, but would it be possible to revert to the old behaviour as an option? (If you tell me where in the code to look, we could probably also comment out the respective lines ourselves so that you don't have extra work...) |
There was a quite strong request to not allow unauthorized access via the elog utility. People were also able to submit entries with the "curl" program without supplying authorization. So I rather would not like to go back to the old version. But I would propose a different scheme: We could save the username/password in a file on the server, which is maybe readable only by the owner. Then one could call elog with
elog ... -u @filename
so that the user name and password gets retrieved from the file on the server. This way the password does not have to be passwd over the network. BTW, you also could use ssh instead of rsh to prevent password being sent over the network in plain text.
Quote: |
The second remark is about attachment comments. When editing a logbook entry, the attachment upload buttons appear again, but without the comment. Shouldn't it be there, too? |
I'll have a look and fix it. |
1803
|
Mon Apr 10 20:08:02 2006 |
| Yoshio Imai | | Question | Linux | 2.6.1-1671 | Re: elog client authentication and attachment comment |
Stefan Ritt wrote: | We could save the username/password in a file on the server, which is maybe readable only by the owner. |
I have discussed it with the others, and it sounds like a good idea. There is only the debate whether it should be readable by the owner or by the root user of the elog server. I can't tell at the moment which is more favourable ... |
66977
|
Wed Dec 15 16:42:32 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.8 | Re: elog as a service in windows not detect Imagemagick |
Diego Obradors Campos wrote: |
I have installed elog 2.8 in a windows pc with the installer from the distribution, it installs elog as a windows service, which is started automatically when windows starts.
It is done as:
"C:\Archivos de programa\ELOG\elogd.exe" -D -c "C:\Archivos de programa\ELOG\elogd.cfg"
Moreover Imagemagick and GhostScript are in the path:
Version: ImageMagick 6.6.4-6 2010-09-21 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP
However the indexing loogbooks are only working fine when elog is started interactively. Is there any posiblity to start elog as a service and use thumbnails for quick preview?
Thank you in advance!
|
This is a know problem. I did not achieve to create the imagemagic subprocess and read its output when elogd is started as a service. Attached is the code doing that, I found it as an example from Microsoft. But even after hours of work, I could not get it running inside the service. If anybody has any idea, please let me know. |
Attachment 1: my_shell.c
|
int my_shell(char *cmd, char *result, int size)
{
HANDLE hChildStdinRd, hChildStdinWr, hChildStdinWrDup,
hChildStdoutRd, hChildStdoutWr, hChildStderrRd, hChildStderrWr, hSaveStdin, hSaveStdout, hSaveStderr;
SECURITY_ATTRIBUTES saAttr;
PROCESS_INFORMATION piProcInfo;
STARTUPINFO siStartInfo;
char buffer[10000];
DWORD dwRead, dwAvail, i;
/* Set the bInheritHandle flag so pipe handles are inherited. */
saAttr.nLength = sizeof(SECURITY_ATTRIBUTES);
saAttr.bInheritHandle = TRUE;
saAttr.lpSecurityDescriptor = NULL;
/* Save the handle to the current STDOUT. */
hSaveStdout = GetStdHandle(STD_OUTPUT_HANDLE);
/* Create a pipe for the child's STDOUT. */
if (!CreatePipe(&hChildStdoutRd, &hChildStdoutWr, &saAttr, 0))
return 0;
/* Set a write handle to the pipe to be STDOUT. */
if (!SetStdHandle(STD_OUTPUT_HANDLE, hChildStdoutWr))
return 0;
/* Save the handle to the current STDERR. */
hSaveStderr = GetStdHandle(STD_ERROR_HANDLE);
/* Create a pipe for the child's STDERR. */
if (!CreatePipe(&hChildStderrRd, &hChildStderrWr, &saAttr, 0))
return 0;
/* Set a read handle to the pipe to be STDERR. */
if (!SetStdHandle(STD_ERROR_HANDLE, hChildStderrWr))
return 0;
/* Save the handle to the current STDIN. */
hSaveStdin = GetStdHandle(STD_INPUT_HANDLE);
/* Create a pipe for the child's STDIN. */
if (!CreatePipe(&hChildStdinRd, &hChildStdinWr, &saAttr, 0))
return 0;
/* Set a read handle to the pipe to be STDIN. */
if (!SetStdHandle(STD_INPUT_HANDLE, hChildStdinRd))
return 0;
/* Duplicate the write handle to the pipe so it is not inherited. */
if (!DuplicateHandle(GetCurrentProcess(), hChildStdinWr, GetCurrentProcess(), &hChildStdinWrDup, 0, FALSE, /* not inherited */
DUPLICATE_SAME_ACCESS))
return 0;
CloseHandle(hChildStdinWr);
/* Now create the child process. */
memset(&siStartInfo, 0, sizeof(siStartInfo));
siStartInfo.cb = sizeof(STARTUPINFO);
siStartInfo.lpReserved = NULL;
siStartInfo.lpReserved2 = NULL;
siStartInfo.cbReserved2 = 0;
siStartInfo.lpDesktop = NULL;
siStartInfo.dwFlags = 0;
/* command to execute */
sprintf(buffer, "cmd /q /c %s", cmd);
if (!CreateProcess(NULL, buffer, /* command line */
NULL, /* process security attributes */
NULL, /* primary thread security attributes */
TRUE, /* handles are inherited */
0, /* creation flags */
NULL, /* use parent's environment */
NULL, /* use parent's current directory */
&siStartInfo, /* STARTUPINFO pointer */
&piProcInfo)) /* receives PROCESS_INFORMATION */
return 0;
/* After process creation, restore the saved STDIN and STDOUT. */
SetStdHandle(STD_INPUT_HANDLE, hSaveStdin);
SetStdHandle(STD_OUTPUT_HANDLE, hSaveStdout);
SetStdHandle(STD_ERROR_HANDLE, hSaveStderr);
memset(result, 0, size);
do {
/* query stdout */
do {
if (!PeekNamedPipe(hChildStdoutRd, buffer, 256, &dwRead, &dwAvail, NULL))
break;
if (dwRead > 0) {
ReadFile(hChildStdoutRd, buffer, 256, &dwRead, NULL);
buffer[dwRead] = 0;
strlcat(result, buffer, size);
}
} while (dwAvail > 0);
/* query stderr */
do {
if (!PeekNamedPipe(hChildStderrRd, buffer, 256, &dwRead, &dwAvail, NULL))
break;
if (dwRead > 0) {
ReadFile(hChildStderrRd, buffer, 256, &dwRead, NULL);
buffer[dwRead] = 0;
strlcat(result, buffer, size);
}
} while (dwAvail > 0);
/* check if subprocess still alive */
if (!GetExitCodeProcess(piProcInfo.hProcess, &i))
break;
if (i != STILL_ACTIVE)
break;
/* give some CPU to subprocess */
Sleep(10);
} while (TRUE);
CloseHandle(hChildStdinWrDup);
CloseHandle(hChildStdinRd);
CloseHandle(hChildStderrRd);
CloseHandle(hChildStdoutRd);
/* strip trailing CR/LF */
while (strlen(result) > 0 && (result[strlen(result) - 1] == '\r' || result[strlen(result) - 1] == '\n'))
result[strlen(result) - 1] = 0;
return 1;
}
|
1649
|
Fri Feb 3 18:25:32 2006 |
| Dimitrios Tsirigkas | dimitrios.tsirigkas@cern.ch | Question | Linux | 2.6.1 | Re: elog allows me to create user "blahblah " | By the way, it is also possible to create a user that doesn't have a password! Shouldn't that be forbidden?
Dimitris |
1652
|
Mon Feb 6 12:54:25 2006 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.6.1 | Re: elog allows me to create user "blahblah " |
Dimitrios Tsirigkas wrote: | By the way, it is also possible to create a user that doesn't have a password! Shouldn't that be forbidden? |
Well, some people want that! |
|