Upgrade issue: multi-user configs don't override generic config

[dsouvik215]

Hello folks,

I installed and configured rutorrent in February and got everything working the way I liked: three users authenticate via standard apache auth, everything's encrypted via HTTPS, etc.

I just upgraded things yesterday to the latest SVN builds, and have noticed a problem with the multiuser configuration: it seems that my user's conf/users/username/config.php files are not overriding the default conf/config.php file.

I have modified the conf/config.php file to point to non-existant $scgi_ports and XmlRPCMountPoints. I have done this because not all users in my apache AuthFile should have access to rutorrent. RUTorrent shares the same AuthFile as another apache site.
For each rutorrent user, I create their /conf/users/username folder and customize the config.php file there to point to a correct port and RPC mount.
In rutorrent 3.0 this worked perfectly. Non-users would authenticate and be greeted with a blank rutorrent screen (is rtorrent running? check your scgi_port! error messages successfully appeared)
The moment I tried to log in with a valid user/pass, rutorrent would correctly read that user's customized config.php file and rutorrent would properly connect to that user's rtorrent process.
Easy peasy.

Unfortunately that is no longer the case with rutorrent 3.1.
My user's customized conf/users/username/config.php file has the correct scgi_port and mountpoints, but they don't work when I authenticate with rutorrent. I get a "is rtorrent running? check scgi ports" error message.
When I edit the DEFAULT conf/config.php to match the values for my user's config.php, my user works correctly and rutorrent connects to rtorrent.

These results seem to suggest that rutorrent is ignoring my user's customized config.php.

I have gone over each file in the /conf section and the /share sections and compared permissions with my old install. (I copied the old install of rutorrent to another location so I could compare perms and make sure everything was set up correctly). The user:groups are the same, and the UGO/RWX permissions are also identical.

Based on these symptoms, can you guys think of possibilities that may have escaped me? Why would rutorrent be ignoring my user's config?

Thanks for any help you can provide!

EDIT: New info related to another issue. I've posted it here: http://forums.rutorrent.org/index.php?topic=342.0
Mods, feel free to join my topics if necessary. Sorry for multi-posting, I was under the impression it was two separate issues...

 

[das329717]

the problem is likely that your old user config.php needs to be deleted and replaced with a new one with the new settings.

 

[dsouvik215]

I thought about this too, and did this. I noticed only one difference in the file: an addition of a new path variable in the paths array.

I replaced my user's 3 config files (access.ini, plugins.ini, and config.php) then re-customized the port/path/etc variables as necessary and then restarted httpd and rtorrent.

This had no effect on my symptoms: rutorrent is still ignoring my user configuration.

Thanks for helping so far... any followup ideas?

 

[das329717]

dude, you've fucked up your config...it's as simple as that.

Do what i'm telling you, do this:

move to your user directory and do this:

mv config.php config.php-old


then copy the one from rutorrent/conf/ to your user directory, then EDIT IT


otherwise post your config file...i PROMISE you've missed something important.

 

[dsouvik215]

The symptoms do point to a messed up config, don't they...
that's why I'm so confused... I've already replaced it though and it hasn't fixed it.

Perhaps you can see the error in the file itself.
This is my user's config.php file:
Code:
<?php
// configuration parameters

// for snoopy client
@define(&#39;HTTP_USER_AGENT&#39;, &#39;Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9) Gecko/2008052906 Firefox/3.0&#39;, true);
@define(&#39;HTTP_TIME_OUT&#39;, 30, true); // in seconds
@define(&#39;HTTP_USE_GZIP&#39;, true, true);

@define(&#39;RPC_TIME_OUT&#39;, 5, true); // in seconds

@define(&#39;LOG_RPC_CALLS&#39;, false, true);
@define(&#39;LOG_RPC_FAULTS&#39;, true, true);

// for php
@define(&#39;PHP_USE_GZIP&#39;, false, true);
@define(&#39;PHP_GZIP_LEVEL&#39;, 2, true);

$do_diagnostic = true;
$log_file = &#39;/tmp/errors.log&#39;; // path to log file (comment or make empty to disable logging)
$saveUploadedTorrents = true;

$topDirectory = &#39;/&#39;; // Upper available directory. Absolute path with trail slash.
$forbidUserSettings = false;

$scgi_port = 5000;
$scgi_host = "127.0.0.1";

$XMLRPCMountPoint = "/RPC2"; // DO NOT DELETE THIS LINE!!! DO NOT COMMENT THIS LINE!!!

$pathToExternals = array(
"php" => &#39;&#39;, // Something like /usr/bin/php. If empty, will be founded in PATH.
"curl" => &#39;&#39;, // Something like /usr/bin/curl. If empty, will be founded in PATH.
"gzip" => &#39;&#39;, // Something like /usr/bin/gzip. If empty, will be founded in PATH.
"id" => &#39;&#39;, // Something like /usr/bin/id. If empty, will be founded in PATH.
"stat" => &#39;&#39; // Something like /usr/bin/stat. If empty, will be founded in PATH.
);

// For web->rtorrent link through unix domain socket
// (scgi_local in rtorrent conf file), change variables
// above to something like this:
//
// $scgi_port = 0;
// $scgi_host = "unix:///tmp/rpc.socket";

?>

 

[das329717]

the only thing i'd do is set the correct paths to everything....but your mistake sounds like a webserver config setup problem

multi-user systems depend on some form of webserver authentication. so, if you login name is john or John or JOHN your directory in rutorrent/conf/users should be

rutorrent/conf/users/john/

and the config should be

rutorrent/conf/users/john/config.php

but you STILL need to have a config file at rutorrent/conf (i just set it up with a port not being used)

 

[dsouvik215]

Ugh that's the frustrating part!
I did *precisely* what you suggest!

My multiuser setup has worked fine for months.
Only after upgrade am I running into these oddities.

After upgrading, I knew (from reading forums and changelogs) that the config files have changed recently.

I grabbed default configs and duplicated them for me and my users.
I altered the DEFAULT config to point to a nonexistant port, as you suggested.
I altered each user's config to match the scgi ports being served by apache (which has not changed)

When I logged in - it didn't work. It took me about 45mins to isolate the problem: it was using my default config (with nonexistant port) instead of my logged-in user's config (which specified a correct port)

I guess I'll try blowing everything away and re-installing from "scratch"

Wonslung - thanks so much for trying to help me. At the very least, you've helped me be confident about how I've configured things even though I still can't get it working correctly.

 

[jith45]

1) What about errors in the web-server log?
2) Something like that may happens, if your web-server auth settings is incorrect. For example, if it ask auth for /rutorrent, but doesn't ask - for /rutorrent/php/getplugins.php. Check this.

 

[das329717]

Quote

Ugh that's the frustrating part!
I did *precisely* what you suggest!

My multiuser setup has worked fine for months.
Only after upgrade am I running into these oddities.

After upgrading, I knew (from reading forums and changelogs) that the config files have changed recently.

I grabbed default configs and duplicated them for me and my users.
I altered the DEFAULT config to point to a nonexistant port, as you suggested.
I altered each user's config to match the scgi ports being served by apache (which has not changed)

When I logged in - it didn't work. It took me about 45mins to isolate the problem: it was using my default config (with nonexistant port) instead of my logged-in user's config (which specified a correct port)

I guess I'll try blowing everything away and re-installing from "scratch"

Wonslung - thanks so much for trying to help me. At the very least, you've helped me be confident about how I've configured things even though I still can't get it working correctly.​

what you are describing makes no sense at all unless you're using a very old version of php or have screwed up your auth settings.

your rutorrent config might be correct but you've made a major mistake somewhere else because this type of error only happens due to:

Improper webserver config
Bad config information for rutorrent
Php errors


That's pretty much it....I've set up over 400 rutorrent installs so i've seen damn near every mistake possible, trust me, you are missing something important.


show your webserver logs
show your config for your webserver
show the output of "php -v"

 

[dsouvik215]

Well I've got it fixed. I don't know what the problem was, but it's gone now.

Since I never touched apache, I continued to leave that alone.
I deleted my entire rutorrent install, re-checked it out of SVN, re-exported it from my checkout, and re-set the permissions on everything.

I then created brand new configs for each of my users, customizing each appropriately as I went.
It worked first-try this time.

Thanks for helping!

 

[dsouvik215]

Wow okay - so it happened again, but this time I figured out why (or at least: the differences between when it happens and when it doesn't)

Here at work, I visit my rutorrent site with a standard url: http://sub.domain.com
My browser prompts me for a username/password, and lets me into the site, however it uses the default config.php (ie: it fails)

At home, I visit my rutorrent site with a URL that specifies the username/password: http://username[email protected]
My browser doesn't prompt me for a username/password, but lets me into the site that is customized with my user profile. (ie: all my torrents, rss feeds, and everything else loads correctly)

Here at work, I've tested firefox and safari with both user-specified and non-user-specified URLs and the symptoms seem consistent: When I don't type the usernameassword into the URL, it loads the default config. When I *DO* type the usernameassword into the URL, it loads that username's config.

Based on these results, (and based on me *never* changing my apache config for the last few months where it has worked as-expected before rutorrent upgrade, but no longer works as-expected now), this begs a question:

Has rutorrent changed the way it detects the username within the last ~200 SVN revisions?
If so, then either I have a "weird" apache user config that was acceptable in the older revisions of rutorrent,
OR I have a standard apache userconfig and rutorrent's user-detection code has a current bug in it somewhere/somehow.

Wonslung - what do you think?

 

[jith45]

See my post above, point 2.

>Has rutorrent changed the way it detects the username within the last ~200 SVN revisions?

No.

 

[das329717]

Quote

Wow okay - so it happened again, but this time I figured out why (or at least: the differences between when it happens and when it doesn't)

Here at work, I visit my rutorrent site with a standard url: http://sub.domain.com
My browser prompts me for a username/password, and lets me into the site, however it uses the default config.php (ie: it fails)

At home, I visit my rutorrent site with a URL that specifies the username/password: http://username[email protected]
My browser doesn't prompt me for a username/password, but lets me into the site that is customized with my user profile. (ie: all my torrents, rss feeds, and everything else loads correctly)

Here at work, I've tested firefox and safari with both user-specified and non-user-specified URLs and the symptoms seem consistent: When I don't type the usernameassword into the URL, it loads the default config. When I *DO* type the usernameassword into the URL, it loads that username's config.

Based on these results, (and based on me *never* changing my apache config for the last few months where it has worked as-expected before rutorrent upgrade, but no longer works as-expected now), this begs a question:

Has rutorrent changed the way it detects the username within the last ~200 SVN revisions?
If so, then either I have a "weird" apache user config that was acceptable in the older revisions of rutorrent,
OR I have a standard apache userconfig and rutorrent's user-detection code has a current bug in it somewhere/somehow.

Wonslung - what do you think?​

that is a TEXTBOOK example of bad webserver configuration.