| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69357
|
Mon Apr 26 16:41:50 2021 |
 | Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Question | Windows | V3.1.3-fd7f1e2 | Re: Real-time mirroring? | Hello Frank,
It seems, you are using the mirror function of elog. It should resolve conflicts by itself acording to the documented rules. (https://elog.psi.ch/elog/config.html)
As I don't use this function, I can't say how good it works.
If you don't want to use this function, I would suggest using the "Execute new | edit | delete" feature to trigger a script after each change of elog entries.
This script could itself run "rsync" or your sync solution to make the sync and
should afterwards call "killall -HUP elogd" on the remote to let elog re-read the config (and this sould also update the indices)
(see Server Configuration https://elog.psi.ch/elog/adminguide.html)
If you have a sync-solution, which itself permanently observes folders for changes and syncs it by itself,
It should have the option to run a command after sucessful sync or you need an other method to call "killall -HUP elogd" after sync.
Personally I would recommend the mirror function as it has a internal conflict resolution.
I hope this helps.
Best wishes,
Sebastian
PS: I don't know anything about your setup, but maybe there is a solution, where you don't need the local servers.
As I think, the mirror function is mainly for backup reasons of a main server to a secondary one or similar.
| Frank Baptista wrote: |
|
Hello!
We have a number of local ELOG servers, all mirrored to a single "remote" ELOG server. We have users that create updates at the local server, and some at the remote server, which can run the risk of record conflicts. Right now, the local servers perform a "Mirror cron" every 5 minutes, but even that leaves the door open to potential conflicts.
I found an open-source JAVA-based app called DirSync Pro (https://www.dirsyncpro.org/) which is capable of performing real-time mirroring, and has conflict handling. I "took it for a spin", and it does do what it claims. However, because each ELOG server performs record "indexing", it doesn't recognize records that aren't part of the current list of records. Restarting the ELOG server obviously corrects that, but I was wondering if there is another way to get the server to recognize newer "remotely-generated" records without restarting the server.
As always, I'm appreciative for the outstanding working that has been done to make ELOG the great application that it is!
|
|
|
69358
|
Wed Apr 28 04:01:49 2021 |
| gary holman | holman@uw.edu | Bug report | Linux | ELOG V3.1.4-611 | Re: segfault in auth.c:366 | Dear Mr Ritt, Mr Schenk,
Thank you for the responses. This was indeed my issue and direction to fix the crash.
Thank you,
Gary
| Sebastian Schenk wrote: |
|
Hi Mr. Holman,
The problem you are facing is more likely the issue, that the LDAP method is only provided as-is from a different developer.
I had a similar issue with the LDAP of my university.
I can't remember the correct error messages, but it looks similar, which arises from the used c library for LDAP.
The LDAP connection response can have 2 different variable types and only one of them is implemented in the elog, the other one crashes the elog with segfault.
I could fix it with this patch:
https://bitbucket.org/merrx/elog/commits/5a75fdb3e0b723380dae73bb57653946ed72690c
Obviously you have to adapt "displayName" and "postOfficeBox" to represent the name and email attributes of your LDAP structure.
I didn't made a PR for this commit, because it would break the current LDAP implementation, i assume.
Best wishes,
Sebastian
| gary holman wrote: |
|
Elog version: ELOG V3.1.4-611489ba
I am running openldap on the localhost. For some reason now, elogd is segfaulting when (I believe) when a new user is being added to the password file. For example:
1. I delete user passord file defined in elogd.cfg
2. Bind/Authenticate to LDAP successfully
3. Segfaults in auth.c ldap_adduser_file()
Makefile:
...
ELOGDIR = /opt/elog
DESTDIR = $(ROOT)$(PREFIX)/bin
SDESTDIR = $(ROOT)$(PREFIX)/sbin
RCDIR = $(ROOT)/etc/rc.d/init.d
SRVDIR = $(ROOT)/usr/lib/systemd/system
# flag for SSL support
USE_SSL = 1
# flag for Kerberos support, please turn off if you don't need Kerberos
USE_KRB5 = 0
# flag for LDAP support, please turn off if you don't need LDAP
USE_LDAP = 1# flag for PAM support, please turn of if you don't need PAM
USE_PAM = 0
...
For authentication, I am using openldap in the localhost:
----
Authentication = LDAP
LDAP server = ldap://localhost:389
LDAP userbase = ou=people,dc=example,dc=org
LDAP login attribute = uid
LDAP register = 1
Password file = /opt/elog/users
gdb output
----------
(gdb) run -s /opt/elog -c /opt/elog/elogd.cfg -f /var/run/elog/elog.pid
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/ubuntu/UPGRADE-42221/work-src/elog/elogd -s /opt/elog -c /opt/elog/elogd.cfg -f /var/run/elog/elog.pid
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
elogd 3.1.4 built Apr 22 2021, 19:19:39 revision 611489ba
File "/var/run/elog/elog.pid" exists, overwriting it.
CKeditor detected
ImageMagick detected
Indexing logbooks ... done
Server listening on port 9011 ...
Breakpoint 1, ldap_adduser_file (lbs=0x555556811ad8, user=0x7ffffffd3bd0 "testuser", password=0x5555558ea110 <_value+6000> "testuser", error_str=0x7ffffffd53d0 "", error_size=<optimized out>) at src/auth.c:350
350 if (rc != LDAP_SUCCESS) {
(gdb) n
337 rc = ldap_search_ext_s(
(gdb) n
350 if (rc != LDAP_SUCCESS) {
(gdb) n
358 for(entry = ldap_first_entry(ldap_ld,result);
(gdb) n
371 if(strcmp(attribute,"mail")==0 || strcmp(attribute,"rfc822Mailbox")==0)
(gdb) n
361 for(attribute = ldap_first_attribute(ldap_ld,entry,&ber);
(gdb) n
365 if((values = ldap_get_values(ldap_ld,entry,attribute)) != NULL ) {
(gdb) n
366 for(i=0; values[i] != NULL; i++) {
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
ldap_adduser_file (lbs=0x555556811ad8, user=0x7ffffffd3bd0 "testuser", password=0x5555558ea110 <_value+6000> "testuser", error_str=<optimized out>, error_size=<optimized out>) at src/auth.c:366
366 for(i=0; values[i] != NULL; i++) {
(gdb) p attribute
$1 = 0x5555567f6a20 "uid"
(gdb) p values
$2 = (char **) 0x567f74f0
This user in LDAP:
-------------------------
# TESTUSER, people, example.org
dn: uid=TESTUSER,ou=people,dc=example,dc=org
uid: TESTUSER
cn: TESTUSER
givenName: TESTUSER
sn:: VEVTVFVTRVIg
mail: TESTUSER
uidNumber: 10000
gidNumber: 10000
homeDirectory: /dev/null
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
userPassword:: e1NTSEF9Y21ua1lsdFpMZ3ZrZlZ4OUp3MFN3cUY3NWIzdkFCSWY=
|
|
|
|
69360
|
Fri Apr 30 20:29:45 2021 |
| Frank Baptista | caffeinejazz@gmail.com | Question | Windows | V3.1.3-fd7f1e2 | Re: Real-time mirroring? | Hi Sebatian,
Thank you for taking the time to answer...very much appreciated!
Although I'm running Windows OS, I do understand your approach, and will work on an analogous solution.
Our setup is interesting -- we're running many temperature chambers, each one having a dedicated computer running a unique instance of ELOG, each of which is regularly updated to let users know what the progress is for the lengthy temperature testing. All of these individual logbooks regularly synchronize to a common 'mirror' ELOG server, which shows all the logbooks in one location. Users can view all the logbooks on one screen, by connecting to the mirror server. Since this can be done remotely, it also makes it convenient to add "updates" remotely to the mirror server, which eventually synchronizes with each individual computer at the temperature chambers. As you might imagine, if there is a user doing an update at the temperature chamber computer while another user enters an update remotely to the mirror server, there is a chance of having a record conflict.
I was trying to avoid conflicts by having real-time mirroring, where a change on either end is detected and immediately "synchronized", thereby reducing or eliminating conflicts.
In any case, if I do come up with a good solution for Windows, I'll be sure to share what I did.
Cheers,
Frank
| Sebastian Schenk wrote: |
|
Hello Frank,
It seems, you are using the mirror function of elog. It should resolve conflicts by itself acording to the documented rules. (https://elog.psi.ch/elog/config.html)
As I don't use this function, I can't say how good it works.
If you don't want to use this function, I would suggest using the "Execute new | edit | delete" feature to trigger a script after each change of elog entries.
This script could itself run "rsync" or your sync solution to make the sync and
should afterwards call "killall -HUP elogd" on the remote to let elog re-read the config (and this sould also update the indices)
(see Server Configuration https://elog.psi.ch/elog/adminguide.html)
If you have a sync-solution, which itself permanently observes folders for changes and syncs it by itself,
It should have the option to run a command after sucessful sync or you need an other method to call "killall -HUP elogd" after sync.
Personally I would recommend the mirror function as it has a internal conflict resolution.
I hope this helps.
Best wishes,
Sebastian
PS: I don't know anything about your setup, but maybe there is a solution, where you don't need the local servers.
As I think, the mirror function is mainly for backup reasons of a main server to a secondary one or similar.
| Frank Baptista wrote: |
|
Hello!
We have a number of local ELOG servers, all mirrored to a single "remote" ELOG server. We have users that create updates at the local server, and some at the remote server, which can run the risk of record conflicts. Right now, the local servers perform a "Mirror cron" every 5 minutes, but even that leaves the door open to potential conflicts.
I found an open-source JAVA-based app called DirSync Pro (https://www.dirsyncpro.org/) which is capable of performing real-time mirroring, and has conflict handling. I "took it for a spin", and it does do what it claims. However, because each ELOG server performs record "indexing", it doesn't recognize records that aren't part of the current list of records. Restarting the ELOG server obviously corrects that, but I was wondering if there is another way to get the server to recognize newer "remotely-generated" records without restarting the server.
As always, I'm appreciative for the outstanding working that has been done to make ELOG the great application that it is!
|
|
|
|
69361
|
Fri Apr 30 21:13:39 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Question | Windows | V3.1.3-fd7f1e2 | Re: Real-time mirroring? | Hi Frank,
I am not sure, if I understood your setup correctly. But in my eyes, you don't need the local elog servers. The only difference for the users at the chambers would be to directly use the 'mirror' remote elog url instead of the local elog url in their browsers. "which is regularly updated..." could mean, that you are using some kind of automatism to add entries to the local elogs, but you could also use these directly on the remote
If you have concers about users editing the wrong chamber elog, there is a usermanagement to only allow certain users to certain elogs (on the remote).
As for the part "having a record conflict". That would be totally fine and handled by the mirror function.
See the part "If new entries exist locally and remotely having the same entry ID"... in the documentation of the function.
As you state, that you are working on windows. There is no "killall" command to send the signal, as far as i know.
Then a script could kill the elog and start it again. But this should have the disadvantage of loosing the login session of the users.
Best wishes,
Sebastian
| Frank Baptista wrote: |
|
Hi Sebatian,
Thank you for taking the time to answer...very much appreciated!
Although I'm running Windows OS, I do understand your approach, and will work on an analogous solution.
Our setup is interesting -- we're running many temperature chambers, each one having a dedicated computer running a unique instance of ELOG, each of which is regularly updated to let users know what the progress is for the lengthy temperature testing. All of these individual logbooks regularly synchronize to a common 'mirror' ELOG server, which shows all the logbooks in one location. Users can view all the logbooks on one screen, by connecting to the mirror server. Since this can be done remotely, it also makes it convenient to add "updates" remotely to the mirror server, which eventually synchronizes with each individual computer at the temperature chambers. As you might imagine, if there is a user doing an update at the temperature chamber computer while another user enters an update remotely to the mirror server, there is a chance of having a record conflict.
I was trying to avoid conflicts by having real-time mirroring, where a change on either end is detected and immediately "synchronized", thereby reducing or eliminating conflicts.
In any case, if I do come up with a good solution for Windows, I'll be sure to share what I did.
Cheers,
Frank
| Sebastian Schenk wrote: |
|
Hello Frank,
It seems, you are using the mirror function of elog. It should resolve conflicts by itself acording to the documented rules. (https://elog.psi.ch/elog/config.html)
As I don't use this function, I can't say how good it works.
If you don't want to use this function, I would suggest using the "Execute new | edit | delete" feature to trigger a script after each change of elog entries.
This script could itself run "rsync" or your sync solution to make the sync and
should afterwards call "killall -HUP elogd" on the remote to let elog re-read the config (and this sould also update the indices)
(see Server Configuration https://elog.psi.ch/elog/adminguide.html)
If you have a sync-solution, which itself permanently observes folders for changes and syncs it by itself,
It should have the option to run a command after sucessful sync or you need an other method to call "killall -HUP elogd" after sync.
Personally I would recommend the mirror function as it has a internal conflict resolution.
I hope this helps.
Best wishes,
Sebastian
PS: I don't know anything about your setup, but maybe there is a solution, where you don't need the local servers.
As I think, the mirror function is mainly for backup reasons of a main server to a secondary one or similar.
| Frank Baptista wrote: |
|
Hello!
We have a number of local ELOG servers, all mirrored to a single "remote" ELOG server. We have users that create updates at the local server, and some at the remote server, which can run the risk of record conflicts. Right now, the local servers perform a "Mirror cron" every 5 minutes, but even that leaves the door open to potential conflicts.
I found an open-source JAVA-based app called DirSync Pro (https://www.dirsyncpro.org/) which is capable of performing real-time mirroring, and has conflict handling. I "took it for a spin", and it does do what it claims. However, because each ELOG server performs record "indexing", it doesn't recognize records that aren't part of the current list of records. Restarting the ELOG server obviously corrects that, but I was wondering if there is another way to get the server to recognize newer "remotely-generated" records without restarting the server.
As always, I'm appreciative for the outstanding working that has been done to make ELOG the great application that it is!
|
|
|
|
|
69362
|
Fri Apr 30 21:55:23 2021 |
| Frank Baptista | caffeinejazz@gmail.com | Question | Windows | V3.1.3-fd7f1e2 | Re: Real-time mirroring? | Hi Sebastian,
You're absolutely correct that the users at the chambers could directly use the remote ELOG server (without having a local server), and I did originally think about this. Unfortunately, there are times that our network "goes down" (for maintenance and other issues), and it was important to maintain the users' ability to perform regular 'local' updates at the temperature chambers, regardless of the network status.
In our situation, having a remote server also became particularly useful in the event that the 'local' computer at a specific temperature chamber "went down". The user can continue to update the respective logbook at the remoter server, knowing that it would eventually synchronize with the respective local server(s).
Thanks for the great feedback!
Frank
| Sebastian Schenk wrote: |
|
Hi Frank,
I am not sure, if I understood your setup correctly. But in my eyes, you don't need the local elog servers. The only difference for the users at the chambers would be to directly use the 'mirror' remote elog url instead of the local elog url in their browsers. "which is regularly updated..." could mean, that you are using some kind of automatism to add entries to the local elogs, but you could also use these directly on the remote
If you have concers about users editing the wrong chamber elog, there is a usermanagement to only allow certain users to certain elogs (on the remote).
As for the part "having a record conflict". That would be totally fine and handled by the mirror function.
See the part "If new entries exist locally and remotely having the same entry ID"... in the documentation of the function.
As you state, that you are working on windows. There is no "killall" command to send the signal, as far as i know.
Then a script could kill the elog and start it again. But this should have the disadvantage of loosing the login session of the users.
Best wishes,
Sebastian
| Frank Baptista wrote: |
|
Hi Sebatian,
Thank you for taking the time to answer...very much appreciated!
Although I'm running Windows OS, I do understand your approach, and will work on an analogous solution.
Our setup is interesting -- we're running many temperature chambers, each one having a dedicated computer running a unique instance of ELOG, each of which is regularly updated to let users know what the progress is for the lengthy temperature testing. All of these individual logbooks regularly synchronize to a common 'mirror' ELOG server, which shows all the logbooks in one location. Users can view all the logbooks on one screen, by connecting to the mirror server. Since this can be done remotely, it also makes it convenient to add "updates" remotely to the mirror server, which eventually synchronizes with each individual computer at the temperature chambers. As you might imagine, if there is a user doing an update at the temperature chamber computer while another user enters an update remotely to the mirror server, there is a chance of having a record conflict.
I was trying to avoid conflicts by having real-time mirroring, where a change on either end is detected and immediately "synchronized", thereby reducing or eliminating conflicts.
In any case, if I do come up with a good solution for Windows, I'll be sure to share what I did.
Cheers,
Frank
| Sebastian Schenk wrote: |
|
Hello Frank,
It seems, you are using the mirror function of elog. It should resolve conflicts by itself acording to the documented rules. (https://elog.psi.ch/elog/config.html)
As I don't use this function, I can't say how good it works.
If you don't want to use this function, I would suggest using the "Execute new | edit | delete" feature to trigger a script after each change of elog entries.
This script could itself run "rsync" or your sync solution to make the sync and
should afterwards call "killall -HUP elogd" on the remote to let elog re-read the config (and this sould also update the indices)
(see Server Configuration https://elog.psi.ch/elog/adminguide.html)
If you have a sync-solution, which itself permanently observes folders for changes and syncs it by itself,
It should have the option to run a command after sucessful sync or you need an other method to call "killall -HUP elogd" after sync.
Personally I would recommend the mirror function as it has a internal conflict resolution.
I hope this helps.
Best wishes,
Sebastian
PS: I don't know anything about your setup, but maybe there is a solution, where you don't need the local servers.
As I think, the mirror function is mainly for backup reasons of a main server to a secondary one or similar.
| Frank Baptista wrote: |
|
Hello!
We have a number of local ELOG servers, all mirrored to a single "remote" ELOG server. We have users that create updates at the local server, and some at the remote server, which can run the risk of record conflicts. Right now, the local servers perform a "Mirror cron" every 5 minutes, but even that leaves the door open to potential conflicts.
I found an open-source JAVA-based app called DirSync Pro (https://www.dirsyncpro.org/) which is capable of performing real-time mirroring, and has conflict handling. I "took it for a spin", and it does do what it claims. However, because each ELOG server performs record "indexing", it doesn't recognize records that aren't part of the current list of records. Restarting the ELOG server obviously corrects that, but I was wondering if there is another way to get the server to recognize newer "remotely-generated" records without restarting the server.
As always, I'm appreciative for the outstanding working that has been done to make ELOG the great application that it is!
|
|
|
|
|
|
69364
|
Tue May 4 15:24:56 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | Linux | 3.1.2 | Re: Bug: "Append on edit" triggers too often | I can confirm the issue also for "prepend on edit".
To be more precise, it gets executed everytime the condition state changes, if placed in the config without condition, or if placed in a condition, everytime the condition gets activated.
| Faith wrote: |
|
The command "Append on edit = " is getting executed everytime, when a dropdown menu is changed. This happens even at the first creation of an entry, so the append text stucks up multiple times in the text body.
|
|
|
69368
|
Thu Jun 3 16:02:02 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Question | Windows | 3.1.4-3 | Re: Problem with a self-compiled code. | Hello Maxim,
I just stumbled on a similar issue. Also with a self-compiled elogd on Ubuntu.
We also use a custom css and by clicking on the "New" or "Reply" or "Duplicate" the elog generates the entry editor.
On the first load of this page the link to the css file is sometimes corrupted by having some garbage characters in it.
<link rel="stylesheet" type="text/css" href="ƒŒüthemes/name.css">
I found the bug in the code and made a PR on the bitbucket. Here is the commit to fix it yourself.
https://bitbucket.org/merrx/elog/commits/cea193ded7161bb6d1f67725ca109d2d4341128a
Best wishes,
Sebastian
| Maxim wrote: |
|
Dear, sir! There is a problem with a configuration file.
The code was compiled by Cygwin (gcc-core, gcc-g++, make, gdb, libssl-dev). After a compilation a reference to our own css-file was written in configuration file and css-file was included in a folder “themes/default” of the project.
The problem is that in running elog-3.1.4-1 (and upper versions) css-file name in a code of a page has some random symbols before file-name, for example: <link rel="stylesheet" type="text/css" href="ø9öÿeLogOUK.css">. It was found that the problem is resolved if a string “Password file=passwd” is deleted, but in this case it is impossible to set passwords to the users.
Here is an example of configuration file which is taken from the forum and just one string (CSS=elogOUK.css) has added to the code
____________________________________________________________________
What can be done to resolve this problem?
|
|
|
69372
|
Mon Jun 14 18:51:59 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | All | V3.1.4 | Bug Report with CSS includes (was Re: How to format a column in list display?) | Hi Andreas,
the bug you have found was already reported in an earlier issue, together with the same solution you have found.
https://elog.psi.ch/elogs/Forum/69368
Best wishes,
Sebastian
| Andreas Luedeke wrote: |
| [...]
That works like a charm - until I log in to the logbook. Then the include of the CSS in the header is garbled with some "prefix" of random chars:
And a quick check in the source code shows some bad code:
L7615: function "show_html_header"
rsprintf("<link rel=\"stylesheet\" type=\"text/css\" href=\"%s%s\">\n", css_base, css);
Here css_base is a not initialized local variable of the function. In fact the above line is the only reference of that variable char css_base[1000].
The bug is still present in elog-3.1.4-611489b
|
|
|