REVU internals

[Stefan Potyra]

Hi,

sorry for abusing this mailing list, this mail is intended for whomever is 
helping out with revu-adminsitration.

So here's a small cheat sheet on REVU internals:

Uploads are uploaded to /home/ftp/incoming
Every 10 minutes, /srv/move_uploads.sh (as root) is run, to move the uploads 
(i.e. every file there) to /srv/uploads. This will in turn call 
process_uploads.sh.

process_uploads.sh will first verify the uploads against revu's keyring using 
dscverify (i.e. the changes-file is the key to the other files of an upload). 
If good, these are moved 
to /var/revu/revu1-incoming/<packagename>-<timestamp> (*), and get extracted 
there. The .changes file will get rights removed, so that it's not accessible 
from anyone.

(*) different path on spooky, but a symlink will guide you the way.

If its not accepted, the .changes-file is moved to /srv/uploads/rejected. This 
is what I've been dealing most often with.

Top 1) problem: key not in keyring.
-> check, who signed the changes file:
  gpg --verify blabla-version_source.changes
gpg --search-keys <thekeyyoujustfoundout>

-> guess the according LP account. Check if he/she is in the group 
ubuntu-universe-contributors *and* has a key registered in LP.

-> check, if this key is in revu's keyring as well
sudo -u revu1 /srv/revu-production/bin/revu-key list <keyid>

if not, the long way:
use revu-key update (run as revu1 as well), to synchronize the keyring with 
LP. Wait. Wait longer. Wait even longer.

I usually don't want to wait, and use this short alternative:
just import the key into the keyring (of course this works for any key, not 
just one which is registered in LP):
revu-key import <keyid> (run as revu1)

since all other files of an upload should still be in /srv/uploads, you can 
then just put back the changes file to /srv/uploads, and it will get picked 
up by move_uploads in the next run.

If things go wrong, you can also manually run move_uploads.sh (as root). The 
output might give some clue, on what's actually going wrong. When doing so, 
please make sure that you don't get in the way with the cronjob (or anyone 
else running move_uploads), I guess this might lead to duplicate package 
entries or have funny side effects.

User management:
I usually do this in the database directly *g*, but there are a bunch of 
scripts for this as well, (check /srv/revu-production/bin). Not too sure if 
all of these are still working though.

The "recover-password" is not working long time pain:
Usually, there's s.th. wrong with the key. Check that the key is 1) in revu's 
keyring and 2) it has an elg-e key attached. Also, make sure that the 
requested email is only associated to one key in revu's keyring (hint, 
revu-key will help).

Nuking:
Packages, that are nuked in the web frontend, are only removed from the 
database, and commands to really remove them from the server disk are 
accumulated in /srv/revu-production/removal.txt. Check this file (not that 
there suddenly appears a rm -rf / in there ;) and execute it with a shell of 
your liking.

Cheers,
    Stefan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20080323/7ec40ab2/attachment.pgp