We're running elogd behind an apache proxy server, with Authentication = Webserver. We have top groups configured, but a single shared password file.

If a user is looking at a particular logbook and goes to the Config link, they are presented with a list of checkboxes for email subscription to logbooks in that top group.  Clicking "Save" will remove all email subscriptions from all other top groups.

Is there a workaround to this issue?

EDIT: Manually adding an entry for different logbooks in the password file gets clobbered the next time the user logs in.

Top groups should use separate password files, otherwise things can mess up.

Stefan

Dear all.

I am running elog 

elogd 3.1.4 , revision ead6bbc6

on Macosx Mojave

Darwin arpg-serv.ing2.uniroma1.it 18.5.0 Darwin Kernel Version 18.5.0: Mon Mar 11 20:40:32 PDT 2019; root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64

I managed to compile and run without problems the elog source code.

I can run it and have it properly displayed at boot time. After the server boot, for few hours, I have the elog ready at http://arpg-serv.ing2.uniroma1.it/elog  but then, after few hours.. I get that the service stops and the elog is no longer accessible.

So far I was able to track down the problems only to the 

/var/log/system.log

file in which I find a not useful error message:

Eg: Apr 23 14:00:46 arpg-serv com.apple.xpc.launchd[1] (ch.psi.elogd[85248]): Service exited with abnormal code: 1

I do not know I can I debug this nor why the code runs for few hours without problems... I just re-downloaded the code from scratch today, unloaded and then re-loaded the daemon but still it fails with the same error.

I am sure that I can get it running again for few hours by re-booting. But I want to understand the source of the problem.. Anyone can be of help on this long standing issue?

Thanks

This kind of behavior we typically see if some elog entry is corrupt. After a few hours you might access this corrupt entry by accident, and then the server stops. If you see however this behavior on a fresh logbook with no corrupt entries, then the problem must lie somewhere else.

Do you see the same problem running under linux?

Do you see the same problem if you run elogd interactively (not through launchd)?

If you run elogd inside a debugger (like gdb or lldb), what does the debugger tell you when it crashes and you show the stack frames? Make sure to compile with -O0 and -g flags to include debug information in the executable.

Stefan 

Since there's no answer to that.
I am the only one with the problem? Did I just configure something wrong?
Thanks Heinz

There are two ways:

1) Use different password files for different logbooks. Each password file contains only those users which have access to that logbook.

2) Use "Login user = <usr list>" to restrict access to certain users in that list.

Stefan

Thanks for the answer. The real problem is that you can overwrite existing entries even if you have set an entry to "read only", i.e. you have forbidden further editing.

Heinz

There is no "read only" flag. Please describe what you exactly did. Probably you want "Restrict edit time" for that.

Stefan