The entry ID #0 was a bug in logging routine only, so in the elog logbook the ID is certainly not zero. But the logging bug has been fixed now, so please update your version of elog.
Then I tried to reproduce your problem. I set up two servers, the master listening at port 8080 and the slave listening at port 8081. I created two entries at the master, did manual synchronization, then created one entry on the slave, and did another synchronization on the master. I got both sides correctly transferred, no problem with ID zero. See attached screenshot. I used following elogd.cff on the master side:
[global]
port = 8080
password file = passwd
Mirror server = http://localhost:8081
Mirror simulate =1
[demo]
Theme = default
Comment = General Linux Tips & Tricks
Attributes = Author, Type, Category, Subject
Options Type = Routine, Software Installation, Problem Fixed, Configuration, Other
Options Category = General, Hardware, Software, Network, Other
Extendable Options = Category
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type
| Sergei Gavrilov wrote: |
|
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
|
|