Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 17 of 238  Not logged in ELOG logo
icon5.gif   Log4j exploit, posted by Alan Grant on Tue Dec 14 19:16:57 2021 

Is there any potential impact/concern with the Log4j exploit in Elog applications?

 

    icon2.gif   Re: Log4j exploit, posted by Stefan Ritt on Tue Dec 14 21:55:16 2021 

ELog does not use the Log4j library so no issue there. If you run a web server like Apache in front of ELog, you however have to check if you use log4j there.

Alan Grant wrote:

Is there any potential impact/concern with the Log4j exploit in Elog applications?

 

 

icon1.gif   Dump screenshot to new elog entry, posted by Anthony J Krishock on Sun Dec 12 01:18:46 2021 

Hello,

I am interested in finding a preferrably single-click way to capture a screenshot and posting it automatically to a new elog entry . I would be doing this from Windows. Is this possible?

Thanks

    icon2.gif   Re: Dump screenshot to new elog entry, posted by Andreas Luedeke on Sun Dec 12 08:12:57 2021 

I am no Windows expert. An option is to write your own application and use the "elog" command to post the output of the application to your ELOG.
There is as well a python library to access ELOG via http: https://github.com/paulscherrerinstitute/py_elog

Anthony J Krishock wrote:

Hello,

I am interested in finding a preferrably single-click way to capture a screenshot and posting it automatically to a new elog entry . I would be doing this from Windows. Is this possible?

Thanks

 

icon4.gif   $attribute replacement fails occasionally, posted by Chris Körner on Sat Nov 27 21:48:41 2021 

Hi,

In our setup we have multiple logbooks. I want a convenient way to search all logbooks for an attribute (in our case with the name Sample-ID) by just clicking it in the list display of any logbook.Therefore, in the [global] section I put "List Change Sample-ID = <a href="https://ourelog.com/$logbook/?all=1&Sample-ID=$Sample-ID"</a>. This transforms the attribute in list display into a hyperlink to the search results page. So far this works fine. In the results page, of course the option also applies, meaning the attribute is replaced by the link as well. But here something odd happens and the replacement does not work. The intended behavior is to replace $logbook in the link with the name of the logbook. Sometimes, however, the replacement yields something like "logbook" (missing $ and thus not replacing anything) or even weirder something like "60logbook". I have no idea what causes this.

    icon2.gif   Re: $attribute replacement fails occasionally, posted by Chris Körner on Sat Dec 4 13:03:32 2021 Screenshot_2021-12-04_130843.jpg

This problen drives me crazy. Under some circumstances the List Change <attribute> function does not replace $attribute. It happens at random circumstances when I use the Find function to search all logbooks. In the resulting list, it fails reproducibly for certain entries of certain logbooks. But I cannot find what is special about those lokbooks or entries. In different Find requests it works perfectly fine. 

I have added a screenshot. The yellow button is created by this command in [global] for all logbooks. It makes no difference to define it in all [logbook] sections. I would really appreciate help to debug this. 

List Change Sample-ID        = <a href="page?mode=summary&reverse=1&all=1&Sample-ID=$Sample-ID$&sort=Date" class="id_div">$Sample-ID</a>

Chris Körner wrote:

Hi,

In our setup we have multiple logbooks. I want a convenient way to search all logbooks for an attribute (in our case with the name Sample-ID) by just clicking it in the list display of any logbook.Therefore, in the [global] section I put "List Change Sample-ID = <a href="https://ourelog.com/$logbook/?all=1&Sample-ID=$Sample-ID"</a>. This transforms the attribute in list display into a hyperlink to the search results page. So far this works fine. In the results page, of course the option also applies, meaning the attribute is replaced by the link as well. But here something odd happens and the replacement does not work. The intended behavior is to replace $logbook in the link with the name of the logbook. Sometimes, however, the replacement yields something like "logbook" (missing $ and thus not replacing anything) or even weirder something like "60logbook". I have no idea what causes this.

 

icon5.gif   Display edit time, posted by Devrim Esenturk on Wed Nov 24 08:12:17 2021 

Hi

I have a large logbook to keep office demo equipments listed. So editing entries are very often, I would like to see last editing time on my entry as entry time shown as each entry. Is there any way to do this? I checked all attributes and commands  but couldn't find any.

King regard

Devrim

    icon2.gif   Re: Display edit time, posted by Stefan Ritt on Wed Nov 24 08:38:33 2021 

Creat an attribute "last edit" and set it to the last edit time. Something like this:

Attributes = ...., Last edit
Preset Last edit = $date
​Preset on edit Last edit = $date
Locked attributes = Last edit

 

Devrim Esenturk wrote:

Hi

I have a large logbook to keep office demo equipments listed. So editing entries are very often, I would like to see last editing time on my entry as entry time shown as each entry. Is there any way to do this? I checked all attributes and commands  but couldn't find any.

King regard

Devrim

 

icon5.gif   Body of new messages not getting saved when submitted, posted by Harry Martin on Sun Nov 21 23:20:15 2021 

I've been using elog for a few years now.  I've had the current setup working for me up until today.  

If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved.  The body (the part I can see in the editor) does not get saved.

Yesterday, I did do some updates on the server machine.  Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines).  Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also.  About 50 packages were updated altogether.

Here are the packages that were updated yesterday (in case this is of interest to solving the issue):

 bind9-host:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 ckeditor:amd64 (4.5.7+dfsg-2, 4.5.7+dfsg-2+deb9u1)
 cron:amd64 (3.0pl1-128+deb9u1, 3.0pl1-128+deb9u2)
 dnsutils:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 firefox-esr:amd64 (78.14.0esr-1~deb9u1, 78.15.0esr-1~deb9u1)
 libapache2-mod-php7.0:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 libavcodec57:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libavfilter6:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libavformat57:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libavresample3:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libavutil55:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libbind9-140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libcups2:amd64 (2.2.1-8+deb9u6, 2.2.1-8+deb9u7)
 libcupsimage2:amd64 (2.2.1-8+deb9u6, 2.2.1-8+deb9u7)
 libdns162:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
libdns-export162:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libdw1:amd64 (0.168-1, 0.168-1+deb9u1)
 libelf1:amd64 (0.168-1, 0.168-1+deb9u1)
 libfaad2:amd64 (2.8.0~cvs20161113-1+deb9u2, 2.8.0~cvs20161113-1+deb9u3)
 libicu57:amd64 (57.1-6+deb9u4, 57.1-6+deb9u5)
 libisc160:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libisccc140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libisccfg140:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libisc-export160:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libjbig2dec0:amd64 (0.13-4.1, 0.13-4.1+deb9u1)
 liblwres141:amd64 (1:9.10.3.dfsg.P4-12.3+deb9u9, 1:9.10.3.dfsg.P4-12.3+deb9u10)
 libnghttp2-14:amd64 (1.18.1-1+deb9u1, 1.18.1-1+deb9u2)
 libntfs-3g871:amd64 (1:2016.2.22AR.1+dfsg-1+deb9u1, 1:2016.2.22AR.1+dfsg-1+deb9u2)
 libopencv-core2.4v5:amd64 (2.4.9.1+dfsg1-2, 2.4.9.1+dfsg1-2+deb9u1)
 libopencv-imgproc2.4v5:amd64 (2.4.9.1+dfsg1-2, 2.4.9.1+dfsg1-2+deb9u1)
 libpostproc54:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libpython3.5:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
 libpython3.5-minimal:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
 libpython3.5-stdlib:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
 libruby2.3:amd64 (2.3.3-1+deb9u9, 2.3.3-1+deb9u10)
 libsdl1.2debian:amd64 (1.2.15+dfsg1-4, 1.2.15+dfsg1-4+deb9u1)
 libswresample2:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 libswscale4:amd64 (7:3.2.15-0+deb9u4, 7:3.2.16-1+deb9u1)
 ntfs-3g:amd64 (1:2016.2.22AR.1+dfsg-1+deb9u1, 1:2016.2.22AR.1+dfsg-1+deb9u2)
 php7.0-cli:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-common:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-curl:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-intl:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-json:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-mbstring:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-opcache:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-readline:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 php7.0-xml:amd64 (7.0.33-0+deb9u11, 7.0.33-0+deb9u12)
 python3.5:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
 python3.5-minimal:amd64 (3.5.3-1+deb9u4, 3.5.3-1+deb9u5)
 ruby2.3:amd64 (2.3.3-1+deb9u9, 2.3.3-1+deb9u10)
 tzdata:amd64 (2021a-0+deb9u1, 2021a-0+deb9u2)

This is a devuan ascii server only for clients on a local area network.

    icon2.gif   Re: Body of new messages not getting saved when submitted, posted by Sebastian Schenk on Sun Nov 21 23:49:42 2021 

Hello Harry,

the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.

You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.

Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update? 
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.

Best wishes,
Sebastian

Harry Martin wrote:

I've been using elog for a few years now.  I've had the current setup working for me up until today.  

If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved.  The body (the part I can see in the editor) does not get saved.

Yesterday, I did do some updates on the server machine.  Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines).  Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also.  About 50 packages were updated altogether.

Here are the packages that were updated yesterday (in case this is of interest to solving the issue):

 [...]

This is a devuan ascii server only for clients on a local area network.

 

       icon2.gif   Re: Body of new messages not getting saved when submitted, posted by Harry Martin on Mon Nov 22 00:44:21 2021 

Thank you for your quick response, Sebastion.  The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2?  It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.

Sebastian Schenk wrote:

Hello Harry,

the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.

You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.

Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update? 
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.

Best wishes,
Sebastian

Harry Martin wrote:

I've been using elog for a few years now.  I've had the current setup working for me up until today.  

If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved.  The body (the part I can see in the editor) does not get saved.

Yesterday, I did do some updates on the server machine.  Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines).  Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also.  About 50 packages were updated altogether.

Here are the packages that were updated yesterday (in case this is of interest to solving the issue):

 [...]

This is a devuan ascii server only for clients on a local area network.

 

 

          icon2.gif   Re: Body of new messages not getting saved when submitted, posted by Harry Martin on Mon Nov 22 19:28:28 2021 

(disregard my recent post here about missing package -- that wasn't the elog server!)

I can see that ckeditor was upgraded 11/19, which is would be prior to my recent attempts to use elog.  It was apparently a security update, so I am not sure it is sensible to downgrade.  OTOH, I am the only person here, and I have all sides carefully barracaded, so I don't think it would be much of an issue.   But please disabuse me of my ignorance if need be.

Harry Martin wrote:

Thank you for your quick response, Sebastion.  The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2?  It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.

Sebastian Schenk wrote:

Hello Harry,

the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.

You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.

Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update? 
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.

Best wishes,
Sebastian

Harry Martin wrote:

I've been using elog for a few years now.  I've had the current setup working for me up until today.  

If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved.  The body (the part I can see in the editor) does not get saved.

Yesterday, I did do some updates on the server machine.  Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines).  Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also.  About 50 packages were updated altogether.

Here are the packages that were updated yesterday (in case this is of interest to solving the issue):

 [...]

This is a devuan ascii server only for clients on a local area network.

 

 

 

             icon2.gif   Re: Body of new messages not getting saved when submitted, posted by Harry Martin on Mon Nov 22 19:45:08 2021 

After downgrading ckeditor, my elog installation is working again.  Thanks for your help.

Harry Martin wrote:

(disregard my recent post here about missing package -- that wasn't the elog server!)

I can see that ckeditor was upgraded 11/19, which is would be prior to my recent attempts to use elog.  It was apparently a security update, so I am not sure it is sensible to downgrade.  OTOH, I am the only person here, and I have all sides carefully barracaded, so I don't think it would be much of an issue.   But please disabuse me of my ignorance if need be.

Harry Martin wrote:

Thank you for your quick response, Sebastion.  The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2?  It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.

Sebastian Schenk wrote:

Hello Harry,

the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.

You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.

Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update? 
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.

Best wishes,
Sebastian

Harry Martin wrote:

I've been using elog for a few years now.  I've had the current setup working for me up until today.  

If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved.  The body (the part I can see in the editor) does not get saved.

Yesterday, I did do some updates on the server machine.  Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines).  Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also.  About 50 packages were updated altogether.

Here are the packages that were updated yesterday (in case this is of interest to solving the issue):

 [...]

This is a devuan ascii server only for clients on a local area network.

 

 

 

 

icon5.gif   Restrict edit time = 0 behavior intended?, posted by Chris Körner on Mon Nov 15 11:35:55 2021 

Hi,

I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.

    icon2.gif   Re: Restrict edit time = 0 behavior intended?, posted by Chris Körner on Mon Nov 15 11:48:25 2021 

Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?

Chris Körner wrote:

Hi,

I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.

 

       icon2.gif   Re: Restrict edit time = 0 behavior intended?, posted by Sebastian Schenk on Mon Nov 15 14:02:42 2021 

Hi Chris,

my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c

As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.

Best wishes,
Sebastian

 

Chris Körner wrote:

Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?

Chris Körner wrote:

Hi,

I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.

 

 

          icon2.gif   Re: Restrict edit time = 0 behavior intended?, posted by Chris Körner on Tue Nov 16 15:14:42 2021 

Hi Sebastian,

thanks for the reply. It is just a bit confusing that these similar settings behave so differently. For me it is no big deal to set the time for every logbook independently instead of [global], but it leaves more room for configuration errors.

Best,
Chris

Sebastian Schenk wrote:

Hi Chris,

my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c

As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.

Best wishes,
Sebastian

 

Chris Körner wrote:

Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?

Chris Körner wrote:

Hi,

I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.

 

 

 

icon3.gif   Shared logbook and elog.cfg file across multiple installations, posted by Anthony on Mon Nov 15 15:41:04 2021 

Hi,

I'm wondering if it's possible to have a shared logbook and elog.cfg between multiple instances of elog.  Ideally, I'd like to have my logbooks folder and elog.cfg hosted on a nextcloud instance while running the elog service locally.  I've tried this using symlinks and shortcuts on windows with no luck.  I was able to install elog into my mounted nextcloud folder, but this isn't ideal as I would like this to work from multiple computers.

Any ideas or thoughts on how I can do this (if I can actually do this)?

    icon2.gif   Re: Shared logbook and elog.cfg file across multiple installations, posted by Sebastian Schenk on Mon Nov 15 17:40:08 2021 

Hi Anthony,

the elog has a mirroring function, which synchornizes config and logs between multiple instances.
See the bottom section of https://elog.psi.ch/elog/config.html

Best wishes,
Sebastian

Anthony wrote:

Hi,

I'm wondering if it's possible to have a shared logbook and elog.cfg between multiple instances of elog.  Ideally, I'd like to have my logbooks folder and elog.cfg hosted on a nextcloud instance while running the elog service locally.  I've tried this using symlinks and shortcuts on windows with no luck.  I was able to install elog into my mounted nextcloud folder, but this isn't ideal as I would like this to work from multiple computers.

Any ideas or thoughts on how I can do this (if I can actually do this)?

 

       icon2.gif   Re: Shared logbook and elog.cfg file across multiple installations, posted by Anthony on Tue Nov 16 13:05:05 2021 

Thank you Sebastian!

I admittidely haven't looked through the page in a while, so I completely missed this feature.  This should solve the problem, although in a slightly different implementation than what I was trying for.

Sebastian Schenk wrote:

Hi Anthony,

the elog has a mirroring function, which synchornizes config and logs between multiple instances.
See the bottom section of https://elog.psi.ch/elog/config.html

Best wishes,
Sebastian

Anthony wrote:

Hi,

I'm wondering if it's possible to have a shared logbook and elog.cfg between multiple instances of elog.  Ideally, I'd like to have my logbooks folder and elog.cfg hosted on a nextcloud instance while running the elog service locally.  I've tried this using symlinks and shortcuts on windows with no luck.  I was able to install elog into my mounted nextcloud folder, but this isn't ideal as I would like this to work from multiple computers.

Any ideas or thoughts on how I can do this (if I can actually do this)?

 

 

icon5.gif   results of security scan, posted by David Stops on Mon Nov 1 12:52:23 2021 

Recently central IT scanned our elog server and reported the following "vulnerabilities"

  • 42873 (1) - SSL Medium Strength Cipher Suites Supported (SWEET32)
  • 51192 (1) - SSL Certificate Cannot Be Trusted
  • 65821 (1) - SSL RC4 Cipher Suites Supported (Bar Mitzvah)
  • 85582 (1) - Web Application Potentially Vulnerable to Clickjacking

Is there any easy way of preventing these

Thanks and Best Wishes

David

    icon2.gif   Re: results of security scan, posted by Stefan Ritt on Tue Nov 2 12:07:46 2021 

The elgod.c progarm itself is rather weak in SSL, since I just don't have time to catch up with the latest SSL enhancements. The safest you can do is to put an industry-strenth web server like Apache in front of elogd and let that server handle the SSL layer.

Stefan

David Stops wrote:

Recently central IT scanned our elog server and reported the following "vulnerabilities"

  • 42873 (1) - SSL Medium Strength Cipher Suites Supported (SWEET32)
  • 51192 (1) - SSL Certificate Cannot Be Trusted
  • 65821 (1) - SSL RC4 Cipher Suites Supported (Bar Mitzvah)
  • 85582 (1) - Web Application Potentially Vulnerable to Clickjacking

Is there any easy way of preventing these

Thanks and Best Wishes

David

 

       icon2.gif   Re: results of security scan, posted by David Stops on Thu Nov 4 13:48:00 2021 

Thanks, I'll try that and see what happens

 

David

Stefan Ritt wrote:

The elgod.c progarm itself is rather weak in SSL, since I just don't have time to catch up with the latest SSL enhancements. The safest you can do is to put an industry-strenth web server like Apache in front of elogd and let that server handle the SSL layer.

Stefan

David Stops wrote:

Recently central IT scanned our elog server and reported the following "vulnerabilities"

  • 42873 (1) - SSL Medium Strength Cipher Suites Supported (SWEET32)
  • 51192 (1) - SSL Certificate Cannot Be Trusted
  • 65821 (1) - SSL RC4 Cipher Suites Supported (Bar Mitzvah)
  • 85582 (1) - Web Application Potentially Vulnerable to Clickjacking

Is there any easy way of preventing these

Thanks and Best Wishes

David

 

 

ELOG V3.1.5-3fb85fa6