diff options
Diffstat (limited to 'tupkg')
| -rw-r--r-- | tupkg/README.txt | 99 | ||||
| -rwxr-xr-x | tupkg/client/tupkg | 19 | ||||
| -rwxr-xr-x | tupkg/server/tupkgs | 22 |
3 files changed, 140 insertions, 0 deletions
diff --git a/tupkg/README.txt b/tupkg/README.txt new file mode 100644 index 00000000..47facc46 --- /dev/null +++ b/tupkg/README.txt @@ -0,0 +1,99 @@ +TU Packaging Tools (tupkg) +-------------------------- +- client side (python for proof of concept, later re-write to C?) + The main purpose of this tool is to upload the compiled + pkg.tar.gz to the server. It can (should?) do some verification + on the package prior to uploading to the server. It will have + a config file to store run-time information such as username + (email), password, and server name. + +- server side (python for proof of concept, later re-write to C?) + The server side will handle incoming connections from its client + side counterpart. The server should bind to port 80 (maybe a + vhost such as tupkg.archlinux.org?) so that firewalls won't be + an issue. The server verifies the client authentication data, + and then accepts the package(s). If port 80 is not available, + perhaps 443, or are there other 'standard' ports that usually + do not get filtered? + + I think the server should be multithreaded to handle simultaneous + uploads rather than queue up requests. The download should be + stored in a temp directory based on the username to prevent + directory, filename clashes. + + Once the package(s) is uploaded, the server can either kick off + a gensync, or we can write a separate script to call gensync once + or twice a day. My preference would be a separate script to call + gensync (like the *NIX philosophy of one tool per task). + +- protocol (c: => client, s: => server) + Whenever the client/server exchange a message, it is always + preceeded by two-bytes representing the following message's + length. For example, when the client connects, it will send: + + 0x0028username=bfinch@example.net&password=B0b + + 0x0028 is the 40 byte strlen of the message in two-bytes. The + client and server always read two-bytes from the socket, and + then know how much data is coming and can read that amount of + bytes from the socket. + + ==> authentication + c: username=emailaddy&password=mypassword + s: result=PASS|FAIL + + NOTE: We can add encryption easily enough with the python + version using the socket.ssl method. + + ==> uploading package data + if PASS: + + c: numpkgs=2&name1=p1.pkg.tar.gz&size1=123&md5sum1=abcd\ + name2=p2.pkg.tar.gz&size2=3&md5sum2=def1 + s: numpkgs=2&name1=p1.pkg.tar.gz&size1=119&\ + name2=p2.pkg.tar.gz&size2=0 (*) + + (*) NOTE: The server will reply back to the client how many + packages it has already received and its local file size. + This way, the client can resume an upload. In the example + above, the server still needs the last four (123-119) bytes + for the first package, and that it has no part of the + second package. The client would then begin sending the + last four bytes from the first package (p1.pkg.tar.gz) and + then follow it with the full second package (p2.pkg.tar.gz). + The data would be sent as a continuous chunk of data. The + server will then need to track which bytes belong to which + package. + + else FAIL: + c: -spits out error message on stderr to user- + + + ==> after upload completes + The server should verify the integrity of the uploaded packages + by doing an md5sum on each and sending the info back to the client + for comparison. After sending the message, the server waits for + the 'ack' message from the client and then closes the connection. + + s: np=2&m1=PASS&m2=FAIL + c: ack + + The client replies with the 'ack' and then closes its connection + to the server. It then reports the PASS/FAIL status of each + package's upload attempt. + + NOTE: If the upload fails (client connection dies), the server + keeps any data it has received in order to support resuming an + upload. However, if the client uploads all data, and the server + successully reads all data and the final MD5 fails, the server + deletes the failed package. + + +Terms/definitions: +====================== +TU - No change (trusted by the community, if anyone asks what trust + means) +TUR - renamed to Arch User-community Repo (AUR) (so we can use -u for + versions) +Incoming - renamed to "Unsupported" + diff --git a/tupkg/client/tupkg b/tupkg/client/tupkg new file mode 100755 index 00000000..ab42b437 --- /dev/null +++ b/tupkg/client/tupkg @@ -0,0 +1,19 @@ +#!/usr/bin/python -O +# +# Description: +# ------------ +# This is the client-side portion of the Trusted User package +# manager. The TUs will use this program to upload packages into +# the AUR. For more information, see the ../README.txt file. +# +# Python Indentation: +# ------------------- +# Use tabs not spaces. If you use vim, the following comment will +# configure it to use tabs. +# vim: ts=2 sw=2 noet ft=python +# + + + +# TODO write the code +# diff --git a/tupkg/server/tupkgs b/tupkg/server/tupkgs new file mode 100755 index 00000000..2c410a5c --- /dev/null +++ b/tupkg/server/tupkgs @@ -0,0 +1,22 @@ +#!/usr/bin/python -O +# +# Description: +# ------------ +# This is the server-side portion of the Trusted User package +# manager. This program will receive uploads from its client-side +# couterpart, tupkg. Once a package is received and verified, it +# is placed in a specified temporary incoming directory where +# a separate script will handle migrating it to the AUR. For +# more information, see the ../README.txt file. +# +# Python Indentation: +# ------------------- +# Use tabs not spaces. If you use vim, the following comment will +# configure it to use tabs. +# vim: ts=2 sw=2 noet ft=python +# + + + +# TODO write the code +# |