all passwords fail on admin login

Hi ks

Are you running any kind of cache or proxy in front of Xibo? We've seen this issue before with Alternate PHP Cache enabled. Disabling it fixes this.

Otherwise try truncating the sessions table in the database - I can tell you how to do that if you aren't sure.

Cheers

Alex

This is accessed from different places, most do not use a cache. One did (squid + privoxy), and had been working find for a couple days, but disabling that did not help either.

Clearing sessions did not help (ie. "delete from session" in mysql). I've also verified the password in the user table is correct.

In a little trial and error, I dropped the php post_max_size variable down, and that allowed me to login. In earlier trial and error troubleshooting I also determined that you can not run install.php with that set too high. And of course you can't upload many files with it set too low. Any ideas how that could be fixed? I guess our current solution will have to be: 1) set post_max_size down (eg. to 100M), 2) have all users login, 3) increase post_max_size (was using 2.5G), 4) let users do their thing, just don't let your session time out.

If it's helpful, this is xibo 1.0.1-1 from the .tar.gz, running on a debian etch server. Some software versions are below. The machine has 3.7GB ram (and almost 8GB swap space), and I don't see any signs of it running out (after increasing that to 2.5G again, I'm able to upload a large file, so php is able to get/use the memory). Any other info I could get that would be useful?

Thanks...

# dpkg --list | egrep 'php|apache2|mysql'
ii apache2 2.2.3-4+etch6 Next generation, scalable, extendable web se
ii apache2-mpm-prefork 2.2.3-4+etch6 Traditional model for Apache HTTPD 2.1
ii apache2-utils 2.2.3-4+etch6 utility programs for webservers
ii apache2.2-common 2.2.3-4+etch6 Next generation, scalable, extendable web se
ii libapache2-mod-php5 5.2.0+dfsg-8+etch15 server-side, HTML-embedded scripting languag
ii libdbd-mysql-perl 3.0008-1 A Perl5 database interface to the MySQL data
ii libmysqlclient15off 5.0.32-7etch10 mysql database client library
ii libqt3-mt-mysql 3.3.7-4etch2 MySQL database driver for Qt3 (Threaded)
ii mysql-client-5.0 5.0.32-7etch10 mysql database client binaries
ii mysql-common 5.0.32-7etch10 mysql database common files (e.g. /etc/mysql
ii mysql-server 5.0.32-7etch10 mysql database server (meta package dependin
ii mysql-server-5.0 5.0.32-7etch10 mysql database server binaries
ii php-pear 5.2.0+dfsg-8+etch15 PEAR - PHP Extension and Application Reposit
ii php5 5.2.0+dfsg-8+etch15 server-side, HTML-embedded scripting languag
ii php5-cli 5.2.0+dfsg-8+etch15 command-line interpreter for the php5 script
ii php5-common 5.2.0+dfsg-8+etch15 Common files for packages built from the php
ii php5-gd 5.2.0+dfsg-8+etch15 GD module for php5
ii php5-json 1.2.1-3.2+etch1 JSON serialiser for PHP5
ii php5-mysql 5.2.0+dfsg-8+etch15 MySQL module for php5
ii php5-sqlite 5.2.0+dfsg-8+etch15 SQLite module for php5
#

Hi

I'm running Ubuntu with max file upload set to 1gb, but haven't touched the post size variable.

Are you restarting Apache between changing variables? Just wondering if that has a bearing rather than the variable setting?

If what you say is the case then it should be pretty easy for us to replicate. Could you post the changes you made over the distributed php.ini from Debian and I'll see if I can replicate it.

Cheers

Alex

--- original message ---
From: "ks" <email address hidden>
Subject: Re: [Question #73115]: all passwords fail on admin login
Date: 3rd June 2009
Time: 10:35:54 pm

Question #73115 on Xibo changed:
https://answers.launchpad.net/xibo/+question/73115

    Status: Answered => Open

ks is still having a problem:
This is accessed from different places, most do not use a cache. One
did (squid + privoxy), and had been working find for a couple days, but
disabling that did not help either.

Clearing sessions did not help (ie. "delete from session" in mysql).
I've also verified the password in the user table is correct.

In a little trial and error, I dropped the php post_max_size variable
down, and that allowed me to login. In earlier trial and error
troubleshooting I also determined that you can not run install.php with
that set too high. And of course you can't upload many files with it
set too low. Any ideas how that could be fixed? I guess our current
solution will have to be: 1) set post_max_size down (eg. to 100M), 2)
have all users login, 3) increase post_max_size (was using 2.5G), 4) let
users do their thing, just don't let your session time out.

If it's helpful, this is xibo 1.0.1-1 from the .tar.gz, running on a
debian etch server. Some software versions are below. The machine has
3.7GB ram (and almost 8GB swap space), and I don't see any signs of it
running out (after increasing that to 2.5G again, I'm able to upload a
large file, so php is able to get/use the memory). Any other info I
could get that would be useful?

Thanks...

# dpkg --list | egrep 'php|apache2|mysql'
ii apache2 2.2.3-4+etch6 Next generation, scalable, extendable web se
ii apache2-mpm-prefork 2.2.3-4+etch6 Traditional model for Apache HTTPD 2.1
ii apache2-utils 2.2.3-4+etch6 utility programs for webservers
ii apache2.2-common 2.2.3-4+etch6 Next generation, scalable, extendable web se
ii libapache2-mod-php5 5.2.0+dfsg-8+etch15 server-side, HTML-embedded scripting languag
ii libdbd-mysql-perl 3.0008-1 A Perl5 database interface to the MySQL data
ii libmysqlclient15off 5.0.32-7etch10 mysql database client library
ii libqt3-mt-mysql 3.3.7-4etch2 MySQL database driver for Qt3 (Threaded)
ii mysql-client-5.0 5.0.32-7etch10 mysql database client binaries
ii mysql-common 5.0.32-7etch10 mysql database common files (e.g. /etc/mysql
ii mysql-server 5.0.32-7etch10 mysql database server (meta package dependin
ii mysql-server-5.0 5.0.32-7etch10 mysql database server binaries
ii php-pear 5.2.0+dfsg-8+etch15 PEAR - PHP Extension and Application Reposit
ii php5 5.2.0+dfsg-8+etch15 server-side, HTML-embedded scripting languag
ii php5-cli 5.2.0+dfsg-8+etch15 command-line interpreter for the php5 script
ii php5-common 5.2.0+dfsg-8+etch15 Common files for packages built from the php
ii php5-gd 5.2.0+dfsg-8+etch15 GD module for php5
ii php5-json 1.2.1-3.2+etch1 JSON serialiser for PHP5
ii php5-mysql 5.2.0+dfsg-8+etch15 MySQL module for php5
ii php5-sqlite 5.2.0+dfsg-8+etch15 SQLite module for php5
#

--
You received this question notification because you are a member of Xibo
Developers, which is an answer contact for Xibo.

Hello,

> Are you restarting Apache between changing variables? Just wondering if that has a
> bearing rather than the variable setting?

Yes, I changed php.ini then restarted apache.

Do you not have to increase the post size to upload large files? In testing/practice that seems to be the case for us (I have the upload filesize set higher, but it didn't allow uploading larger files till I increased the post size, which makes sense, as it uploads using an http POST).

I don't have an unmodified php.ini file handy, but these look to be the interesting settings:

max_execution_time = 90
max_input_time = 180
memory_limit = 256M
variables_order = "EGPCS"
register_globals = Off
register_long_arrays = Off
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 1.7G
magic_quotes_gpc = Off
magic_quotes_runtime = Off
enable_dl = On
file_uploads = On
upload_tmp_dir = /video/tmp
upload_max_filesize = 1.6G

Thanks for the quick response, and your assistance.

Oh, the 1.7G allows the login to work and I can upload a ~900MB file. At 2.5G, login failed.

Hi,

This is quite strange! It sounds a lot like a php / environment problem.

We store a token on the login form that must match with the token assigned
to your current session - we do this to ensure that the browser that viewed
the form is actually the one that submitted the form.

Would it be possible for you to:
 1. Get a user logged in and complete the first part of "Report Fault"
(everything before Collect and Save Data)
 2. Alter your settings
 3. Logout / Login (and see the error)
 4. Alter your settings again
 5. Complete the 2nd part of Report Fault and send the troubleshoot.txt file
to us?

We should be able to recreate this!

Cheers,
Dan

2009/6/4 ks <email address hidden>

> Question #73115 on Xibo changed:
> https://answers.launchpad.net/xibo/+question/73115
>
> ks gave more information on the question:
> Oh, the 1.7G allows the login to work and I can upload a ~900MB file.
> At 2.5G, login failed.
>
> --
> You received this question notification because you are a member of Xibo
> Developers, which is an answer contact for Xibo.
>

> We store a token on the login form that must match with the token assigned
> to your current session - we do this to ensure that the browser that viewed
> the form is actually the one that submitted the form.

When it was failing, I had checked and the token was identical to what the sessions table had (fwiw).

> Would it be possible for you to:
> 1. Get a user logged in and complete the first part of "Report Fault"
> (everything before Collect and Save Data)
> 2. Alter your settings
> 3. Logout / Login (and see the error)
> 4. Alter your settings again
> 5. Complete the 2nd part of Report Fault and send the troubleshoot.txt file
> to us?

Ok, this was logged in at post_max_size=1.7G at step 1 and 4, and 2.5G at steps 2 and 3:

http://users.kci.net/kent/xibo-troubleshoot.txt

Curious - seems that when you have post_max_size up at 2.5G you no longer get anything in the _POST variables.

From your log:
Message: <errormsg>Undefined index: token</errormsg>
Message: Form token incorrect from: 172.31.160.42 with token []

I think I may have found the answer over here: http://marc.info/?l=phpdoc&m=121614026125228&w=2 and maybe also here: http://bugs.php.net/bug.php?id=24624

I have also seen a lot of talk indicating that 2GB is the biggest it can go... ill continue to try and work this out.

Cheers,
Dan

Is there some other way to upload the files? We're just starting to set this up, and getting a few things from pegmedia.com .. but a 28 minute SD show is 1.6GB (of course depending on resolution, etc.), so I'd think that anyone paying longer content, eg. even an hour long, would have run into this. Is there anything that prevents me from just uploading a dummy file then overwriting it with the real file contents at the filesystem level? (Eg. do you store a hash of the file or anything?)

We do HASH the file so that the client can be sure it has a complete
download before it starts playing - however this is generated each time the
client requests it (a little inefficient now I come to look at it).

So your suggested solution would work.

However I feel I should say that the file sizes you are talking about here
go beyond what we have tested thus far - of course if you do hit any
additional problems we will try to resolve.

Do you have an opinion on a standalone application (maybe in .NET, maybe in
Java) that ships with the Xibo Client specifically for uploading large files
to Xibo? Its an idea I have been toying with for some time...

Cheers,
Dan

2009/6/4 ks <email address hidden>

> Question #73115 on Xibo changed:
> https://answers.launchpad.net/xibo/+question/73115
>
> Status: Answered => Open
>
> ks is still having a problem:
> Is there some other way to upload the files? We're just starting to set
> this up, and getting a few things from pegmedia.com .. but a 28 minute
> SD show is 1.6GB (of course depending on resolution, etc.), so I'd think
> that anyone paying longer content, eg. even an hour long, would have run
> into this. Is there anything that prevents me from just uploading a
> dummy file then overwriting it with the real file contents at the
> filesystem level? (Eg. do you store a hash of the file or anything?)
>
> --
> You received this question notification because you are a member of Xibo
> Developers, which is an answer contact for Xibo.
>

> Do you have an opinion on a standalone application (maybe in .NET, maybe in
> Java) that ships with the Xibo Client specifically for uploading large files
> to Xibo? Its an idea I have been toying with for some time...

I think there might be better solutions than a standalone large-file-uploader. If you were building a complete standalone admin client, that would be different and of course should handle large files.

On a trivial point, we are actually deploying the xibo client on "standalone" displays that aren't otherwise used for administration (the Asus Eee boxes are a very nice platform for that). I personally use Linux, so a .NET client would be an inconvenience (though I'm just setting this up, the folks who will use it day to day are running windows).

But since administration is web-based already, it seems that keeping it contained in the web browser would be the most convenient. On a reasonably fast network connection (relative to the size of the upload) there shouldn't be a problem on the client end with just using the browser (eg. javascript HttpRequest) to do the upload. The problem we're hitting is on the server, specifically in php, so a server-side fix would probably be more appropriate.

So .. could do a custom java (or whatever) server to catch the upload, but that's probably just 'recreating the wheel' when there are quite a few 'wheels' around to choose from already. There are a lot of web-based file managers you could consider (I'd imagine you'd find something that could ship and integrate right with the xibo server), and there's also standard WebDAV which is designed exactly for http server file access. (You'll find more searching, but one library that might work for DAV is "davclient.js" (http://debris.demon.nl/projects/davclient.js/doc/README.html).)

Thanks for the suggestions there... I have created a blueprint for this here: https://blueprints.launchpad.net/xibo/+spec/server-large-uploads

I hope the workaround proves acceptable until we can address this blueprint.

Cheers,
Dan