| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68882
|
Fri Feb 1 19:20:35 2019 |
 | Frank Baptista | caffeinejazz@gmail.com | Question | Windows | 3.1.2 | Re: Logbook architecture and availability | I've got things working - sort of. Ran into one strange problem that has me scratching my head. I have two different laptops, each running a local instance of their own logbook. Both are functional, but for some strange reason, one looks great, and the other is missing its graphic format. I've attached a screen capture of that logbook, and a copy of the config file. Do you see something that I've done wrong?
Thanks,
Frank
| Frank Baptista wrote: |
|
Thank you again -- very much appreciated! 
| Stefan Ritt wrote: |
|
I would call the laptops the "master" being responsible for pushing data to the central server which you can call "slave"
Stefan
| Frank Baptista wrote: |
|
Thanks Stephan! I guess I was making it harder than it is. I'm still a little fuzzy -- in this instance, am I correct in saying that each laptop would be considered a "master", and the remote (network) server considered the "slave"? Also, I'm not sure quite sure -- which server should be assigned responsibility for performing periodic synchronization between the laptop and the central elog server?
Thanks again for all you do -- Happy Holidays!
Frank
| Stefan Ritt wrote: |
|
Sure that's easy. Install elog on each laptop separately, so they run without network. Then, set up a central elog server, and use "mirroring" as explained in the documentation at https://elog.psi.ch/elog/config.html#mirroring
So when ever the entwork comes back, you execute a manual mirror operation, and your new entries will be pushed to the central elog server.
Best,
Stefan
| Frank Baptista wrote: |
|
I have a setting which makes ELOG a perfect solution, but there's a situation that I'm struggling to get my head around. We have 3 separate laboratories, each one containing a number of temperature chambers, which run almost constantly over a number of shifts. Each temperature chamber has it's own logbook (laptop). So far, pretty simple.
My dilemma is, our network goes down for maintenance/updates (more often than I'd like), but our operation cannot afford to stop during network interruptions.
With that said, I thought about whether I could run a "local" logbook on each laptop/chamber, and somehow mirror the local logbook to the main ELOG server.
Perhaps I'm over-thinking this...do you have any recommendations?
|
|
|
|
|
|
| Attachment 1: ELOG_Screen_Capture_-_Missing_formatting.PNG
|
|
| Attachment 2: elogd.cfg
|
[global]
port = 8080
Resource dir = C:\Program Files (x86)\ELOG\resources
Logbook dir = C:\Program Files (x86)\ELOG\logbooks
Language = lenglish
[CH79]
Theme = default
Subdir = CH79
Comment = ESS - CH79 / JETS-1
Menu commands = List, Reply, Help
List Menu commands = New, Find, Help
Attributes = Clock #, Type, Category, Production Status, Perform OPM?, ATMS Correct?
Options Type = Test{1}, Equipment Incident{2}
{1} Options Category = Production, Engineering, Update
{2} Options Category = OPM Issue, Test Station, ITA, Chamber, Chiller, Socket, Software change, Hardware change, Update, Other
{1} Show Attributes Edit = Clock #, Type, Category, Production Status, Perform OPM?, ATMS Correct?
{2} Show Attributes Edit = Clock #, Type, Category, Production Status
{1} Preset text = C:\Program Files (x86)\ELOG\JETS_Template.htm
Options Production Status = Running, Open, Down, Engineering
Options Perform OPM? = boolean
Options ATMS Correct? = boolean
Comment Perform OPM? = If issue(s) found, create separate logbook entry.
Comment ATMS Correct? = All entries correct? Checked ATMS constraint?
Cell Style Production Status Running = background-color:green
Cell Style Production Status Open = background-color:yellow
Cell Style Production Status Down = background-color:red
Cell Style Production Status Engineering = background-color:blue
Required Attributes = Clock #, Type, Category, Production Status
Preset on reply Type = $Type
Preset on reply Category = Update
Page Title = ELOG - CH79 / JETS-1
Reverse sort = 1
Save drafts = 0
Quick filter = Date, Type, Subtext
|
|
68883
|
Fri Feb 1 21:59:46 2019 |
| Frank Baptista | caffeinejazz@gmail.com | Question | Windows | 3.1.2 | Re: Logbook architecture and availability | Sorry -- dumb mistake. I moved the "theme" files to the resource folder. Works like a champ...life is good!
| Frank Baptista wrote: |
|
I've got things working - sort of. Ran into one strange problem that has me scratching my head. I have two different laptops, each running a local instance of their own logbook. Both are functional, but for some strange reason, one looks great, and the other is missing its graphic format. I've attached a screen capture of that logbook, and a copy of the config file. Do you see something that I've done wrong?
Thanks,
Frank
| Frank Baptista wrote: |
|
Thank you again -- very much appreciated!
| Stefan Ritt wrote: |
|
I would call the laptops the "master" being responsible for pushing data to the central server which you can call "slave"
Stefan
| Frank Baptista wrote: |
|
Thanks Stephan! I guess I was making it harder than it is. I'm still a little fuzzy -- in this instance, am I correct in saying that each laptop would be considered a "master", and the remote (network) server considered the "slave"? Also, I'm not sure quite sure -- which server should be assigned responsibility for performing periodic synchronization between the laptop and the central elog server?
Thanks again for all you do -- Happy Holidays!
Frank
| Stefan Ritt wrote: |
|
Sure that's easy. Install elog on each laptop separately, so they run without network. Then, set up a central elog server, and use "mirroring" as explained in the documentation at https://elog.psi.ch/elog/config.html#mirroring
So when ever the entwork comes back, you execute a manual mirror operation, and your new entries will be pushed to the central elog server.
Best,
Stefan
| Frank Baptista wrote: |
|
I have a setting which makes ELOG a perfect solution, but there's a situation that I'm struggling to get my head around. We have 3 separate laboratories, each one containing a number of temperature chambers, which run almost constantly over a number of shifts. Each temperature chamber has it's own logbook (laptop). So far, pretty simple.
My dilemma is, our network goes down for maintenance/updates (more often than I'd like), but our operation cannot afford to stop during network interruptions.
With that said, I thought about whether I could run a "local" logbook on each laptop/chamber, and somehow mirror the local logbook to the main ELOG server.
Perhaps I'm over-thinking this...do you have any recommendations?
|
|
|
|
|
|
|
|
68893
|
Wed Feb 20 22:24:05 2019 |
 | Alan Grant | agrant@winnipeg.ca | Request | Windows | 3.1.2 | New feature request for Options list | Is it possible to include an option in the next release to have the Options list reference a text file of attributes rather than explicity listing the attributes in the Config file directly?
This would make it much easier to maintain a particular list that is referenced in several log books. |
|
68895
|
Wed Feb 20 22:45:39 2019 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Windows | 3.1.2 | Re: New feature request for Options list | I can put it on the wish list.
| Alan Grant wrote: |
|
Is it possible to include an option in the next release to have the Options list reference a text file of attributes rather than explicity listing the attributes in the Config file directly?
This would make it much easier to maintain a particular list that is referenced in several log books.
|
|
|
68898
|
Tue Feb 26 14:26:13 2019 |
 | Vladimir Travalja | vlt@hll.mpg.de | Question | Linux | 3.1.2 | Migration from 3.1.2 version to 3.1.4 | Hi,
sorry for bugging you with this, but I could not find any information for making migration of elog system from one server to another.
The migration should be done from one server version (CentOS 6.10 to CentOS 7.6). Also we are talking about migration from one subdomain to another. Example subdomain1.example.com to subdomain2.example.com. Old elog application version is 3.1.2 and I would like to migrate to the latest version 3.1.4
Is the migration from one system to another possible? What are the prerequisites for migration?
Are there any instructions how to do it?
Thank you in advance and have yourself a lovely day,
Warmest regards
|
|
68899
|
Tue Feb 26 14:31:00 2019 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.2 | Re: Migration from 3.1.2 version to 3.1.4 | To move an elog instance, just stop the old server, move the configuration file elogd.cfg and the logbook directory to the new server, and start the new server. If the URL of the server changes, you have to adjust it in elogd.cfg.
Stefan
| Vladimir Travalja wrote: |
|
Hi,
sorry for bugging you with this, but I could not find any information for making migration of elog system from one server to another.
The migration should be done from one server version (CentOS 6.10 to CentOS 7.6). Also we are talking about migration from one subdomain to another. Example subdomain1.example.com to subdomain2.example.com. Old elog application version is 3.1.2 and I would like to migrate to the latest version 3.1.4
Is the migration from one system to another possible? What are the prerequisites for migration?
Are there any instructions how to do it?
Thank you in advance and have yourself a lovely day,
Warmest regards
|
|
|
68901
|
Thu Feb 28 14:56:50 2019 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Request | Windows | 3.1.2 | Re: New feature request for Options list | Just my two cent - I would have many very good applications for that feature:
- Keep option lists identical over different logbooks.
- Keep option lists identical over different applications.
- Create option lists from a database - that allows to use the options in many applications and in the database; e.g. a list of systems with a failure database, but failure reports in the regular ELOG.
- Export extendable option lists to other applications:
- Inform administrator about options that have been newly added to a logbook for a review.
- Provide option lists as menu buttons in these applications.
- Prevent other applications to submit elog entries with illegal option choices.
- Import extendable option lists from other applications (at least after next elogd restart, if no "update option list" URL/command is provided for elogd).
We recently went through the process of renaming a "system list" in several logbooks, to make it consistent over several facilities. If the "on-call service" is called "radio frequency", but the "system" is called "RF", then searching the logbook can become difficult. It was painful: half a dozen applications had to be adapted at the same time the lists were updated, because they had features to create a failure report to ELOG - assuming specific "system" names.
So I'm in favour of putting that high up in the wishlist :-)
| Stefan Ritt wrote: |
|
I can put it on the wish list.
| Alan Grant wrote: |
|
Is it possible to include an option in the next release to have the Options list reference a text file of attributes rather than explicity listing the attributes in the Config file directly?
This would make it much easier to maintain a particular list that is referenced in several log books.
|
|
|
|
68902
|
Thu Feb 28 16:03:36 2019 |
| David Pilgram | David.Pilgram@epost.org.uk | Request | Windows | 3.1.2 | Re: New feature request for Options list | May I slip my vote in for this, especially if it would allow more than 100 attributes (the default, and I do know how to increase it).
I even considered cutting that into two groups,. the first being words like "New", "Re-" and the second being actions. Clunkey and binned.
| Andreas Luedeke wrote: |
|
Just my two cent - I would have many very good applications for that feature:
- Keep option lists identical over different logbooks.
- Keep option lists identical over different applications.
- Create option lists from a database - that allows to use the options in many applications and in the database; e.g. a list of systems with a failure database, but failure reports in the regular ELOG.
- Export extendable option lists to other applications:
- Inform administrator about options that have been newly added to a logbook for a review.
- Provide option lists as menu buttons in these applications.
- Prevent other applications to submit elog entries with illegal option choices.
- Import extendable option lists from other applications (at least after next elogd restart, if no "update option list" URL/command is provided for elogd).
We recently went through the process of renaming a "system list" in several logbooks, to make it consistent over several facilities. If the "on-call service" is called "radio frequency", but the "system" is called "RF", then searching the logbook can become difficult. It was painful: half a dozen applications had to be adapted at the same time the lists were updated, because they had features to create a failure report to ELOG - assuming specific "system" names.
So I'm in favour of putting that high up in the wishlist :-)
| Stefan Ritt wrote: |
|
I can put it on the wish list.
| Alan Grant wrote: |
|
Is it possible to include an option in the next release to have the Options list reference a text file of attributes rather than explicity listing the attributes in the Config file directly?
This would make it much easier to maintain a particular list that is referenced in several log books.
|
|
|
|
|