https://wiki.archlinux.org/api.php?action=feedcontributions&user=Fester&feedformat=atomArchWiki - User contributions [en]2024-03-28T23:25:08ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Rutorrent_with_lighttpd&diff=222711Rutorrent with lighttpd2012-09-12T07:16:37Z<p>Fester: /* lighttpd */</p>
<hr />
<div>[[Category:Internet Applications]]<br />
[http://code.google.com/p/rutorrent/ Rutorrent] is a php frontend to the [http://libtorrent.rakshasa.no/ rtorrent] bitorrent client.<br />
<br />
It communicates with rtorrent using XML-RPC. It requires a web server such as lighttpd or apache to serve it's pages.<br />
<br />
To set up rutorrent, we will need to have rtorrent and lighttpd set up.<br />
<br />
== rtorrent ==<br />
<br />
Install rtorrent and configure to your liking.<br />
<br />
# pacman -S rtorrent<br />
<br />
Information on configuring rtorrent can be found on it's wiki page: https://wiki.archlinux.org/index.php/Rtorrent.<br />
<br />
rtorrent in the repos should be compiled with XML-RPC support.<br />
<br />
Add the following line to your rtorrent config file, usually ~/.rtorrent.rc.<br />
<br />
scgi_port = localhost:5050<br />
<br />
Instead of using a tcp port, it is also possible to use a socket using the scgi_local option instead. This did not work for me, as lighttpd complained about permissions regardless of permissions / location of socket file.<br />
<br />
You can choose a port other than 5050 if you like.<br />
<br />
== lighttpd ==<br />
<br />
Install lighthttp and php.<br />
<br />
# pacman -S lighttpd php php-cgi<br />
<br />
Information on setting up lighthttp can be found on it's wiki page: https://wiki.archlinux.org/index.php/Lighttpd<br />
<br />
After starting lighthttp as per the wiki, you should be able to access the test page at http://localhost:80.<br />
<br />
By default the pages are served from /srv/http, this is where we will be putting rutorrent.<br />
<br />
=== lighttpd.conf ===<br />
<br />
Edit lighthttpd's config file, /etc/lighttpd/lighttpd.conf.<br />
<br />
The following lines tell lighttpd to load the fastcgi and simple-cgi modules. Fast cgi is needed for rutorrent itself, and scgi for rutorrent to communicate with rtorrent.<br />
<br />
server.modules += ( "mod_fastcgi" )<br />
server.modules += ( "mod_scgi" )<br />
<br />
We need to tell lighttpd how to treat files like css, images (jpg etc.), js. Otherwise it will not know what to do with them, and you may get a dialog to download the file or rutorrent will just not work properly.<br />
<br />
Here is a long list of filetypes, it is probably overkill as most of them are not needed, but easier to cover them all.<br />
<br />
Add this to /etc/lighttpd/lighttpd.conf also.<br />
<br />
mimetype.assign = (<br />
".rpm" => "application/x-rpm",<br />
".pdf" => "application/pdf",<br />
".sig" => "application/pgp-signature",<br />
".spl" => "application/futuresplash",<br />
".class" => "application/octet-stream",<br />
".ps" => "application/postscript",<br />
".torrent" => "application/x-bittorrent",<br />
".dvi" => "application/x-dvi",<br />
".gz" => "application/x-gzip",<br />
".pac" => "application/x-ns-proxy-autoconfig",<br />
".swf" => "application/x-shockwave-flash",<br />
".tar.gz" => "application/x-tgz",<br />
".tgz" => "application/x-tgz",<br />
".tar" => "application/x-tar",<br />
".zip" => "application/zip",<br />
".mp3" => "audio/mpeg",<br />
".m3u" => "audio/x-mpegurl",<br />
".wma" => "audio/x-ms-wma",<br />
".wax" => "audio/x-ms-wax",<br />
".ogg" => "application/ogg",<br />
".wav" => "audio/x-wav",<br />
".gif" => "image/gif",<br />
".jar" => "application/x-java-archive",<br />
".jpg" => "image/jpeg",<br />
".jpeg" => "image/jpeg",<br />
".png" => "image/png",<br />
".xbm" => "image/x-xbitmap",<br />
".xpm" => "image/x-xpixmap",<br />
".xwd" => "image/x-xwindowdump",<br />
".css" => "text/css",<br />
".html" => "text/html",<br />
".htm" => "text/html",<br />
".js" => "text/javascript",<br />
".asc" => "text/plain",<br />
".c" => "text/plain",<br />
".cpp" => "text/plain",<br />
".log" => "text/plain",<br />
".conf" => "text/plain",<br />
".text" => "text/plain",<br />
".txt" => "text/plain",<br />
".dtd" => "text/xml",<br />
".xml" => "text/xml",<br />
".mpeg" => "video/mpeg",<br />
".mpg" => "video/mpeg",<br />
".mov" => "video/quicktime",<br />
".qt" => "video/quicktime",<br />
".avi" => "video/x-msvideo",<br />
".asf" => "video/x-ms-asf",<br />
".asx" => "video/x-ms-asf",<br />
".wmv" => "video/x-ms-wmv",<br />
".bz2" => "application/x-bzip",<br />
".tbz" => "application/x-bzip-compressed-tar",<br />
".tar.bz2" => "application/x-bzip-compressed-tar",<br />
# default mime type<br />
"" => "application/octet-stream",<br />
) <br />
<br />
Next we add the configuration for scgi to connect to rtorrent. Make sure to use the same port as when configuring rtorrent.<br />
<br />
scgi.server = (<br />
"/RPC2" =><br />
( "127.0.0.1" =><br />
(<br />
"host" => "127.0.0.1",<br />
"port" => 5050,<br />
"check-local" => "disable"<br />
)<br />
)<br />
)<br />
<br />
And finally the fastcgi settings so lighthttpd knows how to deal with php.<br />
<br />
fastcgi.server = ( ".php" => ((<br />
"bin-path" => "/usr/bin/php-cgi",<br />
"socket" => "/tmp/php.socket"<br />
)))<br />
<br />
==== Test ====<br />
<br />
At this point, you should be able to test if rtorrent and lighttpd's scgi are working properly using the xmlrpc command to ask rtorrent for a list of functions. ( See http://libtorrent.rakshasa.no/wiki/RTorrentXMLRPCGuide#Usage ).<br />
<br />
$ xmlrpc localhost system.listMethods<br />
<br />
This should output a log list of methods that can be accessed through rtorrent's scgi interface. If it doesn't then something may be wrong.<br />
<br />
=== php.ini ===<br />
<br />
We need to make a small change to the open_basedir line in /etc/php/php.ini, to allow rutorrent to access the binaries it needs to run.<br />
<br />
open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/bin/<br />
<br />
The binaries are stat, id, php, curl, gzip. If these are installed somewhere other than /usr/bin, then you may need to append that to the line also.<br />
<br />
== rutorrent ==<br />
<br />
We will download rutorrent to lighttpd http directory.<br />
<br />
# cd /srv/http<br />
# wget http://rutorrent.googlecode.com/files/rutorrent-3.4.tar.gz<br />
# tar xvfx rutorrent-3.4.tar.gz<br />
# rm rutorrent-3.4.tar.gz<br />
<br />
These should download and extract rutorrent to /srv/http. You may need to change rutorrent-3.4 to the desired version from the rutorrent website.<br />
<br />
rutorrent's config files are in '''/srv/http/rutorrent/conf/'''.<br />
<br />
We need to edit '''/srv/http/rutorrent/conf/config.php''', and change the port to the one we used in rtorrent and lighttpd.<br />
<br />
$scgi_port = 5050;<br />
$scgi_host = "127.0.0.1";<br />
<br />
Change the owner of the rutorrent to http (the user that lighttpd runs as by default).<br />
<br />
# chown -R http rutorrent<br />
<br />
== Testing ==<br />
<br />
rutorrent should now be set up.<br />
<br />
Start rtorrent, and restart lighttpd if you have not done so since changing the configuration.<br />
<br />
You should now be able to access the rutorrent interface on localhost or 127.0.0.1 on port 80 (assuming you did not change the default port for lighttpd).<br />
<br />
http://localhost<br />
<br />
== Plugins ==<br />
<br />
To install plugins for rutorrent, download the archive of the plugin you want and extract to rutorrent's plugin directory.<br />
/srv/http/rutorrent/plugins<br />
<br />
Plugins can be found on the rutorrent website: http://code.google.com/p/rutorrent/wiki/Plugins<br />
<br />
== SSL and Authentication ==<br />
{{Stub}}<br />
== Troubleshooting ==<br />
<br />
For problems with rutorrent or lighttpd, the best place to check first is probably the lighttpd log files, in '''/var/log/lighttpd/'''. Particularly error.log.<br />
<br />
$ tail /var/log/lighttpd/error.log<br />
<br />
== See Also ==<br />
* [http://code.google.com/p/rutorrent/ rutorrent Project page]<br />
* [[Rtorrent|Rtorrent Wiki page]]<br />
* [[Lighttpd]]<br />
* [[RuTorrent|RuTorrent (with Apache)]]<br />
* [http://libtorrent.rakshasa.no/wiki/RTorrentXMLRPCGuide Using XMLRPC with rtorrent]</div>Festerhttps://wiki.archlinux.org/index.php?title=DeveloperWiki_talk:Usrlib&diff=213444DeveloperWiki talk:Usrlib2012-07-18T03:17:29Z<p>Fester: /* Quick fix */ new section</p>
<hr />
<div>Note, if you're on a 64 bit system you may need to uncomment the entry for [Multilib] in /etc/pacman.conf --[[User:Zenten|Zenten]] ([[User talk:Zenten|talk]]) 22:46, 14 July 2012 (UTC)<br />
<br />
==Rebuilding==<br />
<br />
At the end of the procedure, it says<br />
<br />
Such packages can be detected using:<br />
grep '^lib/' /var/lib/pacman/local/*/files<br />
These packages need rebuilding so as not to include the /lib directory. Then the final "pacman -Su" will successfully install glibc.<br />
<br />
The term ''rebuilding'' is unclear to me. Reinstall ? Reboot the system ? The command returns glibc on my system --[[User:Martvefun|Martvefun]] ([[User talk:Martvefun|talk]]) 08:50, 15 July 2012 (UTC)<br />
:It will list packages that own files in /lib. If it only lists glibc, you're almost all set to go, all you have to do is check for unowned files and deal with those. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 12:16, 15 July 2012 (UTC)<br />
<br />
== Add subsection to deal with common apps ==<br />
<br />
Can we add a subsection to the "Issue 2" section that deals with known apps that need to be uninstalled and then reinstalled?<br />
<br />
Specifically in my case (and others), there is UFW that causes this "Issue 2". Of course, it would be wise to put a statement in there that pacman will keep their old ufw configs as ".pacsave" files but that they manually must merge them back after reinstalling UFW.<br />
<br />
[[User:Twelveeighty|Twelveeighty]] ([[User talk:Twelveeighty|talk]]) 01:00, 16 July 2012 (UTC)<br />
-------<br />
<br />
Rackspace formerly supported Arch 2010.05 and included a kernel module for packaged as 2.6.35.1-rscloud. Anyone that is running instances from that original image will be affected by Issue 2:<br />
<br />
$ find /lib -exec pacman -Qo -- {} +<br />
error: cannot determine ownership of directory '/lib/modules/2.6.35.1-rscloud'<br />
error: No package owns /lib/modules/2.6.35.1-rscloud/modules.seriomap<br />
...<br />
<br />
Solved by following the instructions to move 2.6.35.1-rscloud to lib, but these can very likely be deleted.<br />
<br />
pacman -U http://pkgbuild.com/~allan/glibc-2.16.0-1-<arch>.pkg.tar.xz # <arch> = x86_64 | i686<br />
pacman -Syu --ignore glibc<br />
cp -r /lib/modules/2.6.35.1-rscloud/ /usr/lib/<br />
rm -rf /lib/modules/<br />
pacman -Su<br />
<br />
--[[User:Dalesaurus|Dalesaurus]] ([[User talk:Dalesaurus|talk]]) 15:11, 17 July 2012 (UTC)<br />
<br />
== Issue 2 ==<br />
<br />
<br />
Too many users are unsure about remaining contents in /lib directly. I propose someone adds the following to the issue 2 in the usrlib wiki as another warning: <br />
<br />
"Do not delete or move away any files in /lib owned by your current glibc (2.16.0-1 on up-to-date systems) in any case at this point."<br />
<br />
--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 16:42, 15 July 2012 (UTC)<br />
<br />
== Issue 3 ==<br />
<br />
Please change "folder" to "directory" and "folders" to "directories" -- Filesystems don't have folders, they have directories. [[User:Diegoviola|Diegoviola]] ([[User talk:Diegoviola|talk]]) 14:28, 16 July 2012 (UTC)<br />
<br />
Also, please change that [http://www.archlinux.org/news/filesystem-upgrade-manual-intervention-required-1/ here] as well. [[User:Diegoviola|Diegoviola]] ([[User talk:Diegoviola|talk]]) 15:14, 16 July 2012 (UTC)<br />
<br />
== Quick fix ==<br />
<br />
According to falconindy:<br />
<br />
<br />
As long as you have a root shell open prior to the upgrade, you can fix this quite easily if it explodes:<br />
/usr/lib/ld-2.16.so /bin/rm -r /lib<br />
/usr/lib/ld-2.16.so /bin/ln -s usr/lib /lib<br />
<br />
You can't do this as a normal user via su or sudo because the setuid bits are no longer significant when executed directly through the linker.</div>Festerhttps://wiki.archlinux.org/index.php?title=DeveloperWiki_talk:Usrlib&diff=213442DeveloperWiki talk:Usrlib2012-07-18T03:01:50Z<p>Fester: </p>
<hr />
<div>Note, if you're on a 64 bit system you may need to uncomment the entry for [Multilib] in /etc/pacman.conf --[[User:Zenten|Zenten]] ([[User talk:Zenten|talk]]) 22:46, 14 July 2012 (UTC)<br />
<br />
==Rebuilding==<br />
<br />
At the end of the procedure, it says<br />
<br />
Such packages can be detected using:<br />
grep '^lib/' /var/lib/pacman/local/*/files<br />
These packages need rebuilding so as not to include the /lib directory. Then the final "pacman -Su" will successfully install glibc.<br />
<br />
The term ''rebuilding'' is unclear to me. Reinstall ? Reboot the system ? The command returns glibc on my system --[[User:Martvefun|Martvefun]] ([[User talk:Martvefun|talk]]) 08:50, 15 July 2012 (UTC)<br />
:It will list packages that own files in /lib. If it only lists glibc, you're almost all set to go, all you have to do is check for unowned files and deal with those. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 12:16, 15 July 2012 (UTC)<br />
<br />
== Add subsection to deal with common apps ==<br />
<br />
Can we add a subsection to the "Issue 2" section that deals with known apps that need to be uninstalled and then reinstalled?<br />
<br />
Specifically in my case (and others), there is UFW that causes this "Issue 2". Of course, it would be wise to put a statement in there that pacman will keep their old ufw configs as ".pacsave" files but that they manually must merge them back after reinstalling UFW.<br />
<br />
[[User:Twelveeighty|Twelveeighty]] ([[User talk:Twelveeighty|talk]]) 01:00, 16 July 2012 (UTC)<br />
-------<br />
<br />
Rackspace formerly supported Arch 2010.05 and included a kernel module for packaged as 2.6.35.1-rscloud. Anyone that is running instances from that original image will be affected by Issue 2:<br />
<br />
$ find /lib -exec pacman -Qo -- {} +<br />
error: cannot determine ownership of directory '/lib/modules/2.6.35.1-rscloud'<br />
error: No package owns /lib/modules/2.6.35.1-rscloud/modules.seriomap<br />
...<br />
<br />
Solved by following the instructions to move 2.6.35.1-rscloud to lib, but these can very likely be deleted.<br />
<br />
pacman -U http://pkgbuild.com/~allan/glibc-2.16.0-1-<arch>.pkg.tar.xz # <arch> = x86_64 | i686<br />
pacman -Syu --ignore glibc<br />
cp -r /lib/modules/2.6.35.1-rscloud/ /usr/lib/<br />
rm -rf /lib/modules/<br />
pacman -Su<br />
<br />
--[[User:Dalesaurus|Dalesaurus]] ([[User talk:Dalesaurus|talk]]) 15:11, 17 July 2012 (UTC)<br />
<br />
== Issue 2 ==<br />
<br />
<br />
Too many users are unsure about remaining contents in /lib directly. I propose someone adds the following to the issue 2 in the usrlib wiki as another warning: <br />
<br />
"Do not delete or move away any files in /lib owned by your current glibc (2.16.0-1 on up-to-date systems) in any case at this point."<br />
<br />
--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 16:42, 15 July 2012 (UTC)<br />
<br />
== Issue 3 ==<br />
<br />
Please change "folder" to "directory" and "folders" to "directories" -- Filesystems don't have folders, they have directories. [[User:Diegoviola|Diegoviola]] ([[User talk:Diegoviola|talk]]) 14:28, 16 July 2012 (UTC)<br />
<br />
Also, please change that [http://www.archlinux.org/news/filesystem-upgrade-manual-intervention-required-1/ here] as well. [[User:Diegoviola|Diegoviola]] ([[User talk:Diegoviola|talk]]) 15:14, 16 July 2012 (UTC)</div>Festerhttps://wiki.archlinux.org/index.php?title=DeveloperWiki_talk:Usrlib&diff=213441DeveloperWiki talk:Usrlib2012-07-18T03:01:09Z<p>Fester: /* What do you do if you've used force? */ new section</p>
<hr />
<div>Note, if you're on a 64 bit system you may need to uncomment the entry for [Multilib] in /etc/pacman.conf --[[User:Zenten|Zenten]] ([[User talk:Zenten|talk]]) 22:46, 14 July 2012 (UTC)<br />
<br />
==Rebuilding==<br />
<br />
At the end of the procedure, it says<br />
<br />
Such packages can be detected using:<br />
grep '^lib/' /var/lib/pacman/local/*/files<br />
These packages need rebuilding so as not to include the /lib directory. Then the final "pacman -Su" will successfully install glibc.<br />
<br />
The term ''rebuilding'' is unclear to me. Reinstall ? Reboot the system ? The command returns glibc on my system --[[User:Martvefun|Martvefun]] ([[User talk:Martvefun|talk]]) 08:50, 15 July 2012 (UTC)<br />
:It will list packages that own files in /lib. If it only lists glibc, you're almost all set to go, all you have to do is check for unowned files and deal with those. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 12:16, 15 July 2012 (UTC)<br />
<br />
== Add subsection to deal with common apps ==<br />
<br />
Can we add a subsection to the "Issue 2" section that deals with known apps that need to be uninstalled and then reinstalled?<br />
<br />
Specifically in my case (and others), there is UFW that causes this "Issue 2". Of course, it would be wise to put a statement in there that pacman will keep their old ufw configs as ".pacsave" files but that they manually must merge them back after reinstalling UFW.<br />
<br />
[[User:Twelveeighty|Twelveeighty]] ([[User talk:Twelveeighty|talk]]) 01:00, 16 July 2012 (UTC)<br />
-------<br />
<br />
Rackspace formerly supported Arch 2010.05 and included a kernel module for packaged as 2.6.35.1-rscloud. Anyone that is running instances from that original image will be affected by Issue 2:<br />
<br />
$ find /lib -exec pacman -Qo -- {} +<br />
error: cannot determine ownership of directory '/lib/modules/2.6.35.1-rscloud'<br />
error: No package owns /lib/modules/2.6.35.1-rscloud/modules.seriomap<br />
...<br />
<br />
Solved by following the instructions to move 2.6.35.1-rscloud to lib, but these can very likely be deleted.<br />
<br />
pacman -U http://pkgbuild.com/~allan/glibc-2.16.0-1-<arch>.pkg.tar.xz # <arch> = x86_64 | i686<br />
pacman -Syu --ignore glibc<br />
cp -r /lib/modules/2.6.35.1-rscloud/ /usr/lib/<br />
rm -rf /lib/modules/<br />
pacman -Su<br />
<br />
--[[User:Dalesaurus|Dalesaurus]] ([[User talk:Dalesaurus|talk]]) 15:11, 17 July 2012 (UTC)<br />
<br />
== Issue 2 ==<br />
<br />
<br />
Too many users are unsure about remaining contents in /lib directly. I propose someone adds the following to the issue 2 in the usrlib wiki as another warning: <br />
<br />
"Do not delete or move away any files in /lib owned by your current glibc (2.16.0-1 on up-to-date systems) in any case at this point."<br />
<br />
--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 16:42, 15 July 2012 (UTC)<br />
<br />
== Issue 3 ==<br />
<br />
Please change "folder" to "directory" and "folders" to "directories" -- Filesystems don't have folders, they have directories. [[User:Diegoviola|Diegoviola]] ([[User talk:Diegoviola|talk]]) 14:28, 16 July 2012 (UTC)<br />
<br />
Also, please change that [http://www.archlinux.org/news/filesystem-upgrade-manual-intervention-required-1/ here] as well. [[User:Diegoviola|Diegoviola]] ([[User talk:Diegoviola|talk]]) 15:14, 16 July 2012 (UTC)<br />
<br />
== What do you do if you've used force? ==<br />
<br />
All it does is warn, but previously such as with filesystem, this has been the way to fix this error. What happens if you've done this already?</div>Fester