Hello, dear ELOG's gurus.
Please help me to understand a problem with mirroring function.
It appears in ELOG V3.1.4-a04faf9f - the last official Windows release, as well as previous 3.1.3 Windows release, which I have checked for comparison.

When I'm using a manual configuration with "mirror server, cron, user" options for one (master) of two servers, it operates well, except the situation, when a new entry is submitted at the second (slave) server.
For example, for a new entry with a real ID#2 at Slave its logfile gives "NEW entry #0", so logfile of the master server gives "MIRROR: Error receiving message: Received wrong entry id "0"".
After that Master deletes this entry at Slave "MIRROR delete remote entry #2".

In case of mirror functions in both .cfg files (Master to Slave, Slave to Master) both servers hung on after the first mirror process.

Now let's imagine, what I want to do. 
Master, as a main-operation global log, is off-operation, Slave automatically becomes a reserv-operation local log with full information from Master due to previous periodic mirroring.
Users work with Slave, submit new entries - all with #0 ID.
After repairing Master starts active mirroring and just deletes all new entries from Slave.

It seems, that the problem is not with mirroring, but with a new entry ID, as was mentioned in https://elog.psi.ch/elogs/Forum/68850
Were these ID#0/mirror problems resolved somehow or may be it is not a problem, but simply my errors in ELOG configuration?
Is there a chance to get an up-to-date Windows-release with working both-sides mirror function and all other addings after V3.1.4-a04faf9f ?

Best regards,
Sergei

Dear colleagues,
Can someone compile an up-to-date windows-version or write a manual how to do it in Windows without compiling errors?
Thank you.

For demonstration, I created https://elog.psi.ch/elogs/Linux+Demo/8

The Find search for category aaa(bb) does not give results.
A quick filter corrects the value to aaa\(bb) and delivers results.

I made a simple fix and submitted it as PR to the bitbucket repository.

Hello,
I have experienced some inconveniences with the restrict edit time option.

First, it is not possible for admin users to edit an entry after the edit time.
The restrict edit option allows admin users to edit posts from other users,
so I think admins should also be allowed to edit posts after edit time.
As they can edit the config and temporarily disable the restrict edit time option, which is an issue.

Secondly, if a user made a draft and did not submitted it before the edit time runs out,
the draft got stuck as it cannot be edited (and submitted) any more.

Best wishes,
Sebastian

Hi,
that Sebastian would be me. I replied to the first entry, as it was a draft (site reloaded incorretly...) and now I can't see the post anywhere. But this is off topic.

We have elog running on port 8000 and forward the traffic via Apache to it. Apache handles the SSL and other sites on the server.
All you need is a apache site configuration like the following. The parameter you want is CustomLog. (Have a look in the internet for options.)
I have also used nginx as webserver and know it can also handle this proxy setup.
If you use the following config, the elog config needs the URL attribute in the (global) config.

Best wishes,
Sebastian

<VirtualHost *:443> # change 443 to  80, if you don't use SSL
        ServerName your.server.name

        # delete the next 3 lines, if you don't use SSL
        SSLEngine on
        SSLCertificateFile /path/to/your/ssl.crt
        SSLCertificateKeyFile /path/to/your/ssl.key

        ProxyPreserveHost On
        ProxyPass / http://127.0.0.1:8000/
        ProxyPassReverse / http://127.0.0.1:8000/

        # Possible values include: debug, info, notice, warn, error, crit, alert, emerg.
        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        ErrorLog ${APACHE_LOG_DIR}/error.log

</VirtualHost>

Dear John,

I am a user of the elog system and no developer, so no complete answer guaranteed.

The quote of the manual describes the case, if e.g. an hardware component discovers a failure and the connected PC makes an automatic (new) entry to the elog. Probably modifying an existing one.

I have small concerns on your solution. The description of your alarm system sounds the other ways around, as you are doing something, depending on the elog entries. Based on your statement on JS and dedicated start page, you want to do it on client-side and not on the server. Where I can see the issue, if there is not client, then there is no alarm. As you want to change the date of the entries, I believe, you want to reuse the same entries multiple (infinite?) times instead of creating new ones. The later would be the style of an logging software like elog.

As far as I know, the Date attribute is special and cannot be changed by submitting something to the elog server. as this would make "Restrict edit time" useless. You can try it with this in your config:
Subst on edit Date = $date
Making an entry and edit it afterwards. The entry time stays the same.
If you really want to use this attribute, you have to do some scripting to the actual saved .log files, but this is not intended as I believe.

What you can do, is using an alternative attribute like "MDate" with the config:
Subst MDate = $date
Subst on edit MDate = $date
This will update every time you edit the entry.
Then you probably want to add something like this to your config
List display = ID, MDate, Author, ...

Or "Update" using the duplicate function on the old entry, where you want to change the date, creating a new one with the same content.
Or "Update" using the reply function to create a new entry, referring to the old one.

I hope, I could help.
Best wishes,
Sebastian

As far as I know, it is not possible, if you make a "new" entry.
You could configure the elog, to always PRESET an atribute, but then it is always the same, not the last.

I think the "duplicate" entry function could provide you partly with the functionality you want, as it copies all old values into a new entry.

Regards,
Sebastian

Hello all,

I have the issue, that we can't list entries older than 1 year, if "Last default = 31" (or any other number, but they are restricted to 1, 3, 7, 31, 92, 182, 364) is active.
The quick filter displays the option for "-- all entries --" but selecting this only reloads the default time frame (31 days).

A workaroud is to select a different time e.g. 1 day and then modifying the URL to ?last=1000 or so, gives acces to the old entries.
But this is not the intended way to do it.

The Find results are also affected by this. e.g. selecting 1.1.2020 to 1.6.2020 with "Last default = 31" yields 0 results.
The "Show last default" atrtribute for 1, 3, 7, 31, 92, 182, 364 work fine and overwrite the "last default" time in the quick filter.

In the Find page, there will be a "All entries" option at the top of the date selection box, if "Show last default" equals to 1, 3, 7, 31, 92, 182 or 364
(2, Bug: it is empty for "Show last default = 0" and not All entries")

Selecting "All entries" or the empty first value in the Find "show last:" date , will give a Find result with the "Last default" time constraint.

Thus it is not possible to get any entry older then the longst period possible (364 days), if you don't know about the workaround.

Best wishes,
Sebastian

PS: I use a self-compiled version of elog up to the 395e101 commit in the bitbucket repository with pull request #7 (which hasn't been merged for over 1,5 years) and a simple patch for our local LDAP.