Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 222 of 801  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Version Subjectdown
  1685   Fri Feb 10 22:31:38 2006 Reply Steve Jonessteve.jones@freescale.comQuestionOther2.6.1Re: compiling elog 2.6.1 on solaris platform

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:
Ok, I see what you did. I took a different route since I was not sure how the gnu linker would handle the fact that there would be two declarations of the forkpty() function when compiled and linked under Linux. Instead, I created a separate forkpty.c module and compiled it separately. Then, if "solaris", link it in. Otherwise, use library "util" which already has forkpty().

So, since it seems to work under Linux, any idea which function is being used?


No, there are no two forkpty() function, due to the
#ifdef OS_SOLARIS

  forkpty(...)
  {
    ...
  }

#endif

conditional compiling. So if I compile under Linux, the variable OS_SOLARIS is not defined, and therefore the special forkpty does not get compiled. Instead the one from the library is taken, since under Linux I use the -libutil switch. Under Solaris, there is no -libutil, but the OS_SOLARIS gets set, and therefore we have the code right inside elogd.c


Steve Jones wrote:

Got it. Much easier than how I was going about it.



BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS. When I run 'make -P' or 'gmake -P' the environment variable 'OSTYPE' is already set to 'solaris'. This is the reason the original Makefile did not work on our solaris systems. I'm not sure if this is universal but it applies to the systems we run (Solaris 8 and 9).
  1686   Fri Feb 10 22:35:20 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionOther2.6.1Re: compiling elog 2.6.1 on solaris platform

Steve Jones wrote:
BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS.


Ok, what about adding:
ifeq ($(OSTYPE),SunOS)
OSTYPE=solaris
endif
  1687   Mon Feb 13 18:22:08 2006 Reply Steve Jonessteve.jones@freescale.comQuestionOther2.6.1Re: compiling elog 2.6.1 on solaris platform

Stefan Ritt wrote:

Steve Jones wrote:
BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS.


Ok, what about adding:
ifeq ($(OSTYPE),SunOS)
OSTYPE=solaris
endif



Steve Jones wrote:

That would work, but my question is "why is this statement needed at all?" In GNU-land it appears that the make utilities use the canonical names rather than the ones returned by the OS. When I simply comment out this section, the solaris compile works fine. Perhaps it does not on other platforms?

Also, I ran into another snag. The include file "pty.h" does not appear to exist in solaris-land, so I am seeing if there is one made available elsewhere.
  1700   Mon Feb 20 17:52:06 2006 Smile Steve Jonessteve.jones@freescale.comQuestionOther2.6.1Re: compiling elog 2.6.1 on solaris platform

Steve Jones wrote:

Stefan Ritt wrote:

Steve Jones wrote:
BTW, Stefan, this code in Makefile does not work on Solaris
OSTYPE = $(shell uname)
.
.
.
ifeq ($(OSTYPE),solaris)
At least, not on our solaris systems. 'uname' returns SunOS.


Ok, what about adding:
ifeq ($(OSTYPE),SunOS)
OSTYPE=solaris
endif



Steve Jones wrote:

That would work, but my question is "why is this statement needed at all?" In GNU-land it appears that the make utilities use the canonical names rather than the ones returned by the OS. When I simply comment out this section, the solaris compile works fine. Perhaps it does not on other platforms?

Also, I ran into another snag. The include file "pty.h" does not appear to exist in solaris-land, so I am seeing if there is one made available elsewhere.


In working with Stefan changes were made so that the latest release should once again cross-compile fine, and Makefile also works under Solaris. Great job Stefan!
  68597   Fri Apr 7 12:16:24 2017 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux3.1.1Re: command line and apache+ldap authentication

Hi, the elog command line client does not know anything about Apache authentication, therefore the authentication with the elog username/password fails. As an alternative to the command line client you can use the "curl" utility (available under Linux). This tools has the "-u" flag, which works with Apache. The tricky thing is now to "emulate" your browser submitting an entry. You can do

$ curl -u <username>:<password> -F cmd=Submit -F Author=CURL -F Text="This is the CURL text" http://<your host>:8080/<logbook>

(of course your attributes might be different than "Author"). If you have a multiline text body, you can read that from a file (in this case "file.txt"):

$ curl -u <username>:<password> -F cmd=Submit -F Author=CURL -F Text="@file.txt" http://<your host>:8080/<logbook>

When I wrote "elog" orginiallly (199x?), "curl" was not available or at least I didn't know of. Right now it almoste completely can replace the elog tool.

Stefan

  67961   Fri Jun 5 19:08:17 2015 Reply Andreas Luedekeandreas.luedeke@psi.chQuestionLinux3.1.0-2Re: ckeditor "Insert Timestamp" bug (was: Three problems with elogd 3.1.0-2)
I can confirm that there is currently a problem with the ckeditor "Insert Timestamp" button.
It apparently calls javascript code in ckeditor/plugins/timestamp/plugin.js
to catch a string from the URL "../../?cmd=gettimedate"
(I think this is one too many "../", but anyway). if you try this for the Forum:
https://midas.psi.ch/elogs/Forum/?cmd=gettimedate
it returns the wrong string. It is "Forum" instead of the date.

PS to David: The subject "Three problems ..." is not giving any indication what it is about. I would find it better in this case to post three entries to the Forum, each with a striking title :-)

David Wallis wrote:

Additional info:

"Time format = %Y" results in "2015" being pasted into the edit window when I hit the "time stamp" button.

"Time format = %m/%Y" results in the string "06/2015"

"TIme format = %m/%d/%Y" results in the string "06/04"

"Time format = %m/%d %H" results in the string "06/04 "

David Wallis wrote:

I just updated to the latest official release (V3.1.0-2411f95) and have these problems:

  1. The Time Stamp button pastes the logbook name when "Time format" is not specified in elogd.cfg, and when it is set to "%m/%d/%Y %H:%M", it adds the string "5/28/."
  2. Drag and drop for attachments dosn't work on either Chrome 37.0.2062.94 (64-bit) or FIrefox 31.5.3 (both on Linux). D&D works on the midas.psi.ch demo page. On my logbooks, the "drop attachements here" area does not have a dashed line border
  3. Auto-saving does not seem to be working.

The "Syntax of elogd.cfg" help file doesn't seem to reflect some of these features... it took me a while to find the settings for LDAP authentication. Am I just missing some settings for these features?

My users are loving the new functionality added in 3.1!

 

 

  67963   Fri Jun 5 23:02:06 2015 Reply David Walliswallis@aps.anl.govQuestionLinux3.1.0-2Re: ckeditor "Insert Timestamp" bug (was: Three problems with elogd 3.1.0-2)

Andreas,

I too was able to track the problem down to the "gettimedate" function in elogd.c. It looks like the code is using a variable named "str" for several different purposes. I haven't had a chance to do any testing, but my suspsicion is that the size of the dynamically allocated variable is ending up too small for the time stamp string, so it gets truncated.

 

Your point about the topic title is a good one - I'll split this into separate issues, thanks!

Andreas Luedeke wrote:
I can confirm that there is currently a problem with the ckeditor "Insert Timestamp" button.
It apparently calls javascript code in ckeditor/plugins/timestamp/plugin.js
to catch a string from the URL "../../?cmd=gettimedate"
(I think this is one too many "../", but anyway). if you try this for the Forum:
https://midas.psi.ch/elogs/Forum/?cmd=gettimedate
it returns the wrong string. It is "Forum" instead of the date.

PS to David: The subject "Three problems ..." is not giving any indication what it is about. I would find it better in this case to post three entries to the Forum, each with a striking title :-)

David Wallis wrote:

Additional info:

"Time format = %Y" results in "2015" being pasted into the edit window when I hit the "time stamp" button.

"Time format = %m/%Y" results in the string "06/2015"

"TIme format = %m/%d/%Y" results in the string "06/04"

"Time format = %m/%d %H" results in the string "06/04 "

David Wallis wrote:

I just updated to the latest official release (V3.1.0-2411f95) and have these problems:

  1. The Time Stamp button pastes the logbook name when "Time format" is not specified in elogd.cfg, and when it is set to "%m/%d/%Y %H:%M", it adds the string "5/28/."
  2. Drag and drop for attachments dosn't work on either Chrome 37.0.2062.94 (64-bit) or FIrefox 31.5.3 (both on Linux). D&D works on the midas.psi.ch demo page. On my logbooks, the "drop attachements here" area does not have a dashed line border
  3. Auto-saving does not seem to be working.

The "Syntax of elogd.cfg" help file doesn't seem to reflect some of these features... it took me a while to find the settings for LDAP authentication. Am I just missing some settings for these features?

My users are loving the new functionality added in 3.1!

 

 

 

  67967   Mon Jun 8 12:02:30 2015 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux3.1.0-2Re: ckeditor "Insert Timestamp" bug (was: Three problems with elogd 3.1.0-2)

Indeed the "str" variable at the gettimedate function had the wrong string size, so that all date strings got truncated at 8 characters. That's what you've seen. Also the ../../?cmd=gettimedate was wrong and it should be ./?cmd=gettimedate. I committed the fix to GIT so it will be contained in the next release ofe log.

David Wallis wrote:

Andreas,

I too was able to track the problem down to the "gettimedate" function in elogd.c. It looks like the code is using a variable named "str" for several different purposes. I haven't had a chance to do any testing, but my suspsicion is that the size of the dynamically allocated variable is ending up too small for the time stamp string, so it gets truncated.

 

Your point about the topic title is a good one - I'll split this into separate issues, thanks!

Andreas Luedeke wrote:
I can confirm that there is currently a problem with the ckeditor "Insert Timestamp" button.
It apparently calls javascript code in ckeditor/plugins/timestamp/plugin.js
to catch a string from the URL "../../?cmd=gettimedate"
(I think this is one too many "../", but anyway). if you try this for the Forum:
https://midas.psi.ch/elogs/Forum/?cmd=gettimedate
it returns the wrong string. It is "Forum" instead of the date.

PS to David: The subject "Three problems ..." is not giving any indication what it is about. I would find it better in this case to post three entries to the Forum, each with a striking title :-)

David Wallis wrote:

Additional info:

"Time format = %Y" results in "2015" being pasted into the edit window when I hit the "time stamp" button.

"Time format = %m/%Y" results in the string "06/2015"

"TIme format = %m/%d/%Y" results in the string "06/04"

"Time format = %m/%d %H" results in the string "06/04 "

David Wallis wrote:

I just updated to the latest official release (V3.1.0-2411f95) and have these problems:

  1. The Time Stamp button pastes the logbook name when "Time format" is not specified in elogd.cfg, and when it is set to "%m/%d/%Y %H:%M", it adds the string "5/28/."
  2. Drag and drop for attachments dosn't work on either Chrome 37.0.2062.94 (64-bit) or FIrefox 31.5.3 (both on Linux). D&D works on the midas.psi.ch demo page. On my logbooks, the "drop attachements here" area does not have a dashed line border
  3. Auto-saving does not seem to be working.

The "Syntax of elogd.cfg" help file doesn't seem to reflect some of these features... it took me a while to find the settings for LDAP authentication. Am I just missing some settings for these features?

My users are loving the new functionality added in 3.1!

 

 

 

 

ELOG V3.1.5-3fb85fa6