Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 98 of 238  Not logged in ELOG logo
icon1.gif   redirect permission, posted by Adam on Mon Feb 13 13:38:19 2012 

Hi All,

Perhaps a trivial question but some issues have arisen accessing my long-running elog with SSL enabled.  I suspect firewalls and browser updates are involved and I do not have the time or experience to diagnose and debug such a potential black-hole of difficulties.  Instead I am looking for a quick fix, and the first step - switching off sll - seems to work.  Now I would like to use redirect so that the elog is running under apache, however this is where I have stumbled; I have passwords so the plan is to eventually secure using apache.  Apache works fine and is running pages on ports 80 and 443, although I seem unable to redirect the elog (port 8080).  Following the instructions on the administrators guide I get:

Forbidden

You don't have permission to access /elog/ on this server.

The page is found at least so my redirect is doing something, and I suspect the solution is trivial, though I'm not too sure where to start.

 

-------------------

 

Also, what is  the best practice for updating one's elog version.  I originally installed using a tarball.

 

 

 

    icon5.gif   Re: redirect permission, posted by Adam on Wed Feb 22 13:18:37 2012 

Adam wrote:

Hi All,

Perhaps a trivial question but some issues have arisen accessing my long-running elog with SSL enabled.  I suspect firewalls and browser updates are involved and I do not have the time or experience to diagnose and debug such a potential black-hole of difficulties.  Instead I am looking for a quick fix, and the first step - switching off sll - seems to work.  Now I would like to use redirect so that the elog is running under apache, however this is where I have stumbled; I have passwords so the plan is to eventually secure using apache.  Apache works fine and is running pages on ports 80 and 443, although I seem unable to redirect the elog (port 8080).  Following the instructions on the administrators guide I get:

Forbidden

You don't have permission to access /elog/ on this server.

The page is found at least so my redirect is doing something, and I suspect the solution is trivial, though I'm not too sure where to start.

 

-------------------

 

Also, what is  the best practice for updating one's elog version.  I originally installed using a tarball.

 

 

 

 Still struggling with this issue, if anyone has managed to solve it let me know.   I've done the obvious and checked ownership/ permissions of the elog folders and they are exactly the same as etc/var/www, which is working in apache.

icon1.gif   ssl problems, posted by Olaf Kasten on Fri Feb 10 11:54:35 2012 

 Hi there,

I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't  connect to the elog server with ssl = 1 in elogd.cfg. 

I tested with Firefox 3.6 and IE 7 installations and there are no problems.

I guess it's a bug. Does someone have a suggestion to solve that problem?

Thx. Olaf

    icon2.gif   Re: ssl problems, posted by John Doroshenko on Fri Feb 10 17:18:25 2012 

Olaf Kasten wrote:

 Hi there,

I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't  connect to the elog server with ssl = 1 in elogd.cfg. 

I tested with Firefox 3.6 and IE 7 installations and there are no problems.

I guess it's a bug. Does someone have a suggestion to solve that problem?

Thx. Olaf

 

Hi!

This just started happening here also.  Some users can't get on to a SSL=1 config'd elog using either IE or firefox 10 (win7 or linux) or chrome.  SAFARI works.  Occurs in 2.8.0 and a newly built (even after

ssl yum updates) 2.9.0 version on SL5.5 system.  Seems to accept self signed cert then nothing.. (connection reset message).   Tried an stunnel from one port to port running elog

with SSL=0.  Same behavior.  Doesn't work on some browsers.  Any clues?

Thanks,

-John

       icon2.gif   Re: ssl problems, posted by Andreas Luedeke on Sat Feb 11 05:43:33 2012 

John Doroshenko wrote:

Olaf Kasten wrote:

 Hi there,

I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't  connect to the elog server with ssl = 1 in elogd.cfg. 

I tested with Firefox 3.6 and IE 7 installations and there are no problems.

I guess it's a bug. Does someone have a suggestion to solve that problem?

Thx. Olaf

 Hi!

This just started happening here also.  Some users can't get on to a SSL=1 config'd elog using either IE or firefox 10 (win7 or linux) or chrome.  SAFARI works.  Occurs in 2.8.0 and a newly built (even after

ssl yum updates) 2.9.0 version on SL5.5 system.  Seems to accept self signed cert then nothing.. (connection reset message).   Tried an stunnel from one port to port running elog

with SSL=0.  Same behavior.  Doesn't work on some browsers.  Any clues?

Thanks,

-John

Hi everyone,
it appears that many people have this problem. I believe this is simply a problem of your firewall settings. There are two simple checks you can do to test if I'm right or wrong:
  • Run your logbook on the standard port 443 and retry. If the special port has been opened on the firewall, it has been likely only opened for specific clients like firefox 3.6, IE 7, etc. If you use a different client (FF 10, IE 9) the port can be blocked.
  • Or just run the browser that does not work on the ELOG server. If it works to access ELOG via localhost, then you know for sure that it is the firewall.
I've actually tested it here at my institute: I've downloaded firefox 10 and could access ELOG on port 443 but couldn't access it on port 444, unless I've started FF10 on the ELOG host.
To John, Olaf and Christian: If you need to be able to use a special port and a certain set of browsers then just contact your computing division or whoever maintains your firewalls.
 
I hope this settles the matter.
Cheers
Andreas
 
Detect language » English
 

PS: I've solved this with the help of google  : have a look at http://forums.mozillazine.org/viewtopic.php?p=2295421#2295421 about firewalls

          icon2.gif   Re: ssl problems, posted by Christian Herzog on Sat Feb 11 22:05:36 2012 

Andreas Luedeke wrote:

John Doroshenko wrote:

Olaf Kasten wrote:

 Hi there,

I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't  connect to the elog server with ssl = 1 in elogd.cfg. 

I tested with Firefox 3.6 and IE 7 installations and there are no problems.

I guess it's a bug. Does someone have a suggestion to solve that problem?

Thx. Olaf

 Hi!

This just started happening here also.  Some users can't get on to a SSL=1 config'd elog using either IE or firefox 10 (win7 or linux) or chrome.  SAFARI works.  Occurs in 2.8.0 and a newly built (even after

ssl yum updates) 2.9.0 version on SL5.5 system.  Seems to accept self signed cert then nothing.. (connection reset message).   Tried an stunnel from one port to port running elog

with SSL=0.  Same behavior.  Doesn't work on some browsers.  Any clues?

Thanks,

-John

Hi everyone,
it appears that many people have this problem. I believe this is simply a problem of your firewall settings. There are two simple checks you can do to test if I'm right or wrong:
  • Run your logbook on the standard port 443 and retry. If the special port has been opened on the firewall, it has been likely only opened for specific clients like firefox 3.6, IE 7, etc. If you use a different client (FF 10, IE 9) the port can be blocked.
  • Or just run the browser that does not work on the ELOG server. If it works to access ELOG via localhost, then you know for sure that it is the firewall.
I've actually tested it here at my institute: I've downloaded firefox 10 and could access ELOG on port 443 but couldn't access it on port 444, unless I've started FF10 on the ELOG host.
To John, Olaf and Christian: If you need to be able to use a special port and a certain set of browsers then just contact your computing division or whoever maintains your firewalls.
 
I hope this settles the matter.
Cheers
Andreas
 
Detect language » English
 

PS: I've solved this with the help of google  : have a look at http://forums.mozillazine.org/viewtopic.php?p=2295421#2295421 about firewalls

 Hi all,

 

it is NOT the firewall. First off, I don't use a firewall. 2. I AM our computing division. 3. if it were the firewall blocking the access, why do I see "TCP connection broken" in the elog log file? 4. it's not working on port 443 either.

Something's flaky in elog's https implementation. For me it's not a big deal any more, as I use an apache reverse proxy in production now anyway, but other people may not.

 

thanks,

-Christian

             icon2.gif   Re: ssl problems, posted by Andreas Luedeke on Sat Feb 11 22:19:07 2012 

Christian Herzog wrote:

Andreas Luedeke wrote:

 
[...]

Hi everyone,
it appears that many people have this problem. I believe this is simply a problem of your firewall settings. There are two simple checks you can do to test if I'm right or wrong:
  • Run your logbook on the standard port 443 and retry. If the special port has been opened on the firewall, it has been likely only opened for specific clients like firefox 3.6, IE 7, etc. If you use a different client (FF 10, IE 9) the port can be blocked.
  • Or just run the browser that does not work on the ELOG server. If it works to access ELOG via localhost, then you know for sure that it is the firewall.
I've actually tested it here at my institute: I've downloaded firefox 10 and could access ELOG on port 443 but couldn't access it on port 444, unless I've started FF10 on the ELOG host.
To John, Olaf and Christian: If you need to be able to use a special port and a certain set of browsers then just contact your computing division or whoever maintains your firewalls.
[...]

[...] it is NOT the firewall. First off, I don't use a firewall. 2. I AM our computing division. 3. if it were the firewall blocking the access, why do I see "TCP connection broken" in the elog log file? 4. it's not working on port 443 either.
Something's flaky in elog's https implementation. For me it's not a big deal any more, as I use an apache reverse proxy in production now anyway, but other people may not. [...]

 
Detect language » English
 

Just for curiosity: did you try to start the non-working web-browser locally on the server?

                icon2.gif   Re: ssl problems, posted by Christian Herzog on Sat Feb 11 22:27:15 2012 
well it's not a server but my laptop, but yeah, the elog server and the browser ran on the same machine, no iptables.
                   icon2.gif   Re: ssl problems, posted by Andreas Luedeke on Sat Feb 11 22:37:34 2012 
> well it's not a server but my laptop, but yeah, the elog server and the browser ran on the same machine, no iptables.

Strange: I thought I was able to reproduce your problem, but no: whatever browser I try I can access ELOG with SSL if
browser and ELOG are running on the same host. Same as you: clean install but no problem occurs. I haven't tried on a
newer operating system yet. Still I tend to believe that it would not reproduce your problem. Maybe I'll try at home
with ubuntu. Let's first wait what the other two report: if those problems are not related to firewall issues, Stefan
will likely see into it anyway.
                      icon2.gif   Re: ssl problems, posted by Olaf Kasten on Mon Feb 13 21:44:05 2012 
> > well it's not a server but my laptop, but yeah, the elog server and the browser ran on the same machine, no iptables.
> 
> Strange: I thought I was able to reproduce your problem, but no: whatever browser I try I can access ELOG with SSL if
> browser and ELOG are running on the same host. Same as you: clean install but no problem occurs. I haven't tried on a
> newer operating system yet. Still I tend to believe that it would not reproduce your problem. Maybe I'll try at home
> with ubuntu. Let's first wait what the other two report: if those problems are not related to firewall issues, Stefan
> will likely see into it anyway.

Well, it's definitely not a firewall problem. I tried it on hosts in different networks and of course in the same subnet as 
the elog server. As I wrote I tried it with different browsers on different OS and everywhere I had same issues if I used 
newer browsers. So I guess there are interoperability problems between elog and newer browsers.

And by the way if I change ssl = 1 to ssl = 0 there are no problems with any browsers.

But I want to use the ssl feature because security reasons.

Hope Stefan could locate and fix the problem.

Thx
          icon2.gif   Re: ssl problems, posted by John Doroshenko on Tue Feb 14 00:55:58 2012 

Andreas Luedeke wrote:

John Doroshenko wrote:

Olaf Kasten wrote:

 Hi there,

I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't  connect to the elog server with ssl = 1 in elogd.cfg. 

I tested with Firefox 3.6 and IE 7 installations and there are no problems.

I guess it's a bug. Does someone have a suggestion to solve that problem?

Thx. Olaf

 Hi!

This just started happening here also.  Some users can't get on to a SSL=1 config'd elog using either IE or firefox 10 (win7 or linux) or chrome.  SAFARI works.  Occurs in 2.8.0 and a newly built (even after

ssl yum updates) 2.9.0 version on SL5.5 system.  Seems to accept self signed cert then nothing.. (connection reset message).   Tried an stunnel from one port to port running elog

with SSL=0.  Same behavior.  Doesn't work on some browsers.  Any clues?

Thanks,

-John

Hi everyone,
it appears that many people have this problem. I believe this is simply a problem of your firewall settings. There are two simple checks you can do to test if I'm right or wrong:
  • Run your logbook on the standard port 443 and retry. If the special port has been opened on the firewall, it has been likely only opened for specific clients like firefox 3.6, IE 7, etc. If you use a different client (FF 10, IE 9) the port can be blocked.
  • Or just run the browser that does not work on the ELOG server. If it works to access ELOG via localhost, then you know for sure that it is the firewall.
I've actually tested it here at my institute: I've downloaded firefox 10 and could access ELOG on port 443 but couldn't access it on port 444, unless I've started FF10 on the ELOG host.
To John, Olaf and Christian: If you need to be able to use a special port and a certain set of browsers then just contact your computing division or whoever maintains your firewalls.
 
I hope this settles the matter.
Cheers
Andreas
 
Detect language » English
 

PS: I've solved this with the help of google  : have a look at http://forums.mozillazine.org/viewtopic.php?p=2295421#2295421 about firewalls

 Hi,

Thanks for the reply. 

The elog server is running SL5.5 (updates applied).  As you suggested, I ran firefox 3.6.26 on the elog server via https://localhost:port and it worked fine.   Downloaded firefox 10.0.1 and retried

on elog server and get error again:  The connection was Reset; The connection to the server was reset while the page was loading.

-John

 

             icon2.gif   Re: ssl problems, posted by Andreas Luedeke on Tue Feb 14 14:54:06 2012 

John Doroshenko wrote:

 

[...] The elog server is running SL5.5 (updates applied).  As you suggested, I ran firefox 3.6.26 on the elog server via https://localhost:port and it worked fine.   Downloaded firefox 10.0.1 and retried

on elog server and get error again:  The connection was Reset; The connection to the server was reset while the page was loading.

-John

Finally I was able to reproduce the problem. I don't know why FF10 worked locally on the ELOG host last weekend, maybe I shouldn't have worked on it during a night shift. I can now confirm that ELOG has problems with firefox 10.0.1.

For those who need a quick workaround: you can set-up apache to access elog via a reverse proxy (like I do and like Stefan does for the ELOG forum does). That 'll work fine with new browsers like FF10.0.1 (at least for apache 2.2) ;-)

Some guidance how to set it up can be found here: https://midas.psi.ch/elogs/Contributions/11

A shorter (but may be incomplete) summary:

  • add in httpd.conf
    • Listen 443
      LoadModule proxy_module modules/mod_proxy.so
    • ServerName <fully-qualified-host-name>
    •  
  • add in ssl.conf
    • <VirtualHost _default_:443>

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
SSLEngine on
SSLProxyEngine on
ProxyPreserveHost On
<Location />
    ProxyPass         https://<fully-qualified-host-name>:444/
    ProxyPassReverse  https://<fully-qualified-host-name>:444/
    SSLRequireSSL
</Location>
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLProxyCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "<cert-file>"
SSLCertificateKeyFile "<cert-key-file>"
</VirtualHost> 

  • And in the ELOG configuration [global] section
    •  port = 444
    • URL = https://<fully-qualified-host-name>                 

Cheers

Andreas

 
Detect language » English
 
                icon2.gif   Re: ssl problems, posted by Diego on Tue Feb 14 17:17:44 2012 

Andreas Luedeke wrote:

John Doroshenko wrote:

 

[...] The elog server is running SL5.5 (updates applied).  As you suggested, I ran firefox 3.6.26 on the elog server via https://localhost:port and it worked fine.   Downloaded firefox 10.0.1 and retried

on elog server and get error again:  The connection was Reset; The connection to the server was reset while the page was loading.

-John

Finally I was able to reproduce the problem. I don't know why FF10 worked locally on the ELOG host last weekend, maybe I shouldn't have worked on it during a night shift. I can now confirm that ELOG has problems with firefox 10.0.1.

For those who need a quick workaround: you can set-up apache to access elog via a reverse proxy (like I do and like Stefan does for the ELOG forum does). That 'll work fine with new browsers like FF10.0.1 (at least for apache 2.2) ;-)

Some guidance how to set it up can be found here: https://midas.psi.ch/elogs/Contributions/11

A shorter (but may be incomplete) summary:

  • add in httpd.conf
    • Listen 443
      LoadModule proxy_module modules/mod_proxy.so
    • ServerName <fully-qualified-host-name>
    •  
  • add in ssl.conf
    • <VirtualHost _default_:443>

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
SSLEngine on
SSLProxyEngine on
ProxyPreserveHost On
<Location />
    ProxyPass         https://<fully-qualified-host-name>:444/
    ProxyPassReverse  https://<fully-qualified-host-name>:444/
    SSLRequireSSL
</Location>
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLProxyCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile "<cert-file>"
SSLCertificateKeyFile "<cert-key-file>"
</VirtualHost> 

  • And in the ELOG configuration [global] section
    •  port = 444
    • URL = https://<fully-qualified-host-name>                 

Cheers

Andreas

 
Detect language » English
 

 With Chrome 17 there is the same problem. 

Is not possible a quick workaround for windows 7 users that we do not use apache server?

Thank you so much!!

Diego

 

 

 

 

             icon2.gif   Re: ssl problems, posted by John Doroshenko on Tue Feb 14 20:41:08 2012 fire10elog.patch

John Doroshenko wrote:

Andreas Luedeke wrote:

John Doroshenko wrote:

Olaf Kasten wrote:

 Hi there,

I have a connection problem with an actual elog installation. Many Browsers like as Chrome, Firefox and IE don't  connect to the elog server with ssl = 1 in elogd.cfg. 

I tested with Firefox 3.6 and IE 7 installations and there are no problems.

I guess it's a bug. Does someone have a suggestion to solve that problem?

Thx. Olaf

 Hi!

This just started happening here also.  Some users can't get on to a SSL=1 config'd elog using either IE or firefox 10 (win7 or linux) or chrome.  SAFARI works.  Occurs in 2.8.0 and a newly built (even after

ssl yum updates) 2.9.0 version on SL5.5 system.  Seems to accept self signed cert then nothing.. (connection reset message).   Tried an stunnel from one port to port running elog

with SSL=0.  Same behavior.  Doesn't work on some browsers.  Any clues?

Thanks,

-John

Hi everyone,
it appears that many people have this problem. I believe this is simply a problem of your firewall settings. There are two simple checks you can do to test if I'm right or wrong:
  • Run your logbook on the standard port 443 and retry. If the special port has been opened on the firewall, it has been likely only opened for specific clients like firefox 3.6, IE 7, etc. If you use a different client (FF 10, IE 9) the port can be blocked.
  • Or just run the browser that does not work on the ELOG server. If it works to access ELOG via localhost, then you know for sure that it is the firewall.
I've actually tested it here at my institute: I've downloaded firefox 10 and could access ELOG on port 443 but couldn't access it on port 444, unless I've started FF10 on the ELOG host.
To John, Olaf and Christian: If you need to be able to use a special port and a certain set of browsers then just contact your computing division or whoever maintains your firewalls.
 
I hope this settles the matter.
Cheers
Andreas
 
Detect language » English
 

PS: I've solved this with the help of google  : have a look at http://forums.mozillazine.org/viewtopic.php?p=2295421#2295421 about firewalls

 Hi,

Thanks for the reply. 

The elog server is running SL5.5 (updates applied).  As you suggested, I ran firefox 3.6.26 on the elog server via https://localhost:port and it worked fine.   Downloaded firefox 10.0.1 and retried

on elog server and get error again:  The connection was Reset; The connection to the server was reset while the page was loading.

-John

 

 Hi,

One of our sys admins discovered that Firefox 10 appeared to send parts of the initial GET in two parts.  As if there was a flush() after the "G" and this caused elog problems.  By making the change in

the patch below, the read loop is re-entered again after the 2nd part of the GET comes in.   Firefox 10.0.1 then works with ELOG with SSL.   Stefan... perhaps you can take a look to see if there is a

better way to accomplish this? 

One side effect with it done this way is that if you start a connection (ie, telnet localhost port) and type a single character,  the elog will block further connections until the telnet is terminated.

Thank you,

-John Doroshenko

                icon2.gif   Re: ssl problems, posted by Stefan Ritt on Thu Feb 16 18:10:33 2012 

Yes, there is a new feature called record splitting which causes the browser to send the "G" of the "GET ..." in a dedicated TCP package. This started in FF10, Chrome 17, and it will come in others as well. It only affects direct SSL connections (SSL=1). I fixed the bug in SVN revision #2435. Please update also MXML to revision #73. Let's hope that surprises like that will not happen too often.

- Stefan
 

                   icon2.gif   Re: ssl problems, posted by John Doroshenko on Thu Feb 16 23:56:35 2012 

Stefan Ritt wrote:

Yes, there is a new feature called record splitting which causes the browser to send the "G" of the "GET ..." in a dedicated TCP package. This started in FF10, Chrome 17, and it will come in others as well. It only affects direct SSL connections (SSL=1). I fixed the bug in SVN revision #2435. Please update also MXML to revision #73. Let's hope that surprises like that will not happen too often.

- Stefan
 

 Thank you Stefan!  I put up your new svn revision and we're back in business.  Seems to be working perfectly.

 

And thank you again for your efforts with regards to ELOG.  It is an incredibly handy tool.

 

-John

 

                   icon2.gif   Re: ssl problems, posted by Stefan Ritt on Mon Feb 20 14:53:04 2012 

Stefan Ritt wrote:

Yes, there is a new feature called record splitting which causes the browser to send the "G" of the "GET ..." in a dedicated TCP package. This started in FF10, Chrome 17, and it will come in others as well. It only affects direct SSL connections (SSL=1). I fixed the bug in SVN revision #2435. Please update also MXML to revision #73. Let's hope that surprises like that will not happen too often.

- Stefan
 

Today I released version 2.9.1 which fixes this problem.

- Stefan 

icon5.gif   elog entry in email footer?, posted by Mark Bergman on Wed Feb 15 17:17:27 2012 

On our system, elog sends email to all people associated with an entry. Often, people will respond via email, not through elog. I'm in the process of setting up a handler for the inbound email. However, I'd like to have the outbound mail from eLog include a 'footer' to each message the details where to go to respond.

For example, the footer might read:

To respond to this message, please click the following link:
<http://www.example.com/elog/General/6153>

Any suggestions for how to implement that?
 

icon5.gif   top text in new user, posted by Diego on Mon Feb 13 22:13:40 2012 

 Hi,

I am using Top text becouse I would like to have the same header in all logbooks. However it is working in the "new user registration page" and I would like to evoid it. Is that possible?

Thank you so much!!

Diego

icon4.gif   problems with https in Chrome and IE, posted by Christian Herzog on Wed Jan 25 10:07:16 2012 

 Hi,

 

we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.

Any idea?

 

thanks,

-Christian

    icon6.gif   Re: problems with https in Chrome and IE, posted by Andreas Luedeke on Wed Jan 25 10:50:43 2012 

Christian Herzog wrote:

[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...]

 
Detect language » English
 
If you want to use https you should know what a certificate is.
Certificates are used to encript the data, but at the same time they are used to identify the host.
ELOG is delivered with a self generated certificate.
This can be used to encript the data, but no certification authority knows this certificate, so nobody can guaratee that you are connected to the right host.
Most browsers will warn you, that nobody did and if you don't care you need to change the security settings of you browser to accept the connection anyway.
 
The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)
       icon2.gif   Re: problems with https in Chrome and IE, posted by Christian Herzog on Wed Jan 25 14:05:46 2012 

Andreas Luedeke wrote:

Christian Herzog wrote:

[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...]

 
Detect language » English
 
If you want to use https you should know what a certificate is.
Certificates are used to encript the data, but at the same time they are used to identify the host.
ELOG is delivered with a self generated certificate.
This can be used to encript the data, but no certification authority knows this certificate, so nobody can guaratee that you are connected to the right host.
Most browsers will warn you, that nobody did and if you don't care you need to change the security settings of you browser to accept the connection anyway.
 
The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

 

we know about certificates, thank you 

The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/

log says: TCP connection broken

 

thanks,

-Christian

          icon2.gif   Re: problems with https in Chrome and IE, posted by Andreas Luedeke on Wed Jan 25 14:48:36 2012 

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...]

 
Detect language » English
 
 
[...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]

 
Detect language » English
 
Sorry that I was mis-interpreting your question
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
  • first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
  • second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
  • third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!

 

             icon2.gif   Re: problems with https in Chrome and IE, posted by Christian Herzog on Wed Jan 25 15:08:53 2012 

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...]

 
Detect language » English
 
 
[...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]

 
Detect language » English
 
Sorry that I was mis-interpreting your question
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
  • first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
  • second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
  • third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!

 

 

thanks for the fast resonse.

1) port 433 done. No change

2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/

3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless

speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?

 

thanks,

-Christian

                icon2.gif   Re: problems with https in Chrome and IE, posted by Andreas Luedeke on Wed Jan 25 15:26:04 2012 

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...

Detect language » English
 
 [...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]

Detect language » English
 
Sorry that I was mis-interpreting your question
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
  • first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
  • second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
  • third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!

thanks for the fast resonse.
1) port 433 done. No change
2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/
3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless
speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?[...]

Okay, I did run out of ideas. I've never tested Chrome, but IE 8 and konquerer works fine here with SSL for our logbooks, but not for your logbook.

Regarding LDAP: you'll either need to convince Stefan Ritt or do it yourself ;-) Stefan did last year a kerberos binding for me: I was lucky that many other people had already asked for the same thing before me.

 
Detect language » English
 
                   icon2.gif   Re: problems with https in Chrome and IE, posted by Christian Herzog on Wed Jan 25 15:33:59 2012 

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...

Detect language » English
 
 [...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]

Detect language » English
 
Sorry that I was mis-interpreting your question
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
  • first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
  • second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
  • third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!

thanks for the fast resonse.
1) port 433 done. No change
2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/
3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless
speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?[...]

Okay, I did run out of ideas. I've never tested Chrome, but IE 8 and konquerer works fine here with SSL for our logbooks, but not for your logbook.

Regarding LDAP: you'll either need to convince Stefan Ritt or do it yourself ;-) Stefan did last year a kerberos binding for me: I was lucky that many other people had already asked for the same thing before me.

 
Detect language » English
 

 

ok thanks, I'll check the LDAP thing.

And just for the record: I have to conclude a clean install of elog 2.9.0 SSL does not work for half of the browsers out there on Debian Squeeze or Ubuntu Lucid right now. You might want to look into that.

 

thanks,

-Christian

 

                      icon2.gif   Re: problems with https in Chrome and IE, posted by Yoshio Imai on Wed Jan 25 15:40:17 2012 
Might this be related to the problem reported by Allen?
                         icon2.gif   Re: problems with https in Chrome and IE, posted by Christian Herzog on Wed Jan 25 15:42:17 2012 

[quote="Yoshio Imai"]Might this be related to the problem reported by [url=elog:67160]Allen[/url]?[/quote]

 

can't tell, but Chrome on Linux doesn't work either...

                      icon2.gif   Re: problems with https in Chrome and IE, posted by Andreas Luedeke on Wed Jan 25 16:05:13 2012 

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...

Detect language » English
 
 [...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]

Detect language » English
 
Sorry that I was mis-interpreting your question
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
  • first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
  • second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
  • third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!

thanks for the fast resonse.
1) port 433 done. No change
2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/
3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless
speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?[...]

Okay, I did run out of ideas. I've never tested Chrome, but IE 8 and konquerer works fine here with SSL for our logbooks, but not for your logbook. [...]

 
Detect language » English
 

[...]

And just for the record: I have to conclude a clean install of elog 2.9.0 SSL does not work for half of the browsers out there on Debian Squeeze or Ubuntu Lucid right now. You might want to look into that.

thanks,

-Christian

 

Excuse me, but I beg to differ. I'm running ELOG V2.9.0-2425 on my production server, therefore I thought that you're maybe right that the latest SVN snapshot has a problem.

I've downloaded it just now from SVN (it is V2.9.0- 2427), compiled it on SL 5.7, installed it and I can easily access it with IE8, Safari, konquerer and firefox.

 
Detect language » English
 
                         icon2.gif   Re: problems with https in Chrome and IE, posted by Christian Herzog on Wed Jan 25 16:13:22 2012 

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...

Detect language » English
 
 [...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]

Detect language » English
 
Sorry that I was mis-interpreting your question
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
  • first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
  • second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
  • third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!

thanks for the fast resonse.
1) port 433 done. No change
2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/
3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless
speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?[...]

Okay, I did run out of ideas. I've never tested Chrome, but IE 8 and konquerer works fine here with SSL for our logbooks, but not for your logbook. [...]

 
Detect language » English
 

[...]

And just for the record: I have to conclude a clean install of elog 2.9.0 SSL does not work for half of the browsers out there on Debian Squeeze or Ubuntu Lucid right now. You might want to look into that.

thanks,

-Christian

 

Excuse me, but I beg to differ. I'm running ELOG V2.9.0-2425 on my production server, therefore I thought that you're maybe right that the latest SVN snapshot has a problem.

I've downloaded it just now from SVN (it is V2.9.0- 2427), compiled it on SL 5.7, installed it and I can easily access it with IE8, Safari, konquerer and firefox.

 
Detect language » English
 

 well maybe SL 5.7 is the explanation - it's old as the hills. Maybe newer versions of libssl or whatever make a difference? I might also try on a recent Fedora, let's see..

 

                            icon2.gif   Re: problems with https in Chrome and IE, posted by Christian Herzog on Wed Jan 25 19:47:38 2012 

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...

Detect language » English
 
 [...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]

Detect language » English
 
Sorry that I was mis-interpreting your question
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
  • first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
  • second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
  • third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!

thanks for the fast resonse.
1) port 433 done. No change
2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/
3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless
speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?[...]

Okay, I did run out of ideas. I've never tested Chrome, but IE 8 and konquerer works fine here with SSL for our logbooks, but not for your logbook. [...]

 
Detect language » English
 

[...]

And just for the record: I have to conclude a clean install of elog 2.9.0 SSL does not work for half of the browsers out there on Debian Squeeze or Ubuntu Lucid right now. You might want to look into that.

thanks,

-Christian

 

Excuse me, but I beg to differ. I'm running ELOG V2.9.0-2425 on my production server, therefore I thought that you're maybe right that the latest SVN snapshot has a problem.

I've downloaded it just now from SVN (it is V2.9.0- 2427), compiled it on SL 5.7, installed it and I can easily access it with IE8, Safari, konquerer and firefox.

 
Detect language » English
 

 well maybe SL 5.7 is the explanation - it's old as the hills. Maybe newer versions of libssl or whatever make a difference? I might also try on a recent Fedora, let's see..

 

 update: clean install on F16, plain vanilla, same problem: TCP connection broken

                               icon2.gif   Re: problems with https in Chrome and IE, posted by Andreas Luedeke on Sat Feb 11 05:47:27 2012 

Christian Herzog wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...

Detect language » English
 
 [...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]

Detect language » English
 
Sorry that I was mis-interpreting your question
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
  • first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
  • second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
  • third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!

thanks for the fast resonse.
1) port 433 done. No change
2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/
3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless
speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?[...]

Okay, I did run out of ideas. I've never tested Chrome, but IE 8 and konquerer works fine here with SSL for our logbooks, but not for your logbook. [...]

 
Detect language » English
 

[...]

And just for the record: I have to conclude a clean install of elog 2.9.0 SSL does not work for half of the browsers out there on Debian Squeeze or Ubuntu Lucid right now. You might want to look into that.

thanks,

-Christian

 

Excuse me, but I beg to differ. I'm running ELOG V2.9.0-2425 on my production server, therefore I thought that you're maybe right that the latest SVN snapshot has a problem.

I've downloaded it just now from SVN (it is V2.9.0- 2427), compiled it on SL 5.7, installed it and I can easily access it with IE8, Safari, konquerer and firefox.

 
Detect language » English
 

 well maybe SL 5.7 is the explanation - it's old as the hills. Maybe newer versions of libssl or whatever make a difference? I might also try on a recent Fedora, let's see..

 

 update: clean install on F16, plain vanilla, same problem: TCP connection broken

See https://midas.psi.ch/elogs/Forum/67184 to fix that problem. It is likely not a problem of ELOG, but of your firewall settings.

 
Detect language » English
 
                                  icon2.gif   Re: problems with https in Chrome and IE, posted by Christian Herzog on Sat Feb 11 22:07:37 2012 

Andreas Luedeke wrote:

Christian Herzog wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...

Detect language » English
 
 [...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]

Detect language » English
 
Sorry that I was mis-interpreting your question
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
  • first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
  • second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
  • third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!

thanks for the fast resonse.
1) port 433 done. No change
2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/
3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless
speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?[...]

Okay, I did run out of ideas. I've never tested Chrome, but IE 8 and konquerer works fine here with SSL for our logbooks, but not for your logbook. [...]

 
Detect language » English
 

[...]

And just for the record: I have to conclude a clean install of elog 2.9.0 SSL does not work for half of the browsers out there on Debian Squeeze or Ubuntu Lucid right now. You might want to look into that.

thanks,

-Christian

 

Excuse me, but I beg to differ. I'm running ELOG V2.9.0-2425 on my production server, therefore I thought that you're maybe right that the latest SVN snapshot has a problem.

I've downloaded it just now from SVN (it is V2.9.0- 2427), compiled it on SL 5.7, installed it and I can easily access it with IE8, Safari, konquerer and firefox.

 
Detect language » English
 

 well maybe SL 5.7 is the explanation - it's old as the hills. Maybe newer versions of libssl or whatever make a difference? I might also try on a recent Fedora, let's see..

 

 update: clean install on F16, plain vanilla, same problem: TCP connection broken

See https://midas.psi.ch/elogs/Forum/67184 to fix that problem. It is likely not a problem of ELOG, but of your firewall settings.

 
Detect language » English
 

see #67184, I'm pretty positive it isn't.

-Christian 

                                     icon2.gif   Re: problems with https in Chrome and IE, posted by Diego on Mon Feb 13 18:36:29 2012 

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:

Andreas Luedeke wrote:

Christian Herzog wrote:
[...] we're evaluating elog right now at the Physics Department of ETH Zurich and I'm trying to come up with a good config. One of the first steps of course was to enable SSL/https. With http, all tested browsers work fine, but with https at least Google Chrome 16 and IE 9 do not get past the "unknown certificate" warning and I see "TCP connection broken" errors in the log file. Firefox however works fine. Same behavior on Linux, Mac and Windows (given the browser in question is available). elog server is running on Lucid.[...

Detect language » English
 
 [...] The proper way out of this is to buy a certificate from a certification authority. Or to switch off https. (See https://midas.psi.ch/elog/config.html#global SSL option)

we know about certificates, thank you 
The point is that it stops AFTER the point at which I tell the browser to accept the self-signed certificates. I now even got a CACert and the problem remains: FF works, Chrome and IE don't: https://phd-bkp-gw2.ethz.ch:8080/admin/
log says: TCP connection broken [...]

Detect language » English
 
Sorry that I was mis-interpreting your question
Unfortunately I don't know what's wrong with your set-up. I can confirm that I cannot access your logbook with "konquerer", but can access it with "firefox". The "konquerer" (on Scientific Linux 5.7) just gets timed out.
But I can access other SSL/https ELOGs with the konquerer. The problem only occurs with your logbook!
Therefore I would think it is a particular problem of your installation. I have three ideas how to isolate the problem:
  • first, I would try to change to the standard port 443. Just in case it is related to some firewall, etc. problem.
  • second, I would try another operating system than Ubuntu Lucid. It should work of course with Ubuntu, but if it still doesn't work with the other operating system then many things are already ruled out.
  • third, I would try to set-up an apache webserver in front of ELOG. We have it here just for safety reasons. ELOG runs then on some special port and apache connects to it with a reverse proxy.
The latter is a little bit of work (about a day) if you never set-up apache before. Therefore I would try the other two, first.
Good luck!

thanks for the fast resonse.
1) port 433 done. No change
2) compiled elog 2.9.0 on Squeeze and only reused the config file. No change: https://daduke.org:8443/
3) we can do that (and we will) no problem, but I'd like to get it working w/o apache nonetheless
speaking of reverse proxy: we'd like to hook elog to our LDAP server. As there's no LDAP binding built in, is there any way to use apache LDAP auth and then bind to that one?[...]

Okay, I did run out of ideas. I've never tested Chrome, but IE 8 and konquerer works fine here with SSL for our logbooks, but not for your logbook. [...]

 
Detect language » English
 

[...]

And just for the record: I have to conclude a clean install of elog 2.9.0 SSL does not work for half of the browsers out there on Debian Squeeze or Ubuntu Lucid right now. You might want to look into that.

thanks,

-Christian

 

Excuse me, but I beg to differ. I'm running ELOG V2.9.0-2425 on my production server, therefore I thought that you're maybe right that the latest SVN snapshot has a problem.

I've downloaded it just now from SVN (it is V2.9.0- 2427), compiled it on SL 5.7, installed it and I can easily access it with IE8, Safari, konquerer and firefox.

 
Detect language » English
 

 well maybe SL 5.7 is the explanation - it's old as the hills. Maybe newer versions of libssl or whatever make a difference? I might also try on a recent Fedora, let's see..

 

 update: clean install on F16, plain vanilla, same problem: TCP connection broken

See https://midas.psi.ch/elogs/Forum/67184 to fix that problem. It is likely not a problem of ELOG, but of your firewall settings.

 
Detect language » English
 

see #67184, I'm pretty positive it isn't.

-Christian 

 Hi,

I have the same problem. with SSL = 1 in elog.cfg I am not able to connect using firefox 10 or chrome. However, using Internet explorer 6.0 it works fine.

Everything it has been checked in a local machine with windows 7 with and without firewall. 

Use port 443, works fine with all browser.

Thank you so much!

Diego

icon3.gif   el cheapo LDAP binding, posted by Christian Herzog on Fri Jan 27 14:05:09 2012 

Hi all,

 

we would like to hook elog to our LDAP server. Instead of writing a full-featured LDAP auth module for elog, I have the following idea: use Apache's LDAP module to require LDAP auth for a single logbook:

 

 <Location /elog/admin>

        Use PhysLDAP

        Use RequirePhysLDAPGroup isg


        RewriteEngine On

        RewriteCond %{LA-U:REMOTE_USER} (.+)

        RewriteRule . - [E=RU:%1]

        RequestHeader add X-Forwarded-User %{RU}e

</Location>
the two Use statements are Apache macros that define our LDAP settings. The last 4 lines are necessary for Apache to pass on the logged in user to the proxied elog (ends up in ENV X-Forwarded-User).
In elogd.c, I added 
 
   /* extract REMOTE_USER */

   if ((p = strstr(request, "X-Forwarded-User:")) != NULL) {

      p += 17;

      while (*p && *p == ' ')

         p++;

      strlcpy(remote_user, p, sizeof(remote_user));

      if (strchr(remote_user, '\r'))

         *strchr(remote_user, '\r') = 0;


         char sid[32];

         /* get a new session ID */

         sid_new(NULL, remote_user, (char *) inet_ntoa(rem_addr), sid);


         /* set SID cookie */

         set_sid_cookie(NULL, sid);

         // TODO: set lbs!

   }


to process_http_request in order to extract the LDAP login. I have managed to populate the author field with remote_user, but what I'd really like is to write a cookie containing this login name so that session handling kicks in. You can see that I attempt to write a cookie, but elogd segfaults at set_sid_cookie() (gdb backtrace: 
set_cookie (lbs=0x0, name=0x483b22 "sid", value=0x7ffffffd7590 "4831386B7B333A99", global=0, expiration=0x7ffffffd7300 "")
 
Would anyone be willing to help me with this? I'm not at all familiar with the program flow in elogd and my C is a bit rusty...
 
thanks,
-Christian
 
--
Dr. Christian Herzog <herzog@phys.ethz.ch>  support: +41 44 633 26 68
IT Services Group, HPT H 8                    voice: +41 44 633 39 50
Department of Physics, ETH Zurich
8093 Zurich, Switzerland                     http://nic.phys.ethz.ch/
 
 
    icon2.gif   Re: el cheapo LDAP binding, posted by Christof Hanke on Mon Jan 30 09:31:51 2012 elogd-addwebserverauth.patch

Hi Christian,

 I have also the need to do auth on the webserver, but  I tried to integrate it into elogd as far as I could.

However, I do not try to set a special cookie to set the username, but always use 
 "X-Forwarded-User".  Like this, every request is authenticated by the webserver in front.

If that's not too heavy for you, try out the applied patch.

 

HTH,

Christof

PS:

 

@Stefan:

If you are willing to integrate this into the official tree, 

I can provide some docs for it (like setting author 

directly etc.)

-----------------------------------------------------------------
Christof Hanke e-mail hanke@rzg.mpg.de
RZG (Rechenzentrum Garching) phone +49-89-3299-1041
Computing Center of the Max-Planck-Gesellschaft (MPG) and the
Institut für Plasmaphysik (IPP)
 

 

Christian Herzog wrote:

Hi all,

 

we would like to hook elog to our LDAP server. Instead of writing a full-featured LDAP auth module for elog, I have the following idea: use Apache's LDAP module to require LDAP auth for a single logbook: 

 

 <Location /elog/admin>

        Use PhysLDAP

        Use RequirePhysLDAPGroup isg


        RewriteEngine On

        RewriteCond %{LA-U:REMOTE_USER} (.+)

        RewriteRule . - [E=RU:%1]

        RequestHeader add X-Forwarded-User %{RU}e

</Location>
the two Use statements are Apache macros that define our LDAP settings. The last 4 lines are necessary for Apache to pass on the logged in user to the proxied elog (ends up in ENV X-Forwarded- User).
In elogd.c, I added 
 
   /* extract REMOTE_USER */

   if ((p = strstr(request, "X-Forwarded-User:")) != NULL) {

      p += 17;

      while (*p && *p == ' ')

         p++;

      strlcpy(remote_user, p, sizeof(remote_user));

      if (strchr(remote_user, '\r'))

         *strchr(remote_user, '\r') = 0;


         char sid[32];

         /* get a new session ID */

         sid_new(NULL, remote_user, (char *) inet_ntoa(rem_addr), sid);


         /* set SID cookie */

         set_sid_cookie(NULL, sid);

         // TODO: set lbs!

   }


to process_http_request in order to extract the LDAP login. I have managed to populate the author field with remote_user, but what I'd really like is to write a cookie containing this login name so that session handling kicks in. You can see that I attempt to write a cookie, but elogd segfaults at set_sid_cookie() (gdb backtrace: 
set_cookie (lbs=0x0, name=0x483b22 "sid", value=0x7ffffffd7590 "4831386B7B333A99", 
global=0, expiration=0x7ffffffd7300 "")
 
Would anyone be willing to help me with this? I'm not at all familiar with the program flow in elogd and my C is a bit rusty...
 
thanks,
-Christian
 
--
Dr. Christian Herzog <herzog@phys.ethz.ch>  support: +41 44 633 26 68
IT Services Group, HPT H 8                    voice: +41 44 633 39 50
Department of Physics, ETH Zurich
8093 Zurich, Switzerland                     http://nic.phys.ethz.ch/
 
 

 

 

       icon2.gif   Re: el cheapo LDAP binding, posted by Christian Herzog on Fri Feb 3 09:30:20 2012 

Hi Christof,

 

wow thanks, that's (almost) exactly what I was looking for! I only had to add

 

 --- src/elogd.c.orig 2012-02-03 09:11:42.000000000 +0100
+++ src/elogd.c 2012-02-03 09:11:32.000000000 +0100
@@ -8375,6 +8375,10 @@
    strcpy(list[i], "remote_host");
    strlcpy(value[i++], rem_host, NAME_LENGTH);

+   /* add LDAP author */
+   strcpy(list[i], "http_user");
+   strlcpy(value[i++], http_user, NAME_LENGTH);
+

    /* add local host */
    strcpy(list[i], "host");
    strlcpy(value[i++], host_name, NAME_LENGTH);
 
in order to get
 

Preset Author = $http_user

to work.  I fully support getting your patches into upstream.

 

thanks a bunch,
-Christian
 

 

icon5.gif   Migrate to elog, posted by Kenneth Nielsen on Thu Feb 2 16:51:32 2012 

Hallo and thanks for a great program.

At my work we have previously been using another program (Rednotebook) for our lab journals, but now we wish to migrate to elog because it is more configurable and because it runs in a browser.

We would off course like to move all of our old log entries with us. Luckily Rednotebook uses a standard module (YAML) for data storage, so I can easily access the data (e.g. with python) and I have already done do, and I have exchanged the native markup with html.

Now I would prefer it if I can make the elog data files directly, in stead of using the elog command, because that makes it possible and easy to revert the change, and also to not have to handle escaping html string before feeding them to elog on the commandline. I have actually already written the program that produces the elog data files, but now I have a few questions:

1) Is there an overall way of validating the datafiles, to make sure elog doesn't choke on them at some point in the future when I try to open one of the old entries. Along the same lines, does elog parse all the files when the demon is started, so if it starts then I'm ok?

2) What exactly are the requirements for the HTML content

2a) Will any valid html do, or are there some speciel requirements (e.g. like &nbsp; at blank lines)

2b) Does it require a particular version of html, because then I could at least validate it against that doctype beforehand

3) Is there a log from elog where I can see if it encounters something it doesn't like?

I hope the you can answer some of my questions.

Regards Kenneth

icon5.gif   Return Code, posted by Alan Grant on Fri Jan 27 02:26:02 2012 

We are using the Elog client from one vlan to insert entries into our Elog system on a different vlan.

Works fine for the most part but we occasionally have network connection issues which prevents some entries from being added, and we don't find out about it until later.

Is there a Return Code associated with the client pgm? Or some suggestion to promptly verify a successful enrty? (We'd queue and resubmit in bulk once running again, if we knew about it.)

Thanks.

    icon2.gif   Re: Return Code, posted by Yoshio Imai on Mon Jan 30 18:23:39 2012 

It depends on how you actually call the elog client, but it outputs a message

 Message successfully transmitted, ID=(new message id)

to the console upon successful transmission. Maybe you can catch this and evaluate?

ELOG V3.1.5-3fb85fa6