ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68558
|
Mon Jan 30 17:45:18 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.8.1-2350 | Re: Opening a Local File using <a href="file:///../filename.doc">text</a> | If a file is on a memorystick and the memorystick is gone, how could elog bring it back? What you ask for is magic, sorry for that. Also if you move files outiside elog from one folder (drive) to anohter. How shoudl elog keep track of these files if they are outside? If your colleague moves some piece of equipment from A to B, without telling you, how can you guess where B is?
Terry Almond wrote: |
Hi Stefan
Unfortunately this would become impractical for us as many of the test data files which we'd need to link too are Gb's in size, some over 100Gb, hence only the files needed to do a say an inspection of the equipment would be copied onto memory sticks. Currently we use an excel speadsheet to store hyperlinks to all of the files / directories we need - unfortunately some people forget to update this and it was asked could we do it using elog as people are familiar with this wonderful peice of software.
Hence why i'm now investigating - so is it actually posible?
Kind regards
Terry
Stefan Ritt wrote: |
Linking to external files via "file:///..." is a bad idea, since only a pointer is stored in the elog. So if someone puts somehing on M: and the drive is removed, the file is physically gone. No way to retrieve it. Instead of puttting links to files, users should get trained to ATTACH the files to elog cntries (V3 of elog has a "Drop attachments here..." section. Only then the files are physically transferred into elog and accessible independed of your external memory stick.
Stefan
Terry Almond wrote: |
I've created an elog where users can then enter links to a file: for example they would enter:
<a href="file:///M:/Data/Inspection%20Reports/ABC123.doc">ABC123</a>
If they are running this on their desktops where everyones M drive is mapped to the same location, not a problem, the file opens perfectly.
The problem we have is some people work off of site and hence they run everything from a memory stick (USB drive), then once back in the office, copy the memory stick back on to the network.
Unfortunately when off of site the href link M: is no longer valid as the M drive doesn't exist.
Hence i've been trying to open a local file with the following syntax:
<a href="file:///../ABC123.doc">ABC123</a>
It just won't open
Hence in my frustration i basically copied the word file ABC123.doc into every single directory on the memory stick thinking surely this must work, it must find it somewhere, unfortunately not.
What am i doing wrong?
|
|
|
|
68557
|
Mon Jan 30 16:56:34 2017 |
| Terry Almond | terry.almond@stfc.ac.uk | Question | Windows | 2.8.1-2350 | Re: Opening a Local File using <a href="file:///../filename.doc">text</a> | Hi Stefan
Unfortunately this would become impractical for us as many of the test data files which we'd need to link too are Gb's in size, some over 100Gb, hence only the files needed to do a say an inspection of the equipment would be copied onto memory sticks. Currently we use an excel speadsheet to store hyperlinks to all of the files / directories we need - unfortunately some people forget to update this and it was asked could we do it using elog as people are familiar with this wonderful peice of software.
Hence why i'm now investigating - so is it actually posible?
Kind regards
Terry
Stefan Ritt wrote: |
Linking to external files via "file:///..." is a bad idea, since only a pointer is stored in the elog. So if someone puts somehing on M: and the drive is removed, the file is physically gone. No way to retrieve it. Instead of puttting links to files, users should get trained to ATTACH the files to elog cntries (V3 of elog has a "Drop attachments here..." section. Only then the files are physically transferred into elog and accessible independed of your external memory stick.
Stefan
Terry Almond wrote: |
I've created an elog where users can then enter links to a file: for example they would enter:
<a href="file:///M:/Data/Inspection%20Reports/ABC123.doc">ABC123</a>
If they are running this on their desktops where everyones M drive is mapped to the same location, not a problem, the file opens perfectly.
The problem we have is some people work off of site and hence they run everything from a memory stick (USB drive), then once back in the office, copy the memory stick back on to the network.
Unfortunately when off of site the href link M: is no longer valid as the M drive doesn't exist.
Hence i've been trying to open a local file with the following syntax:
<a href="file:///../ABC123.doc">ABC123</a>
It just won't open
Hence in my frustration i basically copied the word file ABC123.doc into every single directory on the memory stick thinking surely this must work, it must find it somewhere, unfortunately not.
What am i doing wrong?
|
|
|
68556
|
Mon Jan 30 16:47:31 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.8.1-2350 | Re: Opening a Local File using <a href="file:///../filename.doc">text</a> | Linking to external files via "file:///..." is a bad idea, since only a pointer is stored in the elog. So if someone puts somehing on M: and the drive is removed, the file is physically gone. No way to retrieve it. Instead of puttting links to files, users should get trained to ATTACH the files to elog cntries (V3 of elog has a "Drop attachments here..." section. Only then the files are physically transferred into elog and accessible independed of your external memory stick.
Stefan
Terry Almond wrote: |
I've created an elog where users can then enter links to a file: for example they would enter:
<a href="file:///M:/Data/Inspection%20Reports/ABC123.doc">ABC123</a>
If they are running this on their desktops where everyones M drive is mapped to the same location, not a problem, the file opens perfectly.
The problem we have is some people work off of site and hence they run everything from a memory stick (USB drive), then once back in the office, copy the memory stick back on to the network.
Unfortunately when off of site the href link M: is no longer valid as the M drive doesn't exist.
Hence i've been trying to open a local file with the following syntax:
<a href="file:///../ABC123.doc">ABC123</a>
It just won't open
Hence in my frustration i basically copied the word file ABC123.doc into every single directory on the memory stick thinking surely this must work, it must find it somewhere, unfortunately not.
What am i doing wrong?
|
|
68555
|
Mon Jan 30 15:50:45 2017 |
| Terry Almond | terry.almond@stfc.ac.uk | Question | Windows | 2.8.1-2350 | Opening a Local File using <a href="file:///../filename.doc">text</a> | I've created an elog where users can then enter links to a file: for example they would enter:
<a href="file:///M:/Data/Inspection%20Reports/ABC123.doc">ABC123</a>
If they are running this on their desktops where everyones M drive is mapped to the same location, not a problem, the file opens perfectly.
The problem we have is some people work off of site and hence they run everything from a memory stick (USB drive), then once back in the office, copy the memory stick back on to the network.
Unfortunately when off of site the href link M: is no longer valid as the M drive doesn't exist.
Hence i've been trying to open a local file with the following syntax:
<a href="file:///../ABC123.doc">ABC123</a>
It just won't open
Hence in my frustration i basically copied the word file ABC123.doc into every single directory on the memory stick thinking surely this must work, it must find it somewhere, unfortunately not.
What am i doing wrong?
|
68554
|
Mon Jan 30 12:03:36 2017 |
| Lee Burnside | lee.burnside@ttu.edu | Bug report | Linux | 3.1.2 | Re: Elog crashing at random intervals | Never mind, version from github solved issue.
Lee
Lee Burnside wrote: |
We're running Elog 3.1.2 om SL 7.2 and keep getting random crashes, sometimes when no one is accessing a logbook. The following is from /var/log/messages with debugging turned on after the latest crash.
Jan 28 12:43:56 archer elogd[9629]: POST /PHYS3305Spring2017/ HTTP/1.1
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "ajs_anonymous_id"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "ajs_user_id"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "ajs_group_id"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "__utma"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "__utmz"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "elc"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "_ga"
Jan 28 12:43:56 archer kernel: elogd[9629]: segfault at 0 ip 000000000042237e sp 00007ffe50fcfdc0 error 4 in elogd[400000+8b000]
Jan 28 12:43:56 archer systemd: elogd.service: main process exited, code=killed, status=11/SEGV
Jan 28 12:43:56 archer systemd: Unit elogd.service entered failed state.
Jan 28 12:43:56 archer systemd: elogd.service failed.
Nothing odd in the logbooks, no real activity happening at the time of any crash. Crashes after any amount of time from 1 hour to 24 hours, with littleAny clues?
|
|
68553
|
Sat Jan 28 22:23:46 2017 |
| Lee Burnside | lee.burnside@ttu.edu | Bug report | Linux | 3.1.2 | Elog crashing at random intervals | We're running Elog 3.1.2 om SL 7.2 and keep getting random crashes, sometimes when no one is accessing a logbook. The following is from /var/log/messages with debugging turned on after the latest crash.
Jan 28 12:43:56 archer elogd[9629]: POST /PHYS3305Spring2017/ HTTP/1.1
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "ajs_anonymous_id"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "ajs_user_id"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "ajs_group_id"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "__utma"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "__utmz"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "elc"
Jan 28 12:43:56 archer elogd[9629]: Received unknown cookie "_ga"
Jan 28 12:43:56 archer kernel: elogd[9629]: segfault at 0 ip 000000000042237e sp 00007ffe50fcfdc0 error 4 in elogd[400000+8b000]
Jan 28 12:43:56 archer systemd: elogd.service: main process exited, code=killed, status=11/SEGV
Jan 28 12:43:56 archer systemd: Unit elogd.service entered failed state.
Jan 28 12:43:56 archer systemd: elogd.service failed.
Nothing odd in the logbooks, no real activity happening at the time of any crash. Crashes after any amount of time from 1 hour to 24 hours, with littleAny clues?
|
68552
|
Thu Jan 19 12:56:51 2017 |
| Andreas Warburton | awarburt@physics.mcgill.ca | Bug report | Linux | V3.1.2 | Re: elogd crashes during SSL Mirror operations involving attachments | Further to my comment in https://midas.psi.ch/elogs/Forum/68549, if the described synchronization requires attachment(s) to be transferred from my Mac laptop to the Debian linux server (with SSL = 0 set), it fails in all the tests that I tried.
To check whether these problems are linked to the OpenSSL version on the linux server, we also tried building an elogd executable using 1.0.2j instead of 1.0.1t. This did not appear to change/improve the behaviour.
I'd like to keep using ELOG into the foreseeable future. Don't hesitate to contact me if you'd like me to beta test any upcoming releases. I'd appreciate having the earlier mirroring and attachment-handling functionality back again.
Best regards,
Andreas W.
Andreas Warburton wrote: |
For the time being, I am deeming ELOG 3.1.2 unusable with https (SSL = 1) functionality on my "Debian GNU/Linux 7 (wheezy)" server with "OpenSSL 1.0.1t", due to the described apparent issues with SSL. Reverting to http (SSL = 0) brings back my ability to upload attachments and synchronize with a remote elogd running on a MacOS laptop.
Interestingly, my records indicate that I suffered a problem with very similar symptoms back in 2011, with version 2.8.0. The problem at that time, which is acknowledged in the Changelog as "Fixed bug with SSL connection shutdown", got fixed in version 2.9.0. Perhaps, when the "Replaced insecure SSLv23 with TLSv1 method" change was implemented for version 3.0.0, a similar issue was (re-)introduced?
It would of course be best if this issue were resolvable soon, due to the security vulnerabilities of http versus https. Thank you in advance for any efforts!
Best regards,
Andreas Warburton
Andreas Warburton wrote: |
When I switch from SSL = 1 to SSL = 0 and I use http:// instead of https://, the ability to upload attachments to logbook entries returns. With both Chrome and Safari browsers, with SSL = 1 the file upload hangs after only a small percentage of the file has been uploaded. I ran the following openssl diagnostic on my elogd port. Would anyone have advice on what might be causing such errors?
tapajo [/usr/local/elog/elog-latest] openssl s_client -connect elog.hep.xxx.xx:80xx -state -nbio | grep "^SSL"
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
SSL_connect:unknown state
depth=0 C = EU, ST = SomeState, L = SomeCity, O = SomeOranization, OU = SomeOrganizationUnit, CN = localhost
verify error:num=18:self signed certificate
verify return:1
depth=0 C = EU, ST = SomeState, L = SomeCity, O = SomeOranization, OU = SomeOrganizationUnit, CN = localhost
verify return:1
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:error in unknown state
SSL_connect:error in unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL handshake has read 1733 bytes and written 871 bytes
SSL-Session:
SSL3 alert read:warning:close notify
SSL3 alert write:warning:close notify
Andreas Warburton wrote: |
The attached screenshot shows the behaviour after doing a synchronization (with Mirror simulate = 1) following first having ensured that the local (Mac) and remote (linux) ELOGs initially showed "All entries identical" when doing a simulated synchronization, and then having edited local entries 9707 and 9709 by uploading (different) attachments to them.
The fact that the synchronization is suggesting to renumber two different entry IDs to the same number looks like a bug.
Best regards,
Andreas W.
Andreas Warburton wrote: |
My MacOS (10.12.2) elogd version V3.1.2 is a recent git commit (edc5e85), due to the fix to my earlier-described issue solved in the thread here: https://midas.psi.ch/elogs/Forum/68519.
I am trying to (re-)set up Mirror functionality with a linux server running the standard public (V3.1.2-bd75964). I had initially updated the linux server so that it also had the latest git commit (edc5e85), but could then not even add new logbook entries that involved attachments to it. I therefore rolled the linux server back to the standard public 3.1.2 version.
On the remote Mac, synchronizations usually look like they are going to work fine, with Mirror simulate = 1 switched on. After I set Mirror simulate = 0, and if the server and remote logbook are already identical, I *occasionally* get the proper "All Entries Identical" synchronization result. Unfortunately, this is very rare, and usually there is a failure whereby the remote (Mac) logbook decides that a significant fraction of its entries (usually sequential, from some seemingly random entry all the way up to the last entry) are missing on the linux server and need to be submitted back to the server from the remote Mac.
When the local and remote logbooks are not identical, and a record in need of synchronization contains an attachment, there is again destructive behaviour similar to that described above, except that the Mac elogd executable usually crashes. (As in the case of the already-identical synchronizations described above, I only tested this after observing the correct expected behaviour first with Mirror simulate = 1.)
I'd be grateful for some help/suggestions. My current testing suggests that my problems are likely not elog-content dependent. (The logbook now undergoing synching has less than 10 entries in it.)
More generally, the issue of having things behave fine with Mirror simulate = 1, but then experiencing corruption/damage when switching to Mirror simulate = 0 seems serious to me.
Many thanks, Andreas
|
|
|
|
|
68551
|
Wed Jan 18 10:25:20 2017 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | ELOG V3.1.1- | Re: "No SMTP host defined in [global] section of configuration file" | These problems usually come when you are using a different configuration file that the one you think you are using. Note that you explicitly can tell elogd to use a specific configuation file with the "-c" flag. Also make sure to restart elogd after major changes.
Luca wrote: |
Hi,
I started re-using after a month an elog on my linux machine and, without any apparent reason since I did not used the machine at all in the last month, every time I try to submit a post I get the following error
"No SMTP host defined in [global] section of configuration file".
The weird thing is that today I created a new logbook using the previous one as a template and, on the new one, I can post without problem (although the configuration is identical).
Do you know what could be causing this?
Thnaks
R
|
|
|