[SOLVED] Cannot login admin panel and pma

[haringstad]

After some fighting, I managed to upgrade and convert from VHCS2 to ISPCP 1.0.7. For a while, everything ran smooth, but after enabling AWStats, as mentioned here in the forum, everything works, but I cannot login to the admin panel and pma.

When I take a look at the login table in mysql, I do see that the user admin tries to login, but the login page keeps popping back. Same with the pma page.

I do think that it is rights/permissions related, but cannot find where the issue is... any help here is welcome!

Regards,

Jacco

[ephigenie]

Check the permissions of the phptmp directories - they have to be writable for the corresponding vu user ( most probably vu2000 for your panel & pma ) -> it cannot write the session data..

[haringstad]

(03-12-2012 08:08 PM)ephigenie Wrote:  Check the permissions of the phptmp directories - they have to be writable for the corresponding vu user ( most probably vu2000 for your panel & pma ) -> it cannot write the session data..

Did that already.. Keeps the same.... And the stupid thing is, nothing apears in php.log too... even I have enabled more debugging in /etc/php5/*
/php.ini to do so....

I am getting a bit annoyed now....

[ephigenie]

Ok Another reason can be mysql. Check for corrupted tables in your pma & ispcp DB.

[haringstad]

Found the problem! Memcached was corrupting stuff. So I made changes to the /etc/php5/conf.d/memcache.ini:


extension=memcache.so

[memcache]
memcache.allow_failover=0
memcache.chunk_size=32768
memcache.default_port=11211
memcache.hash_strategy=consistent
memcache.hash_function=crc32
session.save_handler=files
session.save_path="/var/lib/memcache"
memcache.protocol=ascii
memcache.redundancy=1
memcache.session_redundancy=2
memcache.compress_threshold=20000
memcache.lock_timeout=15

And it is working perfectly now! I had the memcache.ini setup earlier (when using vhcs2) for the use of Drupal, and then it was working perfect. The above is the setup I use now. Only change is: session.save_handler=files *was* session.save_handler=memcached and did not have the session.save_path="/var/lib/memcache" line.

Thank you all for thinking with me!

---

My /etc/memcached.conf:

# memcached default config file
# 2003 - Jay Bonci <jaybonci@debian.org>
# This configuration file is read by the start-memcached script provided as
# part of the Debian GNU/Linux distribution.

# Run memcached as a daemon. This command is implied, and is not needed for the
# daemon to run. See the README.Debian that comes with this package for more
# information.
-d

# Log memcached's output to /var/log/memcached
logfile /var/log/memcached

# Be verbose
-v

# Be even more verbose (print client commands as well)
# -vv

# Start with a cap of 64 megs of memory. It's reasonable, and the daemon default
# Note that the daemon will grow to this size, but does not start out holding this much
# memory
-m 1024

# Default connection port is 11211
-p 11211
-U 11211
# Run the daemon as root. The start-memcached will default to running as root if no
# -u command is present in this config file
-u nobody

# Specify which IP address to listen on. The default is to listen on all IP addresses
# This parameter is one of the only security measures that memcached has, so make sure
# it's listening on a firewalled interface.
-l 127.0.0.1

# Limit the number of simultaneous incoming connections. The daemon default is 1024
# -c 1024

# Lock down all paged memory. Consult with the README and homepage before you do this
# -k

# Return error when memory is exhausted (rather than removing items)
# -M

# Maximize core file limit
-r

-t 16

[ephigenie]

hm take care that you're not having some insecure settings in your main php.ini...

All other domains should have "normal" settings ... and use their own php.ini ...

[haringstad]

(03-14-2012 04:51 PM)ephigenie Wrote:  hm take care that you're not having some insecure settings in your main php.ini...

All other domains should have "normal" settings ... and use their own php.ini ...

Dear ephigenie,

Took care of that :-) Running debian, which has the module/dropins configured in /etc/php5/conf.d/. Those are not copied to the domains like in /var/www/fcgi/{domain}/php5/

Therefor, it took some time to find out where the issue was.... but glad I solved it and could share the cause here...

Regards,

Jacco