Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 663 of 808  Not logged in ELOG logo
ID Date Icon Author Author Emaildown Category OS ELOG Version Subject
  69757   Sat Mar 9 17:17:02 2024 Idea Andreas Warburtonandreas.warburton@mcgill.caRequestMac OSX3.1.5Suggestion to update Mac OS X instructions in ELOG Administrator's Guide

The section of the ELOG Administrator's Guide https://elog.psi.ch/elog/adminguide.html describing how to build and install ELOG on a Mac OS X system has worked well for me for several years, even though there have been warnings that the "load" and "unload" subcommands of the "launchctl" command have been deprecated for some time.  After trying my luck again on a new Mac with the latest operating system, I encountered errors of the type "Load failed: 5: Input/output error" when attempting to follow these instructions.

After a bit of searching around, I used information at the page https://www.alansiu.net/2023/11/15/launchctl-new-subcommand-basics-for-macos/ to deploy the more current subcommands as follows:

sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist 

sudo launchctl disable system/ch.psi.elogd

Once the above can be verified, perhaps the instructions in the Administrator's Guide can be updated accordingly.

 

  69758   Sun Mar 10 04:25:43 2024 Reply Andreas Warburtonandreas.warburton@mcgill.caRequestMac OSX3.1.5Re: Suggestion to update Mac OS X instructions in ELOG Administrator's Guide

Here's a more complete/correct set of the updated commands:

sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist 

sudo launchctl bootout system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl disable system/ch.psi.elogd

Cheers,
Andreas

Andreas Warburton wrote:

The section of the ELOG Administrator's Guide https://elog.psi.ch/elog/adminguide.html describing how to build and install ELOG on a Mac OS X system has worked well for me for several years, even though there have been warnings that the "load" and "unload" subcommands of the "launchctl" command have been deprecated for some time.  After trying my luck again on a new Mac with the latest operating system, I encountered errors of the type "Load failed: 5: Input/output error" when attempting to follow these instructions.

After a bit of searching around, I used information at the page https://www.alansiu.net/2023/11/15/launchctl-new-subcommand-basics-for-macos/ to deploy the more current subcommands as follows:

sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist 

sudo launchctl disable system/ch.psi.elogd

Once the above can be verified, perhaps the instructions in the Administrator's Guide can be updated accordingly.

 

 

  69785   Tue Apr 16 13:20:01 2024 Reply Andreas Warburtonandreas.warburton@mcgill.caRequestMac OSX3.1.5Re: Suggestion to update Mac OS X instructions in ELOG Administrator's Guide

Hi Stefan, Thanks a lot for implementing the updated commands. I noted that there are a few typos that could cause people confusion if not fixed:

In one case, "launchctl" is misspelled.

Confusingly, I think the two lines containing the 'enable' and 'disable' commands use the contiguous text string "system/ch.psi.elogd" (no space), whereas the two lines containing the 'bootstrap' and 'bootout' commands use the phrase "system /Library/LaunchDaemons/ch.psi.elogd.plist" (note space after 'system').

Many thanks, Andreas W.

Stefan Ritt wrote:

 

Thanks for the info, I updated the adminguide.

Stefan

Andreas Warburton wrote:

Here's a more complete/correct set of the updated commands:

sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist 

sudo launchctl bootout system /Library/LaunchDaemons/ch.psi.elogd.plist
sudo launchctl disable system/ch.psi.elogd

Cheers,
Andreas

Andreas Warburton wrote:

The section of the ELOG Administrator's Guide https://elog.psi.ch/elog/adminguide.html describing how to build and install ELOG on a Mac OS X system has worked well for me for several years, even though there have been warnings that the "load" and "unload" subcommands of the "launchctl" command have been deprecated for some time.  After trying my luck again on a new Mac with the latest operating system, I encountered errors of the type "Load failed: 5: Input/output error" when attempting to follow these instructions.

After a bit of searching around, I used information at the page https://www.alansiu.net/2023/11/15/launchctl-new-subcommand-basics-for-macos/ to deploy the more current subcommands as follows:

sudo launchctl enable system/ch.psi.elogd
sudo launchctl bootstrap system /Library/LaunchDaemons/ch.psi.elogd.plist 

sudo launchctl disable system/ch.psi.elogd

Once the above can be verified, perhaps the instructions in the Administrator's Guide can be updated accordingly.

 

 

 

 

  2091   Fri Nov 24 23:08:33 2006 Question Andreas Warburtonandreas.warburton@gmail.comQuestionLinux | Windows2.6.2-1755Resubmit-as-new-entry behaviour when synchronizing/mirroring
Hello,

I am running two ELOG installations: one on my Windows laptop; the other on a Debian linux web server. I have mirroring set up between the two installations. This has worked well for over a year. I am hoping that someone can help me regarding the following odd behaviour.

1. I edit (create) an entry on my Windows laptop. This entry gets mirrored or synchronized to the Linux machine.

2. I can view the entry fine both on the Windows side and on the Linux side.

3. I then edit the entry on the Linux side. After saving, the revised entry is visible on the Linux side.

4. I then have the same entry number available on both installations, but the two have different content due to my edit.

5. If I then synchronize, the original (unedited) entry is preserved along with the new entry, so both the Windows and Linux installations now have TWO entries each, representing the unedited and edited versions. The time stamps are identical, but the edited version is given a new ID number.

As a check, I explicitly added the line "Resubmit default = 0", which I know refers to editing and not synchronization, to my config file. The weird thing is that the synchronize/mirror operation seems to be acting with a "Resubmit default = 2" kind of behaviour.

Has anyone observed this happening?

Thanks for any comments or insights.

Cheers,
Andreas
  66856   Thu Jul 22 15:51:50 2010 Reply Andreas Luedekeandreas.luedeke@psi.chQuestionLinux2.7.8Re: drop in replacement for FCKeditor?

Bill Pier wrote:

Stefan Ritt wrote:

Bill Pier wrote:

Is it possible to use a drop-in replacement for the FCKeditor? 

What is a drop-in replacement? 

 A configuration option to specify a different/alternate javascript based editor.

 There is an firefox addon "It's all text" that allows you to call your own editor for all textarea fields in the browser.

If you then choose "plain" or "ELCode" encoding in ELOG for a new entry or to modifiy an existing entry, you can use your favourite editor to edit the entry by an new "EDIT" button associated with the textarea input field. It works simply by temporary files.

Not really a "drop-in" replacement, but similar.

 

  66888   Fri Sep 3 14:14:07 2010 Reply Andreas Luedekeandreas.luedeke@psi.chCommentAll2.8.-2312Re: How to make Subst run?

Robert Heine wrote:
Dear colleagues,
I tried to get an Subst <attrib> = $shell(<command>) to work and put this into a Preset text line, like e.g.:
Attributes = subject, ... 
Options <name> = test{1}, ...  
Subst myvar = $shell(dir) 
{1} Preset subject = Test 
{1} Preset text = $myvar 

Which results in an ELOG-entry having printed "$myvar" in its body instead of the expected substitution. Changing the Subst command to: "Subst myvar = $host" or even to "Subst myvar = Test" also resulted in printing just the string "$myvar" into the submitted Elog-entry. - What am I doing wrong?

What you want to do is done simply by:
{1} Preset text = $shell(dir)
You expect "Subst" to create new variables, but it cannot do this.
"Subst" can overwrite the value of an existing field in an already submitted entry, while
"Preset" allows to prefill an existing entry field and the user may overwrites it before submitting (if it is not "Locked".)
In both cases you can either call a shellscript to create the desired text, or you can use
one of the predefined variables defined in the help pages "ELOG - Syntax of elogd.cfg" for "Subst".

Cheers Andreas
  66889   Fri Sep 3 14:25:37 2010 Reply Andreas Luedekeandreas.luedeke@psi.chBug reportAll2.7.8Re: Elog v2.7.8 does not show substituted attributes while editing or replying

Dennis Seitz wrote:

 Since we updated to 2.7.8 we've found a problem.

Previously, when we used 

Subst on reply subject = Re: $subject

The new "Re: " text would appear in the "subject" field while the user was editing their reply, and they could edit or delete it.
Since 2.7.8, however, it does not appear while editing, but shows up only after the user submits their entry. We would prefer that this appears while the user is editing, because in some cases we want the users to have the option to modify this text. Was this intentional? Is there a way to restore the previous functionality?[...]

Sorry, that appears to be an undocumented bug fix :-)

The desired behaviour should be created by

Preset on reply subject = Re: $subject

The command "Subst" is supposed to overwrite the field after it is submitted.

From the documentation you will even find a nicer possibility:

Preset on first reply Subject = Re: $Subject

The prevent replies to build a long chain of "Re: Re: Re: ...."

Cheers Andreas

  66890   Fri Sep 3 14:43:16 2010 Reply Andreas Luedekeandreas.luedeke@psi.chCommentLinux | Mac OSX2.8.0Re: Synchronizing mirror causes corruption of logbook entries with multiple logbooks defined?

Glenn Horton-Smith wrote:

We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it? [...]

I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized.  This suggests it isn't specific to Linux architecture, 64-bit or otherwise. 

We plan to use ELOG with mirror servers in a larger scale here, so I'm interested to know more about your problem.

Could you boil down your configuration to a minimum that still allows a reproduction of the problem and post those configurations as attachments?

Then I would try to reproduce it here. Best case I'll find a bug fix, worst case I'll reconsider the use of mirror servers ;-)

ELOG V3.1.5-3fb85fa6