> Is there a way to make this (password protecting logbooks while also using a proxy to Apache) work?

I use it with the current version and it works fine for me. What you might be missing is the

URL = http://example.com/elogbook/

statement in your elogd.cfg to make this work.

Best regards,
Stefan

I don't remember the details, but originally had the same trouble. I think a "/" at the end of a url got me somewhere. 
I have defined...

URL = http://somewhere.edu/elog

...in the config file, and my redirect looks like this:

Redirect /elog http://somewhere.edu/elog/
ProxyPass /elog/ http://somewhere.edu:8080/
ProxyPassReverse /elog/ http://somewhere.edu:8080/

> I don't remember the details, but originally had the same trouble. I think a "/" at the end of a url got me somewhere. 
> I have defined...
> 
> URL = http://somewhere.edu/elog
> 
> ...in the config file, and my redirect looks like this:
> 
> Redirect /elog http://somewhere.edu/elog/
> ProxyPass /elog/ http://somewhere.edu:8080/
> ProxyPassReverse /elog/ http://somewhere.edu:8080/


Yes, that did it:  Adding the URL to the config file was the key.

Thanks!

Is there a limit on the number of conditions that can be simultaneously active in a log?  When I activate more than 10 conditions I start to see side effects with other conditions being deactivated.  I think this is due to the hard-coded array size of 10 for clist in the match_param function in elogd.c.  If so, could this limit be increased?  

Are there other limits on the number of conditions, or the length of condition names?  If I've understood the code right, the _condition string holds a comma-separated list of the active conditions, so the 256 byte length of this will also put some limit on the number of conditions that can be active.

Ups. I never imagined that someone would use more than 10 conditions. I'm not 100% sure if the problem is the clist array, but can you try to set it to 20 and see if it gets better? You can also send me your config file and I can try it myself. 

I'll try increasing the list size(s), and will also prepare a simplified config file for you to look at.  Maybe there is a another way to implement what I am trying to achieve?  

In general terms I am trying to give an e-log a "memory" of what has been recorded previously in order to constrain what is permissible to record next.  I do this by starting a log with an initial entry, then alter the config so that users can add records only by duplicating the last record.  The log records the current state of some variables, and allows users to record changes to the state of any of these variables. Conditions are used to constrain the permitted state changes, depending on the current state; conditions are also used, with subst options, to update the current state variables when changes are made.

Specifically, we have "Mate-Demate" logs for connectors to record when connectors are mated and demated.  Previously we just had an attribute for each connector in an assembly with options "Mate", "Demate" and "-" to indicate that either a mate or demate was carried out or that the connector was not touched on this occasion (although others were).  My cunning plan was to ensure that a "Demate" (or no-op) was possible only if the connector is currently mated, and conversely that a "Mate" (or no-op) was possible only if the connector is currently demated.  For each connector (e.g. ConnectorA), there are now two attributes

• "ConnectorA state", to record the current state, and
• "ConnectorA" to record any change.

A new record can be created only by duplicating the last record, thus copying the current state of the connectors, and for each connector the relevant config file entries are like this:

Show Attributes = ConnectorA
Show Attributes Edit = ConnectorA state, ConnectorA
Locked Attributes = ConnectorA state
Preset on duplicate ConnectorA = -
Options ConnectorA state = Mate{1}, Demate{2}
{2} Options ConnectorA = -, Mate{3}
{1} Options ConnectorA = -, Demate{3}
{3} Subst ConnectorA state = $ConnectorA

Hello, I have

authentication = kerberos

kerberos Realm = xxx

I ran tcpdump and know elogd server did attempt to contact kerberos server. I could run kinit username@realm_name, and klist shows my ticket fine. 

I receive "kerberos error 256: Decrypt integrity check failed. Please check your kerberos configuration" when I entered my password wrong purposely on login page.

I receive "Invalid user name or password!' when I entered my correct password. 

Please advise. 

I forgot to mention, I also have Password file line in elogd.cfg file. Because without password file line, I wouldn't get login screen. I know my test account is not in the main.pwd file. I believe elogd does go to kerberos server to compare password. I just don't get why I get invalid username and password when I entered correct password, while kerberos error (expected) when I enter wrong password.  

Authentication = Kerberos

Kerberos Realm = xxx

Password file = main.pwd