Has anyone else had problems with the current SN code release (direct from S.net) or from git. I have a version of most of the releases running including every beta and have never had a problem in getting one up and running.
On the latest releases I do an install and everything works perfect, go to the new site, click login or and page and it just gives the page not found error
Any ideas anyone?
Purge
Comments
If it still happens can you please let me know which install profile you're using?
This seems to be a problem with htaccess, when you do a fresh install it seems to set itself as using htaccess by default.
So by adding $config['site']['fancy'] = true; to config.php and adding the htaccess everything works fine.
All the other versions prior to the ones I have problems with installed without the need for this, a fresh install would not be running thinking it had those options set.
Maybe I missed something in the install process that might have changed I should have checked. I'll run another one to see.
Anyway, it's an easy fix. :)
Purge
It works! Thank you very much!
Think I found the issue in URLMapper.
Please review and test https://gitorious.org/statusnet/mainline/merge_requests/175
Comments welcome,
Regards
JB
http://status.net/statusnet-1.0.1rc1.tar.gz
It should fix this problem.
@jbfavre @kchernenko @masha @jordanc @evan
I have the .htaccess file in place. I tried both 1.0.1rc1 and 1.0.1. I'm running under nginx on Ubuntu Natty. It doesn't seem to think that fancy URLs can work (maybe they can't; I'm really not familiar with php5-fastcgi), but I still tried turning them on. The trouble is that regardless of the fancy URL setting, the login link is to http://s.n4rky.me/main/login
I think that link requires fancy URLs to work. I get a 404. I've tried various advice I found on the web about getting fancy URLs to work, but it all seems intended for WordPress or Drupal (both of which I run, but under Apache on another server).
I'm stumped.
server {
listen 74.207.227.150:443;
listen [2001:470:8:1ae::2]:443;
server_name s.n4rky.me;
access_log /home/www/n4rky.me/logs/access.log;
error_log /home/www/n4rky.me/logs/error.log;
root /home/www/s.n4rky.me;
index index.php index.html;
fastcgi_index index.php;
location @laconica {
rewrite ^(.+)$ /index.php?p=$1 last;
}
location ~ \.php {
# Workaround PHP vulnerability:
# http://forum.nginx.org/read.php?2,88845,page=3
try_files $uri $uri/ @laconica =404;
# Alternatively you can set
# cgi.fix_pathinfo = false
# in php.ini
include /etc/nginx/fastcgi_params;
keepalive_timeout 0;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass 127.0.0.1:9000;
}
ssl on;
ssl_certificate /home/www/ssl/www.cybernude.org_publickey.pem;
ssl_certificate_key /home/www/ssl/www.cybernude.org_privatekey.pem;
ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1;
#ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
ssl_ciphers ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP;
ssl_prefer_server_ciphers on;
}
The laconica strangeness is from http://pbj.ca/FNMP-install-laconica.html
If I'm reading http://pelletiermaxime.info/2009/04/11/Laconica-On-Nginx.html correctly, it says to do essentially the same thing.
Now if I can just get logged in....
Fussing about, the relevant nginx configuration now looks like this:
server {
listen 74.207.227.150:443;
listen [2001:470:8:1ae::2]:443;
server_name s.n4rky.me;
access_log /home/www/n4rky.me/logs/access.log;
error_log /home/www/n4rky.me/logs/error.log;
root /home/www/s.n4rky.me;
index index.php index.html;
fastcgi_index index.php;
location / {
root /home/www/s.n4rky.me;
index index.php;
if (!-e $request_filename) {
rewrite ^(.*)$ /index.php?p=$1 last;
break;
}
}
location ~ \.php$ {
include /etc/nginx/fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /home/www/s.n4rky.me$fastcgi_script_name;
}
ssl on;
ssl_certificate /home/www/ssl/www.cybernude.org_publickey.pem;
ssl_certificate_key /home/www/ssl/www.cybernude.org_privatekey.pem;
ssl_session_timeout 5m;
ssl_protocols SSLv3 TLSv1;
ssl_ciphers ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP;
ssl_prefer_server_ciphers on;
}
This improves matters because it now thinks it can do fancy URLs. But whenever I click submit on a page, it just loops back to that page.
I thought I might need to re-run the installation script. So I did this. But now I can't get past a login screen or a recover password screen. Whenever I hit submit, it just loops back to the same screen.
<?php<br />if (!defined('STATUSNET') && !defined('LACONICA')) { exit(1); }
$config['site']['name'] = 's.n4rky.me';
$config['site']['server'] = 's.n4rky.me';
$config['site']['path'] = false;
$config['site']['fancy'] = true;
$config['db']['database'] = 'mysqli://statusnet:elided@localhost/statusnet';
$config['db']['type'] = 'mysql';
$config['site']['profile'] = 'public';
That doesn't allow me to do a lot of things--like administer the site or allow people to register. But it is something.
I went ahead and added the following to the above config.php output:
// Enable bidirectional Twitter bridge
//
// NOTE: if you enable this you must also set $config['avatar']['path']
//
$config['twitter']['enabled'] = true;
// Twitter integration source attribute. Note: default is StatusNet
$config['avatar']['path'] = '/home/www/s.n4rky.me/avatar';
$config['integration']['source'] = 's.n4rky.me';
$config['twitter']['consumer_secret'] = 'j4PnATFzpNVH1bji8FC1jYaqHHwU8KQWWzgZte2QQ';
$config['twitter']['consumer_key'] = 'zqgGgMXHaAs2dVP14BYIQ';
// optionally show non-local messages in public timeline
$config['public']['localonly'] = false;
$config['queue']['enabled'] = true;
$config['attachments']['dir'] = '/home/www/attachments';
And I've started the daemons:
www-data 10828 0.0 1.4 207092 21176 ? S Nov19 0:00 php /home/www/statusnet-1.0.1/scripts/queuedaemon.php
www-data 10829 0.0 1.5 207348 22240 ? S Nov19 0:00 php /home/www/statusnet-1.0.1/scripts/queuedaemon.php
www-data 10832 0.0 1.3 206064 20244 ? S Nov19 0:00 php /home/www/statusnet-1.0.1/scripts/imdaemon.php
www-data 10833 0.0 1.4 206580 21380 ? S Nov19 0:00 php /home/www/statusnet-1.0.1/scripts/imdaemon.php
www-data 10834 0.0 1.5 207348 22244 ? S Nov19 0:00 php /home/www/statusnet-1.0.1/scripts/queuedaemon.php
www-data 10835 0.0 1.5 207348 22240 ? S Nov19 0:00 php /home/www/statusnet-1.0.1/scripts/queuedaemon.php
www-data 10836 0.0 1.5 207348 22240 ? S Nov19 0:00 php /home/www/statusnet-1.0.1/scripts/queuedaemon.php
It doesn't seem like anything untoward is happening there. So I tried another browser on another operating system on another computer. But I found the same result: clicking on a submit button (like the login button) just immediately cycles back to the original screen, apparently without actually doing anything: I'm not seeing any mention of these attempts in the server logs.
So I tried configuring gwibber to access the site. It failed even to get to a login screen to authorize the account: again, no explanation in the logs.
As a matter of practice, I've been redirecting http requests to https for a while (which still doesn't eliminate man-in-the-middle attacks but I'm trying to get there). I completely forgot that StatusNet attempts to assert control over such things.
The installation worked just fine with the HTTPS everywhere and the redirect to https. And of course, initial pages worked just fine. But with an initial default setting to *never* use https, that's where things were apparently going awry.
(And, by the way, gwibber still can't authorize but I don't really care.)
Something else that might help: if you could make clear in the SSL setting that you should *not* include the https:// portion of the URL (or better yet, deal with it correctly). I had to blow away the database and reinstall to get out of that mess.
Thank you for your forbearance.
Unfortunately the support on this forum seems to have dissapeared so I would suggest you head over to identi.ca and post the URL of this thread to @evan so he can see what's going on, it will be your best bet to get this solved.
Sorry I can't help more :)
Thanks!
Purge