GENERAL
1.0 What is this for ?
Ans: Short answer - providing a "napster" like service for rpm files.
Longer answer - This tries to offer a means of locating and
subsequently downloading rpm files from a pc's connected to the net
temporarily (like on a dialup). So instead of downloading the rpm files
from the major sites, one has the option of locating the file on a
nearby (hop distance wise) pc and downloading it from him. Hopefully
this would be a faster alternative
1.1 You mean to say this would be faster than downloading them from foo.com ??
Ans: Well not really, if you have a good connectivity. More likely than not
foo.com has a pretty fat pipe going out of its server, with which a
modem connected weakling cannot really compete. However if your
connectivity is poor and foo.com is many hop distance away, this could
be an alternative. For instance 56kbps modems really have an upload
capacity of 32kbps, so theoretically one should get a speed of 4K when
downloading from such a pc. However the protocol does encourage,
downloading the same file in segemnts from multiple peers, in which
case it would be limited by the modem's download speed ( for a 56kbps
around 7k ).
1.2 Is this usefull ?
Ans: No. Broadband, which is just round the corner will soon make this
obsolete and unnecessary.
1.3 What about security, isnt downoading an executable from an untrusted host
dangerous ?
Ans: RPM packages by the well known packagers are always signed by PGP and/or
GPG. So as long as these are verified before installing it is safe.
1.4 Why only rpm files, I want to share any file ?
Ans: Applications allready exist for sharing *any* files. I would certainly
like to include debs, if someone can help me with them. The choice for
rpm were made for 3 reasons.
(i) rpm have an inherent authentication mechanism that makes it safe to
download them from untrusted hosts
(ii) the generic file sharing applications, do not provide those extra
bit of information required to download the *right* rpm. One does
need to know the name of the packager, version etc.
iii) Save tgz' rpm and debs happen to be the most downloaded files on a
linux box ;)
1.5 Why would anyone want to host this server application ?
Ans: The server will play no role in the actual transfer of file, and will
require, practically no disk space to host the service. Perhaps people
wouldnt mind hosting such a lightweight application.
1.6 So we dont need those local ftp mirrors any more ?
Ans: Oh no we need them by all and every means. This can never be a
replacement for a ftp mirror service. But for places were such a mirror
does not exist this could be a means by which a particular rpm spreads
among the local users, after some evangelist downloads it from the
distant ftp/http host.
1.7 Oh, so this is a p2p application ?
Ans: Wrong this is not, otherwise there wouldnt have been a server. But
puritianism aside it is a practical approximation.
1.8 Then why not use a real p2p like gnutella ?
Ans: Because the main idea was to save on bandwidth. This application is for
bandwidth scarce zones.
1.9 I see that the actual file transfer takes place over anonymous ftp. Arent
ftp insecure ?
Ans: Why re-invent the wheel when such an effective proven solution already
exists. Moreover ftp is not insecure, otherwise the net would have
collapsed long ago. Anonymous ftp do however get some bad press, but the
incidents are mostly caused by wrong configuration and running old and
buggy ftp daemons.
Running the latest wu-ftpd, pro-ftpd or bsd-ftpd should be OK. Both
pro-ftpd and bsd-ftpd are designed for heavy-weight ftp servers and have
been free of remote exploits since ages. But for home use, wu-ftpd
should be fine, but it should be the latest one.
Moreover, these being open source they are continuously scanned for bugs
and exploits, why not take the advantage of such a heck of a support
team.
1.10 Why write a network protocol, couldnt it have been done some otherway
Ans: This was just a way of doing it. One could wrap the service easilly over
http. Cgi/php can provide the server side features,like, for registering
uploads and answering queries. Javascript on the other handcan offer the
downloading feature on the client side. LDAP could also be a way of
maintaining the temporary index database.
With a seperate protocol we save a tiny bit of overhead as compared to http.
1.11 How safe is the protocol against mischief ?
Ans: Some of the possibilities that had to be guarded against were
unauthorised access to editing an index entry. That is B should not be
able to modify A's index entry. This is provided by 2 mechanisms.
i) All entries are associated with the machine IP's
ii) The peers recieve a token string on uploading for the first time.
Any modification to an existing entry requires this token string, in
addition to verification of IP address.
Thus it depends on how difficult it is to spoof an ip or guess a
token.
One can ofcourse label junk files as valid rpms. It is only after
downloading it that one wil get to know. Hopefully these pain in the
neck nuisance would not occur.
USAGE
2.0 How does one set the port on which to run this service ?
Ans: I am yet to set up a conf file reading feature. As of now, the code
itself is its conf file. However the tunable parameters have been grouped
together at the end. Change the value of SERVER_PORT to anything that
pleases you But remember, users need to be aware on which port the
service is running.
2.1 There seems to be many time related tunable parameters, what to they do ?
Ans: TTL this sets the time after which an index entry will be pulled
down unless renewed by the peer.
TIMEOUT this sets the maximum "connected" time for a client. The socket
automatically closes after this time. However if any changes has
been made to the entries, based on the connection request, it
is always acknowledged, well amost always.
AUTH_DELAY Requests for editing one's index, requires in addition to the
correct IP, an authenticating token. If the token provided by
the peer is wrong, the server closes the socket with an error
message. However the server waits for an AUTH_DELAY before doing
that, presumably to discourage guessing games.
2.2 How does one control the memory usage for this service ?
Ans: The current version offers a very crude means of controlling the memory
footprint. This will probably improve. The variables are:
MAX_STORE_LENGTH The maximum size of the entry that can be stored
This is the combied size of the index entry which
consists of rpm file data, path, id-token and ftp
path.
MAX_SHARED The maximum number of files any peer is allowed to
share or upload indices of.
MAX_PEERS The maximum number of peers, that the server will
hold entries for.
2.3 How does one verify the signature of an rpm file ?
Ans: Use "rpm --checksig <rpm filename>" or rpm -K <rpm filename>. If this
returns silently the packages are OK. However its a bit disconcerting to
get no feedback, so its better to add a "v" i.e. "rpm -Kv <file name>".
It will check for the size, Md5 and the GPG/PGP signature of the file.
2.4 I tried it on authentic rpm files, but I still get PGP not OK ?
Ans: You need to add the PGP or the GPG public keys of the packagers in your
list of trusted keys. Get them from their websites. If you get their
GPG key, add it to your list by "gpg -import <signature file>". You can
verify that they have been added by "gpg --list-keys"
If you have pgp installed, yu can use the PGP keys. One does it as
pgp -ka <signature file>.
2.5 What is this warning I get about " WARNING: This key is not certified with a trusted signature!" ?
Ans: Neither, PGP or GPG have a central body which doles out keys to people
or where one can register one's signature keys. In abscence of such a
registering body, they have a hierarchical flow of trust. In this,
anyone having an endorsed key can attest the key of someone else. So
when person A attests the signature of person B, this information
automatically gets encoded in B's signature.
What the warning is claiming is that, the key that verified the rpm was
not attested by anybody. But since you got the keys directly from the
packager, you dont have to worry.