ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
69346
|
Mon Apr 12 13:57:18 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 3.1.4 (latest) | Re: auto pre-fill fields issue | "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
|
|
|
|
|
|
69347
|
Mon Apr 12 14:17:52 2021 |
| Gys Wuyts | gys.wuyts@gmail.com | Question | Windows | 3.1.4 (latest) | Re: auto pre-fill fields issue | 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
|
|
|
|
|
|
|
69355
|
Mon Apr 26 15:40:36 2021 |
| Frank Baptista | caffeinejazz@gmail.com | Question | Windows | V3.1.3-fd7f1e2 | Real-time mirroring? | 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!
|
69356
|
Mon Apr 26 16:14:49 2021 |
| Frank Baptista | caffeinejazz@gmail.com | Question | Windows | 314-2 | Re: How to make personal ELOG to public | 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. |
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!
|
|
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!
|
|
|
|
|
|