First off, this is not an issue with the installation, I have repeated the steps more than 10 times, the issue is with the login flow. If this is an issue is caused by configuration difference it should be handled as my installation attempts were following the instructions on a supported system.

I am installing on a Debian 4 system with Mysql 5.0.32, PHP 5.2.0 and drupal 6.9.

After an initial installation and subsequent logout of the admin user, the admin user cannot login again. In looking at the code and database contents, it appears that the user->uid value is never being set to the users uid following login attempt. In fact, I was not able to see any of the authentication/login methods actually being called from user.module. The user_is_logged_in check method was called, but nothing had been initialized with user information prior to the check.

Without the proper initialization of the user object, the sess_write method saves the session to the database with a 0 uid instead of the admin users id of 1. Thus on subsequent attempts to read the joined user + sessions table rows, the resulting row is incomplete and the user is then treated as anonymous. If I change the uid in the saved session row in the database, then I am able to operate as per normal for the duration of the session.

I don't mind debugging further, but need guidance since I am not aware of the expected flow of the methods in a successful session initiation.

Comments

jdubbwya’s picture

jdubbwya commented

One possibility that is fairly common occurrence in my experience is take a look at any custom module code and ensure there isn't a newline character after the close of the php tag, that send information to the output buffer and wreaks all kind of havoc within the system, if that still isn't the case you might need to add some stack trace checking around the following functions which actually do the user validation: user_login_name_validate, user_login_authenticate_validate, user_login_final_validate. The preceding functions are in the user.module

lonerzzz’s picture

lonerzzz commented

I am glad that I was in the correct area. I tried again with the stack trace dumps in the tops of these methods and these methods never actually get called which seemed odd to me before but I was not sure. All of the code is straight out of the 6.9 minimal tar ball. I haven't even attempted to pull any modules in.

Any other suggested areas to pursue?

jdubbwya’s picture

jdubbwya commented

Try to do a fresh install, just to ensure that the installation process wasn't interrupted. And what hosting service are you using, or are your hosting it locally, and also are you using secure connection or not?

lonerzzz’s picture

lonerzzz commented

I have performed a fresh install right from the tar ball more than ten times trying to see what might be going on. I have played with permissions, user, root path, etc, but get the same result each time. The hosting service is a virtual private server operator on the web with which I have a completely separate server on another machine that works without issue but does not have drupal installed. I am not using secure connections.

When I attempt to login as the admin user, a session is written to the db, but with a uid of 0 and I am presented with the same main page as if my login had failed. None of the user authentication methods are called, no errors are generated.

lonerzzz’s picture

lonerzzz commented
Status: Active » Closed (fixed)

I have fixed the problem. The issue was with the configuration of the Apache server. This information might be worth adding to your docs because drupal is more sensitive to bad configuration than other web applications I have installed.

If the configuration in an Apache 2 installation is not correct with respect to the naming of the sites-enabled and sites-available entries in the /etc/apache2 configuration subdirectories, the sessions become messed up and this prevents login without any errors for diagnosis.

Thus, if you are installing fresh and encountering a situation where you cannot login with your admin user, check the Apache configuration to ensure that all naming is aligned as so:

>ls /etc/apache2/sites-available
drupal
>ls -l /etc/apache2/sites-enabled
000-drupal -> /etc/apache2/sites-available/drupal
and NOT
drupal -> /etc/apache2/sites-available/drupal
OR
000-default -> /etc/apache2/sites-available/drupal

Also ensure that your apache configuration file looks something like:
NameVirtualHost *:80

ServerAdmin webmaster@

DocumentRoot /var/www/drupal

Options FollowSymLinks
AllowOverride None


Options FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all

ErrorLog /var/log/apache2/drupal_error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog /var/log/apache2/drupal_access.log combined
ServerSignature On

and your /etc/apache2/ports.conf looks as follows (at least this entry):
Listen 80