Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 22 of 238  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
icon5.gif   Real-time mirroring?, posted by Frank Baptista on Mon Apr 26 15:40:36 2021 

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!

 

 

    icon2.gif   Re: Real-time mirroring?, posted by Sebastian Schenk on Mon Apr 26 16:41:50 2021 

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!

 

 

 

       icon2.gif   Re: Real-time mirroring?, posted by Frank Baptista on Fri Apr 30 20:29:45 2021 

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!

 

 

 

 

          icon2.gif   Re: Real-time mirroring?, posted by Sebastian Schenk on Fri Apr 30 21:13:39 2021 

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!

 

 

 

 

 

             icon2.gif   Re: Real-time mirroring?, posted by Frank Baptista on Fri Apr 30 21:55:23 2021 

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!

 

 

 

 

 

 

icon1.gif   [Bug?] Admin restrict edit time, posted by Faith on Fri Apr 30 07:27:31 2021 

I would like to know, if the command "Admin restrict edit time = " does really work as intended.

In my case I have the following global configuration:

Admin user = <me>
Restrict edit = 1
Restrict edit time = 1
Admin restrict edit time = 10000

And every time, when I want to edit an entry (as admin), that is older than 1 hour, i get the following error message:

"Entry can only be edited 1 hours after creation"

 

icon1.gif   segfault in auth.c:366, posted by gary holman on Fri Apr 23 04:59:58 2021 

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=
 

 

 

 

    icon2.gif   Re: segfault in auth.c:366, posted by Sebastian Schenk on Fri Apr 23 15:46:39 2021 

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=
 

 

 

 

 

       icon2.gif   Re: segfault in auth.c:366, posted by Stefan Ritt on Fri Apr 23 16:21:05 2021 

Well, if you find a solution with works for everybody, I'm happy to commit it to the main repository. But unfortunately I cannot test it because I don't have LDAP here, so I'm flying blind.

Stefan

          icon2.gif   Re: segfault in auth.c:366, posted by Laurent Jean-Rigaud on Sun Apr 25 15:17:27 2021 

Hi,

Maybe it could be useful to add new parameters in elogd.cfg to define the attribute name to use to retrieve the given name, login name and email from LDAP server.

By example :

LDAP email attribute = mail
LDAP surname attribute = id
LDAP givename attribute = gn

 

So users can define them according to their exotic LDAP schema ;-)

 

Laurent

       icon2.gif   Re: segfault in auth.c:366, posted by gary holman on Wed Apr 28 04:01:49 2021 

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=
 

 

 

 

 

 

icon1.gif   How to make personal ELOG to public, posted by Hien Doan on Tue Mar 30 12:56:48 2021 
Dear experts,

I am trying to use ELOG for my projects which we want to record every daily activities.
I have successful installed the ELOG to the computer (Windows10 -64 bit).
However, I don't know how to make it public or online, that people can access it from their computers.
I am a very newer to the ELOG.
Could you help me on it, please?

Best regards,
Hien.
    icon2.gif   Re: How to make personal ELOG to public, posted by Sebastian Schenk on Tue Mar 30 18:08:37 2021 
Dear Hien,

your problem is more general the question, how to get the elog to the network.

You have to open the port on your system to the network.
I would suggest to google "open port for webserver on windows".
As right now I would just do the same and follow a tutorial.
A remark here: elog by default runs at port 8080, if you haven't changed this, this is the port you should be opening to the network.

If the elog can be accessed in the local network and you want to open it to the whole internet,
then you need to configure your router/gateway/(company) firewall to allow forwarding of the port of the elog.
I can't give you tips here, at this is very user specific.

An other remark, i would suggest (for a productive environment) to use user authentication in the elog to restrict access.
If you do this, then you also should use https reverse proxy or have a read in the SSL section of the elog documentation.
As http only would transmit the credentials in plain text.

I hope, I could give you a route, what your next steps could be.
Best wishes,
Sebastian


> Dear experts,
>
> I am trying to use ELOG for my projects which we want to record every daily activities.
> I have successful installed the ELOG to the computer (Windows10 -64 bit).
> However, I don't know how to make it public or online, that people can access it from their computers.
> I am a very newer to the ELOG.
> Could you help me on it, please?
>
> Best regards,
> Hien.
       icon2.gif   Re: How to make personal ELOG to public, posted by Hien Doan on Thu Apr 8 06:25:58 2021 
Dear Sebastian,

Thank you very much for the instruction.
I am able to make the elog to the network.

Best regards,
Hien.


Sebastian Schenk wrote:
Dear Hien,

your problem is more general the question, how to get the elog to the network.

You have to open the port on your system to the network.
I would suggest to google "open port for webserver on windows".
As right now I would just do the same and follow a tutorial.
A remark here: elog by default runs at port 8080, if you haven't changed this, this is the port you should be opening to the network.

If the elog can be accessed in the local network and you want to open it to the whole internet,
then you need to configure your router/gateway/(company) firewall to allow forwarding of the port of the elog.
I can't give you tips here, at this is very user specific.

An other remark, i would suggest (for a productive environment) to use user authentication in the elog to restrict access.
If you do this, then you also should use https reverse proxy or have a read in the SSL section of the elog documentation.
As http only would transmit the credentials in plain text.

I hope, I could give you a route, what your next steps could be.
Best wishes,
Sebastian


> Dear experts,
>
> I am trying to use ELOG for my projects which we want to record every daily activities.
> I have successful installed the ELOG to the computer (Windows10 -64 bit).
> However, I don't know how to make it public or online, that people can access it from their computers.
> I am a very newer to the ELOG.
> Could you help me on it, please?
>
> Best regards,
> Hien.
    icon2.gif   Re: How to make personal ELOG to public, posted by Frank Baptista on Mon Apr 26 16:14:49 2021 

Hello Hien,

If you are sharing ELOG with users on the same network, here's something you can try.  First, on the machine running ELOG, you need to find the "Computer name".   To do this, locate "This PC", and right click it to get to "Properties" in the drop-down menu.  You need to jot down the "Computer name".  Now, users on the same network should be able to view ELOG by entering the following:

http://computer-name:(port number)

If you are using port 80 (instead of the default 8080) for ELOG, then there is no need to enter the port number.

Give that a try -- that is working well for us.

Cheers!
Frank

 

> Dear experts, > > I am trying to use ELOG for my projects which we want to record every daily activities. > I have successful installed the ELOG to the computer (Windows10 -64 bit). > However, I don't know how to make it public or online, that people can access it from their computers. > I am a very newer to the ELOG. > Could you help me on it, please? > > Best regards, > Hien.

Entry   , posted by Vinzenz Bildstein on Fri Apr 23 18:53:16 2021 
 
icon4.gif   auto pre-fill fields issue, posted by Gys Wuyts on Fri Apr 9 16:48:54 2021 

Hello,

what are the pre-requisites to automatically fill the Author and Author Email fields. The documented method:

Subst Author = $long_name from $remote_host

Subst Email = $user_email

in the elogd.cfg file does not seem to work.

(I see it works here on this platform)

Tnks

 

G

    icon2.gif   Re: auto pre-fill fields issue, posted by Stefan Ritt on Fri Apr 9 17:54:42 2021 

You need user-level access control, using 

Password file = ...

Stefan

Gys Wuyts wrote:

Hello,

what are the pre-requisites to automatically fill the Author and Author Email fields. The documented method:

Subst Author = $long_name from $remote_host

Subst Email = $user_email

in the elogd.cfg file does not seem to work.

(I see it works here on this platform)

Tnks

 

G

 

       icon2.gif   Re: auto pre-fill fields issue, posted by Gys Wuyts on Sat Apr 10 20:58:35 2021 

Thank you but that is already  in place. I have the same issue on both Windows 10 and Windows Server 2016 and 2019.

tnks

g

Stefan Ritt wrote:

You need user-level access control, using 

Password file = ...

Stefan

Gys Wuyts wrote:

Hello,

what are the pre-requisites to automatically fill the Author and Author Email fields. The documented method:

Subst Author = $long_name from $remote_host

Subst Email = $user_email

in the elogd.cfg file does not seem to work.

(I see it works here on this platform)

Tnks

 

G

 

 

          icon2.gif   Re: auto pre-fill fields issue, posted by Andreas Luedeke on Sun Apr 11 18:16:02 2021 

If you would post a minimal config file where the problem occurs, then we could look what the problem is.

Gys Wuyts wrote:

Thank you but that is already  in place. I have the same issue on both Windows 10 and Windows Server 2016 and 2019.

tnks

g

Stefan Ritt wrote:

You need user-level access control, using 

Password file = ...

Stefan

Gys Wuyts wrote:

Hello,

what are the pre-requisites to automatically fill the Author and Author Email fields. The documented method:

Subst Author = $long_name from $remote_host

Subst Email = $user_email

in the elogd.cfg file does not seem to work.

(I see it works here on this platform)

Tnks

 

G

 

 

 

             icon2.gif   Re: auto pre-fill fields issue, posted by Gys Wuyts on Mon Apr 12 13:32:53 2021 

[global]

port = 8080

ssl = 0

Password file = passwords.txt

Admin user = user1

SMTP host = smtp. mail.com

SMTP port = 25

SMTP username = user1@mail.com

SMTP Password = GIwbx7UbmkWs5J0P8lVztX7Anje0/21BU/Tmk0aPm.

Logfile = ELog_log.txt

Logging level = 3

 

 

[Server]

Logbook dir = Server

Theme = default

Comment = Server Change Log

Attributes = Author, Email, Type, Category, Subject

Subst Author = $long_name from $remote_host

Subst Email = $user_email

Options Type = SRV 1, SRV 2, SRV Sup, BMS content, BMS setpoints, BMS new

Options Category = Config, User, Access, Connection, Change, New, Delete

Extendable Options =

Required Attributes = Author, Type

Page Title = ELOG - $subject

Reverse sort = 1

Quick filter = Date, Type

Andreas Luedeke wrote:

If you would post a minimal config file where the problem occurs, then we could look what the problem is.

Gys Wuyts wrote:

Thank you but that is already  in place. I have the same issue on both Windows 10 and Windows Server 2016 and 2019.

tnks

g

Stefan Ritt wrote:

You need user-level access control, using 

Password file = ...

Stefan

Gys Wuyts wrote:

Hello,

what are the pre-requisites to automatically fill the Author and Author Email fields. The documented method:

Subst Author = $long_name from $remote_host

Subst Email = $user_email

in the elogd.cfg file does not seem to work.

(I see it works here on this platform)

Tnks

 

G

 

 

 

 

                icon2.gif   Re: auto pre-fill fields issue, posted by Stefan Ritt on Mon Apr 12 13:57:18 2021 

"Subst xxx" replaces after you submit an entry, while "Preset xxx" replaces before you create an entry. I believe you want the second one.

Stefan

Gys Wuyts wrote:

[global]

port = 8080

ssl = 0

Password file = passwords.txt

Admin user = user1

SMTP host = smtp. mail.com

SMTP port = 25

SMTP username = user1@mail.com

SMTP Password = GIwbx7UbmkWs5J0P8lVztX7Anje0/21BU/Tmk0aPm.

Logfile = ELog_log.txt

Logging level = 3

 

 

[Server]

Logbook dir = Server

Theme = default

Comment = Server Change Log

Attributes = Author, Email, Type, Category, Subject

Subst Author = $long_name from $remote_host

Subst Email = $user_email

Options Type = SRV 1, SRV 2, SRV Sup, BMS content, BMS setpoints, BMS new

Options Category = Config, User, Access, Connection, Change, New, Delete

Extendable Options =

Required Attributes = Author, Type

Page Title = ELOG - $subject

Reverse sort = 1

Quick filter = Date, Type

Andreas Luedeke wrote:

If you would post a minimal config file where the problem occurs, then we could look what the problem is.

Gys Wuyts wrote:

Thank you but that is already  in place. I have the same issue on both Windows 10 and Windows Server 2016 and 2019.

tnks

g

Stefan Ritt wrote:

You need user-level access control, using 

Password file = ...

Stefan

Gys Wuyts wrote:

Hello,

what are the pre-requisites to automatically fill the Author and Author Email fields. The documented method:

Subst Author = $long_name from $remote_host

Subst Email = $user_email

in the elogd.cfg file does not seem to work.

(I see it works here on this platform)

Tnks

 

G

 

 

 

 

 

                   icon2.gif   Re: auto pre-fill fields issue, posted by Gys Wuyts on Mon Apr 12 14:17:52 2021 

Super, overlooked that one. Works now

 

g

Stefan Ritt wrote:

"Subst xxx" replaces after you submit an entry, while "Preset xxx" replaces before you create an entry. I believe you want the second one.

Stefan

Gys Wuyts wrote:

[global]

port = 8080

ssl = 0

Password file = passwords.txt

Admin user = user1

SMTP host = smtp. mail.com

SMTP port = 25

SMTP username = user1@mail.com

SMTP Password = GIwbx7UbmkWs5J0P8lVztX7Anje0/21BU/Tmk0aPm.

Logfile = ELog_log.txt

Logging level = 3

 

 

[Server]

Logbook dir = Server

Theme = default

Comment = Server Change Log

Attributes = Author, Email, Type, Category, Subject

Subst Author = $long_name from $remote_host

Subst Email = $user_email

Options Type = SRV 1, SRV 2, SRV Sup, BMS content, BMS setpoints, BMS new

Options Category = Config, User, Access, Connection, Change, New, Delete

Extendable Options =

Required Attributes = Author, Type

Page Title = ELOG - $subject

Reverse sort = 1

Quick filter = Date, Type

Andreas Luedeke wrote:

If you would post a minimal config file where the problem occurs, then we could look what the problem is.

Gys Wuyts wrote:

Thank you but that is already  in place. I have the same issue on both Windows 10 and Windows Server 2016 and 2019.

tnks

g

Stefan Ritt wrote:

You need user-level access control, using 

Password file = ...

Stefan

Gys Wuyts wrote:

Hello,

what are the pre-requisites to automatically fill the Author and Author Email fields. The documented method:

Subst Author = $long_name from $remote_host

Subst Email = $user_email

in the elogd.cfg file does not seem to work.

(I see it works here on this platform)

Tnks

 

G

 

 

 

 

 

 

icon5.gif   Parsing log files, posted by Alan Grant on Fri Jan 8 05:48:45 2021 

Sometimes we change the attributes in a config file for a given tab as time goes on, which naturally can get out of sync with the older data in that tab.

I can imagine some other Elog users have encounterd this too at some point so I'm wondering if there's a utilty or some way anyone knows of that I can use to parse a log file DIRECTLY to view the older data, without using the Elog GUI?

    icon1.gif   Re: Parsing log files, posted by John on Fri Jan 8 06:14:49 2021 

Hi Al; if I understand your situation correctly you want to access Elog db (logbooks) via another way. There are many ways depending on your knowledge, type of work needed, and ease of use. I have found that accessing whatever I need via Elog gui is satisfactory in many situations-- by simply exporting. THEN take the raw csv/xml  file and manipulte it more easily from there. There are MANY free web sites that will take your data then, and put it in still another format that you choose (usually manipulating the rows/columns to your liking or doing mail-merge type work on your data). BTW WPS (Windows Office clone) is awesome at further 'mail-merg'  techniques. THEN at that point you may have close to what you are trying to accomplish. I've also used PHP alot in this type of situation and have replicated Elog's data format for it's db (logbooks)..; so PHP is great in this maner, although of course it takes time to 'get-it-right' if you are not well versed in it. If you go into detail more of what type of format you want as the finalized product, maybe  more suggestions will be made.

Happy belated New Years everyone,

John

Alan Grant wrote:

Sometimes we change the attributes in a config file for a given tab as time goes on, which naturally can get out of sync with the older data in that tab.

I can imagine some other Elog users have encounterd this too at some point so I'm wondering if there's a utilty or some way anyone knows of that I can use to parse a log file DIRECTLY to view the older data, without using the Elog GUI?

 

       icon2.gif   Re: Parsing log files, posted by Alan Grant on Fri Jan 8 15:28:06 2021 

 

John wrote:

Hi Al; if I understand your situation correctly you want to access Elog db (logbooks) via another way. There are many ways depending on your knowledge, type of work needed, and ease of use. I have found that accessing whatever I need via Elog gui is satisfactory in many situations-- by simply exporting. THEN take the raw csv/xml  file and manipulte it more easily from there. There are MANY free web sites that will take your data then, and put it in still another format that you choose (usually manipulating the rows/columns to your liking or doing mail-merge type work on your data). BTW WPS (Windows Office clone) is awesome at further 'mail-merg'  techniques. THEN at that point you may have close to what you are trying to accomplish. I've also used PHP alot in this type of situation and have replicated Elog's data format for it's db (logbooks)..; so PHP is great in this maner, although of course it takes time to 'get-it-right' if you are not well versed in it. If you go into detail more of what type of format you want as the finalized product, maybe  more suggestions will be made.

Happy belated New Years everyone,

John

Alan Grant wrote:

Sometimes we change the attributes in a config file for a given tab as time goes on, which naturally can get out of sync with the older data in that tab.

I can imagine some other Elog users have encounterd this too at some point so I'm wondering if there's a utilty or some way anyone knows of that I can use to parse a log file DIRECTLY to view the older data, without using the Elog GUI?

 

Hi John. The problem with using the Find-->Export method is that some of the Attributes for the older data are no longer shown on that screen because the Config file has since changed. That's why I'm contemplating somehow parsing the log files directly instead.

          icon2.gif   Re: Parsing log files, posted by Stefan Ritt on Fri Jan 8 15:35:35 2021 

Well, you could put the old options back to the config file, do the export, then remove them again.

But have a look at the Elog database files ZZMMDDa.log in your logbook directory, they are pure ASCII files, which are relatively simple to parse.

Hi John. The problem with using the Find-->Export method is that some of the Attributes for the older data are no longer shown on that screen because the Config file has since changed. That's why I'm contemplating somehow parsing the log files directly instead.

 

    icon2.gif   Re: Parsing log files, posted by Lagarde on Wed Apr 7 17:11:28 2021 

Hi,

I had similar needs (access and parse logs ) so I'm  a small library in cpp. Have a look on https://github.com/flagarde/elogpp maybe it could be usefull for you too.

Alan Grant wrote:

Sometimes we change the attributes in a config file for a given tab as time goes on, which naturally can get out of sync with the older data in that tab.

I can imagine some other Elog users have encounterd this too at some point so I'm wondering if there's a utilty or some way anyone knows of that I can use to parse a log file DIRECTLY to view the older data, without using the Elog GUI?

 

icon5.gif   Pre-fill Attribute with last entry, posted by Dominic Schneider on Wed Mar 24 16:20:37 2021 

Hi all together,

I struggle a lot with the following problem:
I try to prefill certain attributes with the value of exactly the same attribute in the last entry made in the same logbook.

I know I have to go with Preset, tried a view hours and searched the forum but i didn't find a thing. Am I overlooking a flag, an option or whatever, or is there just not such a functionality (which I dont believe)?

I thought about:
Preset Test_Attribute = $Test_attribute
Preset Test_Attribute = Re:$Test_attribute
Preset Test_Attribute = $shell(Command to somehow get last entry and this attributes value)
Not succesful though.

I would be very thankful for help, thanks in advance.

    icon2.gif   Re: Pre-fill Attribute with last entry, posted by Stefan Ritt on Wed Mar 24 16:25:36 2021 

Nope, there is no way to acces the last value of an attribute. Sorry.

Stefan

Dominic Schneider wrote:

Hi all together,

I struggle a lot with the following problem:
I try to prefill certain attributes with the value of exactly the same attribute in the last entry made in the same logbook.

I know I have to go with Preset, tried a view hours and searched the forum but i didn't find a thing. Am I overlooking a flag, an option or whatever, or is there just not such a functionality (which I dont believe)?

I thought about:
Preset Test_Attribute = $Test_attribute
Preset Test_Attribute = Re:$Test_attribute
Preset Test_Attribute = $shell(Command to somehow get last entry and this attributes value)
Not succesful though.

I would be very thankful for help, thanks in advance.

 

       icon2.gif   Re: Pre-fill Attribute with last entry, posted by Sebastian Schenk on Wed Mar 24 17:36:15 2021 

Sorry Stefan, but it is possible as you have the scripting ability.

The idea is to use "Preset Test_Attribute = $shell(script_to_get_the_last_entry)", where the script asks elog about the details and parses them.
The problem here is, that the elogd already is working to resolve the click on "new entry" request (or similar) and the script can't call elogd until the page is delievered, what is to late.
(If it would, the elogd will hang.)

So the script either has to directly parse all the entry.log files in the logbook folder or you need a second elogd running, which can answer the request from the script.
This second elogd could run on a different port and it doen't need to be public as it only answers internal requests and could use the same config as the "primary" elogd.
My idea for the script uses the python elog module to establish the connection and do the parsing.

I hope this helps as a workaround.
Best wishes,
Sebastian

 

Stefan Ritt wrote:

Nope, there is no way to acces the last value of an attribute. Sorry.

Stefan

Dominic Schneider wrote:

Hi all together,

I struggle a lot with the following problem:
I try to prefill certain attributes with the value of exactly the same attribute in the last entry made in the same logbook.

I know I have to go with Preset, tried a view hours and searched the forum but i didn't find a thing. Am I overlooking a flag, an option or whatever, or is there just not such a functionality (which I dont believe)?

I thought about:
Preset Test_Attribute = $Test_attribute
Preset Test_Attribute = Re:$Test_attribute
Preset Test_Attribute = $shell(Command to somehow get last entry and this attributes value)
Not succesful though.

I would be very thankful for help, thanks in advance.

 

 

          icon2.gif   Re: Pre-fill Attribute with last entry, posted by Dominic Schneider on Wed Mar 24 19:30:50 2021 

Hi Stefan, hi Sebastian,

thank you for your help. Ok I see its not that simple.

Is there maybe a way of executing a Script on submitting, writing the values of the Attributes into an temporary file and loading the values from this file via a preset shell script when opening a NEW entry?

Best wishes & thanks in advance

Sebastian Schenk wrote:

Sorry Stefan, but it is possible as you have the scripting ability.

The idea is to use "Preset Test_Attribute = $shell(script_to_get_the_last_entry)", where the script asks elog about the details and parses them.
The problem here is, that the elogd already is working to resolve the click on "new entry" request (or similar) and the script can't call elogd until the page is delievered, what is to late.
(If it would, the elogd will hang.)

So the script either has to directly parse all the entry.log files in the logbook folder or you need a second elogd running, which can answer the request from the script.
This second elogd could run on a different port and it doen't need to be public as it only answers internal requests and could use the same config as the "primary" elogd.
My idea for the script uses the python elog module to establish the connection and do the parsing.

I hope this helps as a workaround.
Best wishes,
Sebastian

 

Stefan Ritt wrote:

Nope, there is no way to acces the last value of an attribute. Sorry.

Stefan

Dominic Schneider wrote:

Hi all together,

I struggle a lot with the following problem:
I try to prefill certain attributes with the value of exactly the same attribute in the last entry made in the same logbook.

I know I have to go with Preset, tried a view hours and searched the forum but i didn't find a thing. Am I overlooking a flag, an option or whatever, or is there just not such a functionality (which I dont believe)?

I thought about:
Preset Test_Attribute = $Test_attribute
Preset Test_Attribute = Re:$Test_attribute
Preset Test_Attribute = $shell(Command to somehow get last entry and this attributes value)
Not succesful though.

I would be very thankful for help, thanks in advance.

 

 

 

             icon2.gif   Re: Pre-fill Attribute with last entry, posted by Stefan Ritt on Wed Mar 24 19:45:41 2021 

That would actually be my recommendation. There is a "execute new" which you can call when submitting a new entry.

Stefan

Dominic Schneider wrote:

Hi Stefan, hi Sebastian,

thank you for your help. Ok I see its not that simple.

Is there maybe a way of executing a Script on submitting, writing the values of the Attributes into an temporary file and loading the values from this file via a preset shell script when opening a NEW entry?

Best wishes & thanks in advance

Sebastian Schenk wrote:

Sorry Stefan, but it is possible as you have the scripting ability.

The idea is to use "Preset Test_Attribute = $shell(script_to_get_the_last_entry)", where the script asks elog about the details and parses them.
The problem here is, that the elogd already is working to resolve the click on "new entry" request (or similar) and the script can't call elogd until the page is delievered, what is to late.
(If it would, the elogd will hang.)

So the script either has to directly parse all the entry.log files in the logbook folder or you need a second elogd running, which can answer the request from the script.
This second elogd could run on a different port and it doen't need to be public as it only answers internal requests and could use the same config as the "primary" elogd.
My idea for the script uses the python elog module to establish the connection and do the parsing.

I hope this helps as a workaround.
Best wishes,
Sebastian

 

Stefan Ritt wrote:

Nope, there is no way to acces the last value of an attribute. Sorry.

Stefan

Dominic Schneider wrote:

Hi all together,

I struggle a lot with the following problem:
I try to prefill certain attributes with the value of exactly the same attribute in the last entry made in the same logbook.

I know I have to go with Preset, tried a view hours and searched the forum but i didn't find a thing. Am I overlooking a flag, an option or whatever, or is there just not such a functionality (which I dont believe)?

I thought about:
Preset Test_Attribute = $Test_attribute
Preset Test_Attribute = Re:$Test_attribute
Preset Test_Attribute = $shell(Command to somehow get last entry and this attributes value)
Not succesful though.

I would be very thankful for help, thanks in advance.

 

 

 

 

                icon2.gif   Re: Pre-fill Attribute with last entry, posted by Dominic Schneider on Thu Mar 25 07:48:24 2021 

Thank you very much.

So far I testet all functionalities and scripts to reach my goal. I will post a dummy of the solution later on for future purposes.

Best wishes 

Stefan Ritt wrote:

That would actually be my recommendation. There is a "execute new" which you can call when submitting a new entry.

Stefan

Dominic Schneider wrote:

Hi Stefan, hi Sebastian,

thank you for your help. Ok I see its not that simple.

Is there maybe a way of executing a Script on submitting, writing the values of the Attributes into an temporary file and loading the values from this file via a preset shell script when opening a NEW entry?

Best wishes & thanks in advance

Sebastian Schenk wrote:

Sorry Stefan, but it is possible as you have the scripting ability.

The idea is to use "Preset Test_Attribute = $shell(script_to_get_the_last_entry)", where the script asks elog about the details and parses them.
The problem here is, that the elogd already is working to resolve the click on "new entry" request (or similar) and the script can't call elogd until the page is delievered, what is to late.
(If it would, the elogd will hang.)

So the script either has to directly parse all the entry.log files in the logbook folder or you need a second elogd running, which can answer the request from the script.
This second elogd could run on a different port and it doen't need to be public as it only answers internal requests and could use the same config as the "primary" elogd.
My idea for the script uses the python elog module to establish the connection and do the parsing.

I hope this helps as a workaround.
Best wishes,
Sebastian

 

Stefan Ritt wrote:

Nope, there is no way to acces the last value of an attribute. Sorry.

Stefan

Dominic Schneider wrote:

Hi all together,

I struggle a lot with the following problem:
I try to prefill certain attributes with the value of exactly the same attribute in the last entry made in the same logbook.

I know I have to go with Preset, tried a view hours and searched the forum but i didn't find a thing. Am I overlooking a flag, an option or whatever, or is there just not such a functionality (which I dont believe)?

I thought about:
Preset Test_Attribute = $Test_attribute
Preset Test_Attribute = Re:$Test_attribute
Preset Test_Attribute = $shell(Command to somehow get last entry and this attributes value)
Not succesful though.

I would be very thankful for help, thanks in advance.

 

 

 

 

 

                   icon2.gif   Re: Pre-fill Attribute with last entry, posted by Sebastian Schenk on Thu Mar 25 12:50:08 2021 

I am glad, we could help.

I can see a caveat in the recommendation.
By having "Execute New = echo $attrib > /path/last_attrib" and "Preset attrib = $shell(cat /path/last_attrib)" as the most simple construction.
But there are cases, where /path/last_attrib can get out of sync with the elog by e.g. editing or deleting the last entry, which is the most likely one to edit or delete.

I am aware, that you can make the logic more complex to fix this issue,
but basically you have the same information stored in two locations and you have to keep them in sync for the system to be reliable.
I am not sure, if it will be more hassle to construct a script/config system to keep them in sync or to find a solution which gets the information from the elog database.

Dominic Schneider wrote:

Thank you very much.

So far I testet all functionalities and scripts to reach my goal. I will post a dummy of the solution later on for future purposes.

Best wishes 

Stefan Ritt wrote:

That would actually be my recommendation. There is a "execute new" which you can call when submitting a new entry.

Stefan

Dominic Schneider wrote:

Hi Stefan, hi Sebastian,

thank you for your help. Ok I see its not that simple.

Is there maybe a way of executing a Script on submitting, writing the values of the Attributes into an temporary file and loading the values from this file via a preset shell script when opening a NEW entry?

Best wishes & thanks in advance

Sebastian Schenk wrote:

Sorry Stefan, but it is possible as you have the scripting ability.

The idea is to use "Preset Test_Attribute = $shell(script_to_get_the_last_entry)", where the script asks elog about the details and parses them.
The problem here is, that the elogd already is working to resolve the click on "new entry" request (or similar) and the script can't call elogd until the page is delievered, what is to late.
(If it would, the elogd will hang.)

So the script either has to directly parse all the entry.log files in the logbook folder or you need a second elogd running, which can answer the request from the script.
This second elogd could run on a different port and it doen't need to be public as it only answers internal requests and could use the same config as the "primary" elogd.
My idea for the script uses the python elog module to establish the connection and do the parsing.

I hope this helps as a workaround.
Best wishes,
Sebastian

 

Stefan Ritt wrote:

Nope, there is no way to acces the last value of an attribute. Sorry.

Stefan

Dominic Schneider wrote:

Hi all together,

I struggle a lot with the following problem:
I try to prefill certain attributes with the value of exactly the same attribute in the last entry made in the same logbook.

I know I have to go with Preset, tried a view hours and searched the forum but i didn't find a thing. Am I overlooking a flag, an option or whatever, or is there just not such a functionality (which I dont believe)?

I thought about:
Preset Test_Attribute = $Test_attribute
Preset Test_Attribute = Re:$Test_attribute
Preset Test_Attribute = $shell(Command to somehow get last entry and this attributes value)
Not succesful though.

I would be very thankful for help, thanks in advance.

 

 

 

 

 

 

                      icon2.gif   Re: Pre-fill Attribute with last entry, posted by Richard Stamper on Tue Mar 30 13:43:46 2021 

Just noting that, depending on what you want to achieve, you may be able to use the threading functionality so that a "new" entry is actually a "reply" to a previous entry.  This will allow you to populate attributes with values from that previous entry without having to rely on storing information outside the system, with all the attendant concurrency risks already identified.

Sebastian Schenk wrote:

I am glad, we could help.

I can see a caveat in the recommendation.
By having "Execute New = echo $attrib > /path/last_attrib" and "Preset attrib = $shell(cat /path/last_attrib)" as the most simple construction.
But there are cases, where /path/last_attrib can get out of sync with the elog by e.g. editing or deleting the last entry, which is the most likely one to edit or delete.

I am aware, that you can make the logic more complex to fix this issue,
but basically you have the same information stored in two locations and you have to keep them in sync for the system to be reliable.
I am not sure, if it will be more hassle to construct a script/config system to keep them in sync or to find a solution which gets the information from the elog database.

Dominic Schneider wrote:

Thank you very much.

So far I testet all functionalities and scripts to reach my goal. I will post a dummy of the solution later on for future purposes.

Best wishes 

Stefan Ritt wrote:

That would actually be my recommendation. There is a "execute new" which you can call when submitting a new entry.

Stefan

Dominic Schneider wrote:

Hi Stefan, hi Sebastian,

thank you for your help. Ok I see its not that simple.

Is there maybe a way of executing a Script on submitting, writing the values of the Attributes into an temporary file and loading the values from this file via a preset shell script when opening a NEW entry?

Best wishes & thanks in advance

Sebastian Schenk wrote:

Sorry Stefan, but it is possible as you have the scripting ability.

The idea is to use "Preset Test_Attribute = $shell(script_to_get_the_last_entry)", where the script asks elog about the details and parses them.
The problem here is, that the elogd already is working to resolve the click on "new entry" request (or similar) and the script can't call elogd until the page is delievered, what is to late.
(If it would, the elogd will hang.)

So the script either has to directly parse all the entry.log files in the logbook folder or you need a second elogd running, which can answer the request from the script.
This second elogd could run on a different port and it doen't need to be public as it only answers internal requests and could use the same config as the "primary" elogd.
My idea for the script uses the python elog module to establish the connection and do the parsing.

I hope this helps as a workaround.
Best wishes,
Sebastian

 

Stefan Ritt wrote:

Nope, there is no way to acces the last value of an attribute. Sorry.

Stefan

Dominic Schneider wrote:

Hi all together,

I struggle a lot with the following problem:
I try to prefill certain attributes with the value of exactly the same attribute in the last entry made in the same logbook.

I know I have to go with Preset, tried a view hours and searched the forum but i didn't find a thing. Am I overlooking a flag, an option or whatever, or is there just not such a functionality (which I dont believe)?

I thought about:
Preset Test_Attribute = $Test_attribute
Preset Test_Attribute = Re:$Test_attribute
Preset Test_Attribute = $shell(Command to somehow get last entry and this attributes value)
Not succesful though.

I would be very thankful for help, thanks in advance.

 

 

 

 

 

 

 

ELOG V3.1.5-3fb85fa6