Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 3 subscribers
  • Views 6536 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

User Portal - logging in shows blank browser

Natalie
We are having real problems on our ASG320 and access to the user portal. We are running 7.301.  It seems that every time a user tries to log in now, they get a blank screen with the top Astaro banner and a drop down for the language, and pretty much nothing else. No links. No tabs, no nothing.

I have users desperately needing to get to the VPN and they can't download the clients or certificates because the portal is flaked out.

This is the same regardless of browser or system used.  We tried Firefox 3.0.1, IE 7.0, IE 6.0 and Firefox 2.0.0.5 all with the same results.

Anyone have any ideas why this is happening or how I can fix it?

(The log files indicate that the user authenticated successfully on the portal using Radius)

I've attached a screenshot....

-Natalie


This thread was automatically locked due to age.
Parents
  • 0
    It seems that the root partition had filled up. For some reason the Webadmin was not deleting or cleaning up old log files. This is the second time we have had the root partition fill up on this system, so I'm going to be discussing this with Astaro. That simply should not happen.

    There was a whole raft of directories under:
    /var/sec/chroot-httpd/var/webadmin/var  

    With names like: jwKapGkaoEYGUAJAnprW

    under which there were several directories, and in the "download" directory of many of these generated directories, there were log files named "singlelogfile" which were several hundred megabytes each.

    Needless to say, deleting just 10 of these files cleared up 25% free disk space.

    The problem is that the webadmin httpd could not create temporary files, and so it prevented it from fully serving up the sessions for users and new admin logins alike.

    examining the HTTP Daemon log showed entries like this:

    2008:12:10-15:54:23 (none) httpd[20530]: [error] (20014)Internal error: Cannot store SSL session to DBM file `/tmp/http.ssl_scache'
    2008:12:10-15:54:23 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:23 -0500] "GET /jape/img/tr.gif HTTP/1.1" 304 -
    2008:12:10-15:54:23 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:23 -0500] "GET /jape/img/nl.gif HTTP/1.1" 304 -
    2008:12:10-15:54:23 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:23 -0500] "GET /jape/img/zh.gif HTTP/1.1" 304 -
    2008:12:10-15:54:23 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:23 -0500] "GET /eup/icons/panel_left.png HTTP/1.1" 304 -
    2008:12:10-15:54:24 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:23 -0500] "POST /index.plx HTTP/1.1" 200 386
    2008:12:10-15:54:24 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:24 -0500] "POST /index.plx HTTP/1.1" 200 340
    2008:12:10-15:54:24 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:24 -0500] "POST /index.plx HTTP/1.1" 200 340
    2008:12:10-15:54:24 (none) httpd[20532]: [error] (20014)Internal error: Cannot store SSL session to DBM file `/tmp/http.ssl_scache'
    2008:12:10-15:54:24 (none) httpd[20531]: [error] (20014)Internal error: Cannot store SSL session to DBM file `/tmp/http.ssl_scache'
    2008:12:10-15:54:24 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:24 -0500] "GET /eup/icons/top_right.gif HTTP/1.1" 304 -
    2008:12:10-15:54:24 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:24 -0500] "GET /eup/icons/top_gradient.gif HTTP/1.1" 304 -
    2008:12:10-15:54:25 (none) httpd[20533]: [error] (20014)Internal error: Cannot store SSL session to DBM file `/tmp/http.ssl_scache'
    2008:12:10-15:54:25 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:25 -0500] "GET /eup/icons/panel_top.png HTTP/1.1" 304 -
    2008:12:10-15:54:25 (none) httpd: 192.168.7.104 - - [10/Dec/2008:12:10-15:54:26 (none) httpd[20534]: [error] [client 127.0.0.1] access to /var/webadmin/ failed, reason: SSL connection required
    2008:12:10-15:54:26 (none) httpd: 127.0.0.1 - - [10/Dec/2008:15:54:26 -0500] "GET /" 403 - 

    After deleting the log files to free up disk space, I restarted the webadmin
     /etc/init.d/httpd restart

    And login access was restored.
Reply
  • 0
    It seems that the root partition had filled up. For some reason the Webadmin was not deleting or cleaning up old log files. This is the second time we have had the root partition fill up on this system, so I'm going to be discussing this with Astaro. That simply should not happen.

    There was a whole raft of directories under:
    /var/sec/chroot-httpd/var/webadmin/var  

    With names like: jwKapGkaoEYGUAJAnprW

    under which there were several directories, and in the "download" directory of many of these generated directories, there were log files named "singlelogfile" which were several hundred megabytes each.

    Needless to say, deleting just 10 of these files cleared up 25% free disk space.

    The problem is that the webadmin httpd could not create temporary files, and so it prevented it from fully serving up the sessions for users and new admin logins alike.

    examining the HTTP Daemon log showed entries like this:

    2008:12:10-15:54:23 (none) httpd[20530]: [error] (20014)Internal error: Cannot store SSL session to DBM file `/tmp/http.ssl_scache'
    2008:12:10-15:54:23 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:23 -0500] "GET /jape/img/tr.gif HTTP/1.1" 304 -
    2008:12:10-15:54:23 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:23 -0500] "GET /jape/img/nl.gif HTTP/1.1" 304 -
    2008:12:10-15:54:23 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:23 -0500] "GET /jape/img/zh.gif HTTP/1.1" 304 -
    2008:12:10-15:54:23 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:23 -0500] "GET /eup/icons/panel_left.png HTTP/1.1" 304 -
    2008:12:10-15:54:24 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:23 -0500] "POST /index.plx HTTP/1.1" 200 386
    2008:12:10-15:54:24 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:24 -0500] "POST /index.plx HTTP/1.1" 200 340
    2008:12:10-15:54:24 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:24 -0500] "POST /index.plx HTTP/1.1" 200 340
    2008:12:10-15:54:24 (none) httpd[20532]: [error] (20014)Internal error: Cannot store SSL session to DBM file `/tmp/http.ssl_scache'
    2008:12:10-15:54:24 (none) httpd[20531]: [error] (20014)Internal error: Cannot store SSL session to DBM file `/tmp/http.ssl_scache'
    2008:12:10-15:54:24 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:24 -0500] "GET /eup/icons/top_right.gif HTTP/1.1" 304 -
    2008:12:10-15:54:24 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:24 -0500] "GET /eup/icons/top_gradient.gif HTTP/1.1" 304 -
    2008:12:10-15:54:25 (none) httpd[20533]: [error] (20014)Internal error: Cannot store SSL session to DBM file `/tmp/http.ssl_scache'
    2008:12:10-15:54:25 (none) httpd: 192.168.7.104 - - [10/Dec/2008:15:54:25 -0500] "GET /eup/icons/panel_top.png HTTP/1.1" 304 -
    2008:12:10-15:54:25 (none) httpd: 192.168.7.104 - - [10/Dec/2008:12:10-15:54:26 (none) httpd[20534]: [error] [client 127.0.0.1] access to /var/webadmin/ failed, reason: SSL connection required
    2008:12:10-15:54:26 (none) httpd: 127.0.0.1 - - [10/Dec/2008:15:54:26 -0500] "GET /" 403 - 

    After deleting the log files to free up disk space, I restarted the webadmin
     /etc/init.d/httpd restart

    And login access was restored.
Children
  • 0 in reply to Natalie
    You may want to up2date to 7.305 ... I know they fixed some disk space issues in releases after 7.300.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

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

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Unfiltered HTML