The problem here is that the session regeneration in PHP seems to be unstable and this instability causes the issue above. It works on most systems but on some systems it breaks the login completely and as more and more users complained that they can not login when session regeneration is on, we had to disable it until the function is stable in PHP. The issue might be a timing Issue. I will see if we can add it again but make it configurable in securty settings, so owners of systems where it does not work can disable it. The output of the sys dump is not security sensitive as the only "non stock" data that can bee seen there is the session ID which the user can see in the cookie list of his browser as well, you will always see your own ID and never the ID of another user. Off course, you should not post the ID as screenshot then
Could be, eg. with simultaneous requests (iirc, for /login/, nav.php, dashboard.php and maybe one more) all sending the old session id; the first request invalidates that session, so the subsequent requests fail. Aside from debugging session id regeneration, there are other things that could help, eg. on explicit logout, remove PHPSESSION cookie. Also could include a check for user agent in the session to assist (not prevent) hijacking (I wouldn't include the client ip address, though). Maybe check the session regeneration code at http://php.net/manual/en/function.session-regenerate-id.php#87905 (remove the check against client ip address and the nonce (or better yet, integrate it throughout ispconfig forms)). It looks like it will allow the old session id to work for up to 60 seconds after regeneration.
All thanks for your time ... i have install my cluster using 14.04 Trusty ans it is perfect ...... maybe will wait for beta version become stable then try again.