Planning on using Arch for a web server/torrent tracker/torrent s[...]

Question

I'm going to be making a web server/torrent tracker/torrent seed (hopefully) from Arch on an old-ish HP NetServer E 800. I was going to go with Debian, but I like the KISS Arch brings and with a server on the slim hardware I'm using, even Debian is too big esp. compared to Arch. [If the hardware's not up to Arch (highly doubtful) I'll have to resort to *gasp* Gentoo.]
I saw the tutorial on the wiki for Arch with Apache, LAMP, etc. so that's fine. I do, however, have a question about torrent stuff. I'm wanting to track and seed my band's torrents off the same machine (obviously, it won't be the sole tracker; TPB/Mininova/etc.), where its site is (two separate domains: .com for the main site, .org for the email, legal stuff, and BT tracker).
I am planning on using XBTT as the tracker and XBTC + web interface as the seed client. My main (and only, as of yet) problem is that there are no instructions on the XBTT site or Arch wiki for using Arch with XBT(T/C). I guess the only difference is getting the tools needed. Are these included with Arch, in the main repos, or somewhere available for Arch? Also, would there be a conflict seeding from the same machine the tracker is on?
If that doesn't work, I'm thinking Opentracker. I don't expect too many peers but we might get Dugg, Slashdotted, Stumbled, or promoted by TPB (they like when bands release over BT). So, I want a tracker than can handle the unlikely event of a large number of peers.
Also, does anyone know of a Python frontend to XBTT? PHP is fine, but really prefer Python to integrate with the remainder of the site.
Thanks in advance,
Sajro

Answer 1

manasij7479 wrote:3.This should be an stfw type of question, but I'm really confused about which way to go for a remote desktop connection.
So, I'd like to hear any experience, positive or negative, on that matter.
Note that my main machine will have an extra monitor,on which I'd like to ocassionaly 'see' the server.
I second/third/forth screen. Ask yourself if you really need a GUI for a server--chances are, the answer is a "no." Screen is handy because you can detach it from anywhere and then resume right where you left off. ctrl+a followed by "d" to detach, screen -r to resume (or -rd if you need to resume and detach a running instance). GUIs are mostly overkill for this use case, IMO.
I have a very similar setup with a cheapish AMD CPU, large disks, and a fair amount of RAM running mostly as a file server/router/miscellaneous box (NFS/SMB, also as a web server, IPv6 gateway, and other odds and ends). I have one of the monitors of my desktop plugged into it in the event I actually need to see it (rare, but can happen if something occurs with the network).
I think you'll find after some experimentation that it's a lot easier to manage and run than you might expect. The same drawbacks that apply to Arch desktops apply to servers as well, probably more so: Regular maintenance updates aren't likely to happen depending on how you use the server, so you need to keep up on the news and bookmark important entries for whenever you do have time to update it. Be extra sure to update it only when you have an hour or two to spare, particularly if you come to rely on that machine to be up and running.
Perhaps the more serious drawback of having an always on (or almost always on) server is that you'll find far more uses for it than you originally anticipated.