sistpoty at ubuntu.com
Sun Mar 23 17:51:59 GMT 2008
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 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
(*) 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.
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).
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20080323/7ec40ab2/attachment.pgp
More information about the Ubuntu-motu