Wireshark kräver X11 för att köras under OSX. I och med OSX 10.8 ingår inte längre X11 och Apple hänvisar användare till xquartz.
När jag försökte köra Wireshark tillsammans med Xquartz märkte jag att inga fönster öppnas även om programmet visas som det är startat. En workaround är att starta Xquartz, öppna en Xterm i Xquartz och sedan köra följande:
open /Applications/Wireshark.app/
Nu kommer Wireshark att starta upp normalt.
måndag 1 april 2013
tisdag 5 februari 2013
Rensa sökcache i Windows
Om indexering är aktiverat i Windows 7 kommer det att skapas det cachefiler, Windows.edb samt tillhörande *.ci-filer. Antalet filer och utförda sökningar påverkar cachestorleken.
I min utvecklingsdator där jag regelbundet söker i källkod och har ett stort antal filer är cachestrukturen över 5GB stor. Då maskinen har en liten SSD var det dags att utföra en rensning.
Öppna kontrollpanelen, gå till Indexing Options. Tryck på modify-knappen, bocka ur samtliga platser.
Tryck där efter på Advanced-knappen, tryck där efter på Rebuild. Nu kommer Windows att rensa all cache.
Om du behöver cache, gå tillbaka till indexing options, lägg till de platser du behöver. Nu kan du antingen välja att göra en rebuild igen för att låta cachen återskapas direkt eller trycka close och låta cachen skapas vid behov.
Även om alla platser är urbockade kommer indexeringen inte bli helt inaktiverad. Vill du inaktivera indexeringen gör du så här:
Gå till Control Panel -> Administrative tools -> Services.
Dubbelklicka på Windows Search, välj disabled och tryck där efter på stop.
Om du däremot bara vill stänga av indexering för en specifik hårddisk går även detta att göra. Öppna My Computer, högerklicka på en hårddisk, välj properties. Bocka sedan ur rutan
"Allow files on this drive to have contents indexed in addition to file properties".
I min utvecklingsdator där jag regelbundet söker i källkod och har ett stort antal filer är cachestrukturen över 5GB stor. Då maskinen har en liten SSD var det dags att utföra en rensning.
Öppna kontrollpanelen, gå till Indexing Options. Tryck på modify-knappen, bocka ur samtliga platser.
Tryck där efter på Advanced-knappen, tryck där efter på Rebuild. Nu kommer Windows att rensa all cache.
Om du behöver cache, gå tillbaka till indexing options, lägg till de platser du behöver. Nu kan du antingen välja att göra en rebuild igen för att låta cachen återskapas direkt eller trycka close och låta cachen skapas vid behov.
Även om alla platser är urbockade kommer indexeringen inte bli helt inaktiverad. Vill du inaktivera indexeringen gör du så här:
Gå till Control Panel -> Administrative tools -> Services.
Dubbelklicka på Windows Search, välj disabled och tryck där efter på stop.
Om du däremot bara vill stänga av indexering för en specifik hårddisk går även detta att göra. Öppna My Computer, högerklicka på en hårddisk, välj properties. Bocka sedan ur rutan
"Allow files on this drive to have contents indexed in addition to file properties".
onsdag 23 januari 2013
GPU-prestanda Xbox 360 och Playstation 3
I föregående post gick jag igenom beräkningsprestanda i Playstation 3 och Xbox 360. Jag snuddade även vid att GPUn i Xbox 360 går att använda för GPGPU-beräkningar. I detta inlägg tänkte jag jämföra de två grafiklösningarna som används i Playstation 3 och Xbox 360.
Xenos som sitter i Xbox 360 är en modern typ av GPU med unified shaders och GPGPU-funktionalitet. Det går alltså att utföra annat än grafikberäkningar och prestandan påverkas inte av fördelningen mellan pixel- och vertexshaders i spel.
Xenos är föregångaren till R600, det vill säga Radeon 2900-/2600-/2400-serien.
En markant skillnad är hur ration mellan shaders, texture mapping units och ROPs ser ut.
Xenos: 6:2:1
2400: 10:1:1
2600: 30:2:1
2900: 20:1:1
Xenos har alltså förhållandevis extremt få shaders och ganska många texture units. Detta ger en hög fillrate, men låg beräkningskapacitet.
Faktiska siffror:
Xenos: 48:16:8
2400: 40:4:4
2600: 120:8:4
2900: 320:16:16
Xenos har inget dedikerat vram utan är ansluten till en stor minnespool på 512MB som den delar med Xboxens CPU. Däremot har Xenos 10MB edram anslutet, dit den skriver delar av sin framebuffer (tiled rendering).
Edramet har också extra logik anslutet för att avlasta Xenos med anti alias, alpha compositioning och stencil buffering. Data som processas av denna logik har en bandbredd av 256GB/s vidare mot Edramet! Operationer som alpha compositioning och stencil buffering görs normalt av ROP, så räknar man in detta har Xenos ett väldigt högt antal ROPs i förhållande till shaders.
RSX som sitter i Playstation 3 är baserad på Geforce 7800. Detta är en äldre typ utan unified shaders eller GPGPU-stöd. RSX har 24st pixel shaders och 8st vertex shaders.
Till skillnad från Xenos har RSX dedikerat minne på 256MB. Bandbredden är på 22.4GB/s vilket är markant lägre än 7800GTX. RSX kan också mappa in ramminne om 256MB inte skulle räcka, då sjunker prestandan till 15GB/s läs och 10GB/s skriv.
RSX: 22.4GB/s 128bit, 1400MHz GDDR3
7600GT: 22.4GB/S 128bit, 1400MHz GDDR3
7800GS: 38.4GB/s 256bit, 1200MHz GDDR3
7800GTX: 38.4GB/s 256bit, 1200MHZ GDDR3
Även om RSX är baserad på 7800GTX är det en något bantad modell, som hamnar någonstans mellan GTX och GS om man tittar på pixel shaders, vertex shaders, texturing units och ROPs.
RSX: 24:8:24:8, 550MHz
7600GT: 12:5:12:8, 560MHz
7800GS: 16:8:16:8, 375MHz
7800GTX: 24/8/24/16, 430MHz
Ser man till förhållandet mellan dem, verkar det mer normalt än för Xenos:
RSX: 3:1:3:1
7600GT: 2.4:1:2.4:1.6
7800GS: 2:1:2:1
7800GTX: 3:1:3:2
Normaliserar vi med klockfrekvens ser vi följande:
Xenos: 132:44:132:44
7600GT: 67:28:67:45
7800GS: 60:30:60:30
7800GTX: 103:34:103:69
Men om vi jämför korten hur ser prestandan ut då?
Bandbredden är komplicerad att räkna in, eftersom Xenos bandbredd både beror på edram och det delade minnet, precis som att RSX kan mappa ram om det behövs. Därför tänker jag bara gå genom rå beräkningsprestanda.
Antal operationer per sekund:
RSX: 400GFlops, (24 pixel s. * 27ops + 8 vertex s. * 10ops) * 550MHz
Xenos: 240GFlops, 48 shaders * 10ops * 500MHz
Här är den teoretiska prestandan i RSX markant högre, men det kräver perfekt fördelning av pixel- och vertex-shaders medan Xenos behåller sitt värde oavsett fördelning. Vid en fördelning av 24/16 kommer RSX bara hantera 200GFlops exempelvis.
Antal shaderoperationer per sekund:
RSX: 75 Miljarder, (24 Pixel s. * 5 ALU + 8 vertex s. * 2 ALU) * 550MHz
Xenos 96 Miljarder, 48 * 4 ALU * 500MHz
Här gäller också perfekt fördelning för att RSX ska uppnå sina värden.
Texel fillrate
RSX: 13.2 GigaTexels, 24 texture units * 550MHz
Xenos: 8 GigaTexels, 16 texture units * 500MHz
Pixel fillrate
RSX: 4.4 Gpixels, 8 ROPs * 550MHz
Xenos: 4 Gpixels, 8 ROPs * 500MHz
Z sample rate
RSX: 8.8 GigaSamples, 2x Z-samples * 8 ROPs * 550 MHz
Xenos: 8 GigaSamples, 2x Z-samples * 8 ROPs * 500 MHz
Att ha möjlighet till två Z-samples är något som kan utnyttjas för att köra två pass över scenen som ska renderas. Första gången samplar man vad som ligger längst fram i bild, så att det som ligger bakom kan ignoreras om det är täckt.
Som vi kan se är fillrate och sample rate högre, däremot är shaderoperationer lägre. Pixel fillrate på 360 ska vara exakt matchat mot edram för att kunna utföra 4xAA vid hd-upplösningar.
http://www.beyond3d.com/content/articles/4/4
Något som siffrorna inte kan visa är att Xenos är effektivare under ojämn last, samt hur hög praktisk effektivitet grafiklösningarna faktiskt har under last.
Xenos som sitter i Xbox 360 är en modern typ av GPU med unified shaders och GPGPU-funktionalitet. Det går alltså att utföra annat än grafikberäkningar och prestandan påverkas inte av fördelningen mellan pixel- och vertexshaders i spel.
Xenos är föregångaren till R600, det vill säga Radeon 2900-/2600-/2400-serien.
En markant skillnad är hur ration mellan shaders, texture mapping units och ROPs ser ut.
Xenos: 6:2:1
2400: 10:1:1
2600: 30:2:1
2900: 20:1:1
Xenos har alltså förhållandevis extremt få shaders och ganska många texture units. Detta ger en hög fillrate, men låg beräkningskapacitet.
Faktiska siffror:
Xenos: 48:16:8
2400: 40:4:4
2600: 120:8:4
2900: 320:16:16
Xenos har inget dedikerat vram utan är ansluten till en stor minnespool på 512MB som den delar med Xboxens CPU. Däremot har Xenos 10MB edram anslutet, dit den skriver delar av sin framebuffer (tiled rendering).
Edramet har också extra logik anslutet för att avlasta Xenos med anti alias, alpha compositioning och stencil buffering. Data som processas av denna logik har en bandbredd av 256GB/s vidare mot Edramet! Operationer som alpha compositioning och stencil buffering görs normalt av ROP, så räknar man in detta har Xenos ett väldigt högt antal ROPs i förhållande till shaders.
RSX som sitter i Playstation 3 är baserad på Geforce 7800. Detta är en äldre typ utan unified shaders eller GPGPU-stöd. RSX har 24st pixel shaders och 8st vertex shaders.
Till skillnad från Xenos har RSX dedikerat minne på 256MB. Bandbredden är på 22.4GB/s vilket är markant lägre än 7800GTX. RSX kan också mappa in ramminne om 256MB inte skulle räcka, då sjunker prestandan till 15GB/s läs och 10GB/s skriv.
RSX: 22.4GB/s 128bit, 1400MHz GDDR3
7600GT: 22.4GB/S 128bit, 1400MHz GDDR3
7800GS: 38.4GB/s 256bit, 1200MHz GDDR3
7800GTX: 38.4GB/s 256bit, 1200MHZ GDDR3
Även om RSX är baserad på 7800GTX är det en något bantad modell, som hamnar någonstans mellan GTX och GS om man tittar på pixel shaders, vertex shaders, texturing units och ROPs.
RSX: 24:8:24:8, 550MHz
7600GT: 12:5:12:8, 560MHz
7800GS: 16:8:16:8, 375MHz
7800GTX: 24/8/24/16, 430MHz
Ser man till förhållandet mellan dem, verkar det mer normalt än för Xenos:
RSX: 3:1:3:1
7600GT: 2.4:1:2.4:1.6
7800GS: 2:1:2:1
7800GTX: 3:1:3:2
Normaliserar vi med klockfrekvens ser vi följande:
Xenos: 132:44:132:44
7600GT: 67:28:67:45
7800GS: 60:30:60:30
7800GTX: 103:34:103:69
Men om vi jämför korten hur ser prestandan ut då?
Bandbredden är komplicerad att räkna in, eftersom Xenos bandbredd både beror på edram och det delade minnet, precis som att RSX kan mappa ram om det behövs. Därför tänker jag bara gå genom rå beräkningsprestanda.
Antal operationer per sekund:
RSX: 400GFlops, (24 pixel s. * 27ops + 8 vertex s. * 10ops) * 550MHz
Xenos: 240GFlops, 48 shaders * 10ops * 500MHz
Här är den teoretiska prestandan i RSX markant högre, men det kräver perfekt fördelning av pixel- och vertex-shaders medan Xenos behåller sitt värde oavsett fördelning. Vid en fördelning av 24/16 kommer RSX bara hantera 200GFlops exempelvis.
Antal shaderoperationer per sekund:
RSX: 75 Miljarder, (24 Pixel s. * 5 ALU + 8 vertex s. * 2 ALU) * 550MHz
Xenos 96 Miljarder, 48 * 4 ALU * 500MHz
Här gäller också perfekt fördelning för att RSX ska uppnå sina värden.
Texel fillrate
RSX: 13.2 GigaTexels, 24 texture units * 550MHz
Xenos: 8 GigaTexels, 16 texture units * 500MHz
Pixel fillrate
RSX: 4.4 Gpixels, 8 ROPs * 550MHz
Xenos: 4 Gpixels, 8 ROPs * 500MHz
Z sample rate
RSX: 8.8 GigaSamples, 2x Z-samples * 8 ROPs * 550 MHz
Xenos: 8 GigaSamples, 2x Z-samples * 8 ROPs * 500 MHz
Att ha möjlighet till två Z-samples är något som kan utnyttjas för att köra två pass över scenen som ska renderas. Första gången samplar man vad som ligger längst fram i bild, så att det som ligger bakom kan ignoreras om det är täckt.
Som vi kan se är fillrate och sample rate högre, däremot är shaderoperationer lägre. Pixel fillrate på 360 ska vara exakt matchat mot edram för att kunna utföra 4xAA vid hd-upplösningar.
http://www.beyond3d.com/content/articles/4/4
Något som siffrorna inte kan visa är att Xenos är effektivare under ojämn last, samt hur hög praktisk effektivitet grafiklösningarna faktiskt har under last.
Beräkningsprestanda i 360 och PS3
Nu är det snart dags för nästa generation av Playstation och Xbox. I och med detta väcks diskussionerna om prestanda i nuvarande generation.
En vanlig tolkning är att Playstation 3 skulle ha högre prestanda än Xbox 360, men varifrån kommer denna tolkning från och stämmer den?
Tolkningen kommer från att Cell-CPUn i PS3 har teoretisk topprestanda som ligger över den i Xbox 360.
Cellprocessorn i Playstation 3 består av en PPE, en traditionell CPU samt 7st SPU-enheter. SPU-enheterna är avsedda att effektivt kunna beräkna flyttalsoperationer och är jämförbara med vad man hittar i ett modernt grafikkort med GPGPU-funktionalitet.
Xbox 360 har en CPU, Xenon, som består av 3st PPE-enheter och inga SPU-enheter. Microsoft har gjort några mindre ändringar till Altivec-enheten i PPEn. Det nya instruktionssetet kallas VMX128 och är inte bakåtkompatibelt med Altivec.
En annan skillnad mellan PPE i Cell och Xenon är att Xenon har 1MB Cache som delas mellan kärnorna, medan Cell har 512KB cache till PPEn. Således bör enkeltrådad prestanda vara högre på Xenon, men det finns ingen praktisk anledning att köra sådan kod.
Jag roade mig med att jämföra teoretisk prestanda mellan de två. Notera att jag bara räknar med 6 SPUer eftersom den sjunde är reserverad av systemet i Playstation 3.
Flyttal, single precision
360: 3x 25.6 = 76.8 GFlops
PS3: 1x 25.6 + 6x 25.6 = 179.2 GFlops
Det är oftast här jämförelsen slutar och så säger man att PS3 är snabbast. Men låt oss fortsätta:
Flyttal, double precision
360: 3x 6.4 = 19.2 GFlops
PS3: 1x 6.4 + 6x 1.8 = 17.2 GFlops
Xbox 360 har också en modernare GPU, Xenos, denna har GPGPU-funktionalitet, till skillnad från RSX i PS3. Vi kan alltså låta Xenos göra beräkningar, om än bara i single precision.
Flyttal, single precision
360: 3x 25.6 + 240 = 316.8 GFlops
PS3: 1x 25.6 + 6x 25.6 = 179.2 GFlops
I teorin är alltså Xenon + Xenos snabbare än Cell oavsett om vi vill beräkna single- eller double precision.
En vanlig tolkning är att Playstation 3 skulle ha högre prestanda än Xbox 360, men varifrån kommer denna tolkning från och stämmer den?
Tolkningen kommer från att Cell-CPUn i PS3 har teoretisk topprestanda som ligger över den i Xbox 360.
Cellprocessorn i Playstation 3 består av en PPE, en traditionell CPU samt 7st SPU-enheter. SPU-enheterna är avsedda att effektivt kunna beräkna flyttalsoperationer och är jämförbara med vad man hittar i ett modernt grafikkort med GPGPU-funktionalitet.
Xbox 360 har en CPU, Xenon, som består av 3st PPE-enheter och inga SPU-enheter. Microsoft har gjort några mindre ändringar till Altivec-enheten i PPEn. Det nya instruktionssetet kallas VMX128 och är inte bakåtkompatibelt med Altivec.
En annan skillnad mellan PPE i Cell och Xenon är att Xenon har 1MB Cache som delas mellan kärnorna, medan Cell har 512KB cache till PPEn. Således bör enkeltrådad prestanda vara högre på Xenon, men det finns ingen praktisk anledning att köra sådan kod.
Jag roade mig med att jämföra teoretisk prestanda mellan de två. Notera att jag bara räknar med 6 SPUer eftersom den sjunde är reserverad av systemet i Playstation 3.
Flyttal, single precision
360: 3x 25.6 = 76.8 GFlops
PS3: 1x 25.6 + 6x 25.6 = 179.2 GFlops
Det är oftast här jämförelsen slutar och så säger man att PS3 är snabbast. Men låt oss fortsätta:
Flyttal, double precision
360: 3x 6.4 = 19.2 GFlops
PS3: 1x 6.4 + 6x 1.8 = 17.2 GFlops
Xbox 360 har också en modernare GPU, Xenos, denna har GPGPU-funktionalitet, till skillnad från RSX i PS3. Vi kan alltså låta Xenos göra beräkningar, om än bara i single precision.
Flyttal, single precision
360: 3x 25.6 + 240 = 316.8 GFlops
PS3: 1x 25.6 + 6x 25.6 = 179.2 GFlops
I teorin är alltså Xenon + Xenos snabbare än Cell oavsett om vi vill beräkna single- eller double precision.
lördag 15 december 2012
Modernisera bootloader och DirectX i NT4
Prövade att installera NT4 i en virtuell maskin, det finns två roliga tweaks man kan göra. Det första är att installera DirectX 5. Normalt stöder bara NT4 upp till DirectX 3, men till betan av Windows 2000 (NT5) gjordes DirectX 5-filer som är kompatibla med Windows NT 4. Filerna kan hittas genom att söka efter nt4dx5.zip
Den andra tweaken man kan göra är att man kan stoppa in en nyare bootloader, detta snabbar upp boothastigheten. Filerna som ska bytas ut ligger rätt i C: och heter ntdetect.com och ntldr. Man kan ta filerna från Windows 2000, XP eller 2003. Filerna i 2003 SP1 är de som ger bäst prestanda.
Den andra tweaken man kan göra är att man kan stoppa in en nyare bootloader, detta snabbar upp boothastigheten. Filerna som ska bytas ut ligger rätt i C: och heter ntdetect.com och ntldr. Man kan ta filerna från Windows 2000, XP eller 2003. Filerna i 2003 SP1 är de som ger bäst prestanda.
fredag 30 november 2012
Nu fungerar nyheterna igen.
Märkte att mitt rss-flöde med nyheter slutat fungera och bara visade mina blogginlägg. Nu fungerar allt som innan igen.
söndag 30 september 2012
ruTorrent i Ubuntu server
Uppdatering: Jag rekommenderar att du installerar rTorrent tillsammans med c-ares för att det inte ska frysa när många torrentar körs. För instruktioner om c-ares se mitt nya inlägg.
ruTorrent är en webbaserad frontend till rtorrent. Tanken är att den ska vara extremt lik uTorrent. ruTorrent är huvudsakligen skriven i php och kommunicerar med rtorrent genom xmlrpc-c.
Jag har installerat ruTorrent tillsammans med lighttpd, vilket är något ovanligare än Apache.
Vi börjar med att installera lighttpd och php
Vi börjar med att installera nödvändiga paket.
Dags för att kompilera och installera libtorrent.
Vi fortsätter mer att installera rTorrent.
Vi fortsätter med att lägga in rpc-stödet som krävs för att ruTorrent ska kunna kommunicera med rtorrent.
Nu har vi kommit till att lägga ruTorrent på plats.
Skapa filstruktur för rtorrent, förslagsvis i din hemmapp
Konfiguration av rTorrent:
Parametrar som behöver ändras är:
De flesta övriga inställningar går att konfigurera från ruTorrent, men det som sätts i .rtorrent.rc kommer användas som default.
Om ruTorrent ska vara öppet utifrån behöver den adressen säkras upp. Detta kan göras på följande sätt:
Lägg sedan till följande i /etc/lighttpd/lighttpd.conf
Dags att ladda om lighttpd
Har allt gått vägen ska du nu kunna nå ruTorrent med användarnamn och lösenord på http://mitthostname/rutorrent
Källa:
http://filesharefreak.com/2010/02/13/how-to-install-rtorrent-rutorrent-using-socket-ssl-authentication-on-ubuntu-or-debian
ruTorrent är en webbaserad frontend till rtorrent. Tanken är att den ska vara extremt lik uTorrent. ruTorrent är huvudsakligen skriven i php och kommunicerar med rtorrent genom xmlrpc-c.
Jag har installerat ruTorrent tillsammans med lighttpd, vilket är något ovanligare än Apache.
Vi börjar med att installera lighttpd och php
sudo apt-get install lighttpd php5 php5-common php5-cli php5-cgi php5-curlDå de flesta distributioner inte kompilerar in rpc-stöd i rTorrent blir nästa steg att ladda hem och kompilera libtorrent samt rtorrent.
Vi börjar med att installera nödvändiga paket.
sudo apt-get g++ install automake make libcppunit-dev libcurl4-nss-dev libncurses5-dev libsigc++-2.0-dev libtool libxmlrpc-c3-dev pkg-config
Dags för att kompilera och installera libtorrent.
wget http://libtorrent.rakshasa.no/downloads/libtorrent-0.13.2.tar.gz
tar zxf libtorrent-0.13.2.tar.gz
cd libtorrent-0.13.2
./autogen.sh
./configure
make
sudo make install
Vi fortsätter mer att installera rTorrent.
wget http://libtorrent.rakshasa.no/downloads/rtorrent-0.9.2.tar.gzNu behöver vi konfigurera lighttpd att använda php, lägg till följande i /etc/lighttpd/lighttpd.conf
tar zxf rtorrent-0.9.2.tar.gz
cd rtorrent-0.9.2
./autogen.sh
./configure --with-xmlrpc-c
make
sudo make install
fastcgi.server = ( ".php" => ((
"bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php.socket",
"max-procs" => 2,
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "16",
"PHP_FCGI_MAX_REQUESTS" => "10000"
),
"bin-copy-environment" => (
"PATH", "SHELL", "USER"
),
"broken-scriptfilename" => "enable"
)))
Vi fortsätter med att lägga in rpc-stödet som krävs för att ruTorrent ska kunna kommunicera med rtorrent.
server.modules += ( "mod_scgi")
scgi.server = (
"/RPC2" =>
( "127.0.0.1" =>
(
"socket" => "/tmp/rpc.socket",
"check-local" => "disable",
"disable-time" => 0, # don't disable scgi if connection fails
)
)
)
Nu har vi kommit till att lägga ruTorrent på plats.
wget http://rutorrent.googlecode.com/files/rutorrent-3.4.tar.gzruTorrent behöver konfigureras, konfigurationsfilen finns här:
tar zxf rutorrent-3.4.tar.gz
wget http://rutorrent.googlecode.com/files/plugins-3.4.tar.gz
tar zxf plugins-3.4.tar.gz
mv plugins rutorrent/
Dags att flytta in ruTorrent till webservern.
sudo mv rutorrent /var/www/
sudo chown -r www-data:www-data /var/www/rutorrent
/var/www/rutorrent/conf/config.phpStäll följande parametrar:
$scgi_port = 0;Om du kommer ha din download-mapp någon annanstans än på din huvudpartition (sda1) behöver du ändra $topDirectory till att peka på rätt mapp.
$scgi_host = "unix:///tmp/rpc.socket";
$XMLRPCMountPoint = "/RPC2";
Skapa filstruktur för rtorrent, förslagsvis i din hemmapp
cd
mkdir rtorrent
cd rtorrent
mkdir download
mkdir watch
mkdir .session
Konfiguration av rTorrent:
cd
wget https://rtgui.googlecode.com/files/.rtorrent.rc
nano .rtorrent.rc
Parametrar som behöver ändras är:
encoding_list = UTF-8
scgi_local = /tmp/rpc.socket
schedule = chmod,0,0,"execute=chmod,777,/tmp/rpc.socket"
directory = ~/rtorrent/download
De flesta övriga inställningar går att konfigurera från ruTorrent, men det som sätts i .rtorrent.rc kommer användas som default.
Om ruTorrent ska vara öppet utifrån behöver den adressen säkras upp. Detta kan göras på följande sätt:
sudo apt-get install apache2-utils
sudo htdigest -c /etc/lighttpd/.auth "Authorized users only" mittUserName
Lägg sedan till följande i /etc/lighttpd/lighttpd.conf
server.modules += ( "mod_auth" )
auth.backend = "htdigest"
auth.backend.htdigest.userfile = "/etc/lighttpd/.auth"
auth.debug = 2
auth.require = ( "/rutorrent/" => ( "method" => "digest", "realm" => "Authorized users only", "require" => "valid-user" ) )
Dags att ladda om lighttpd
sudo service lighttpd force-reload
Har allt gått vägen ska du nu kunna nå ruTorrent med användarnamn och lösenord på http://mitthostname/rutorrent
Källa:
http://filesharefreak.com/2010/02/13/how-to-install-rtorrent-rutorrent-using-socket-ssl-authentication-on-ubuntu-or-debian
Prenumerera på:
Inlägg (Atom)