Re: recovery status update
* Aaron M. Ucko <[EMAIL PROTECTED]> [2003-12-09 15:37]: > Although I agree that there is definitely something to be said for > this approach, I would like to note an additional issue with it: > > - how to verify that katie will process uploads as expected (I'd been > running dinstall -n, via dput -D; I suppose it would be possible to > upload separately to the mirror and test there, but that's awkward.) dinstall -n is not as useful as it was in the past. In the past, you'd have to wait until dinstall run to see whether your package is okay; nowadays, packages are checked regularly (I think every 15 minutes), so you get almost immediate feedback anyway. -- Martin Michlmayr [EMAIL PROTECTED]
Re: recovery status update
* Aaron M. Ucko <[EMAIL PROTECTED]> [2003-12-09 22:14]: > Clint Adams <[EMAIL PROTECTED]> writes: > > > - how to run madison and wanna-build > > I thought the idea was for the unrestricted mirror to include a > read-only copy of the database madison consults. Yes, the idea is to sync the Postgres database once a day (it basically only changes on dinstall time anyway). Then you can run madison on the mirror. -- Martin Michlmayr [EMAIL PROTECTED]
Re: recovery status update
* Julian Gilbey <[EMAIL PROTECTED]> [2003-12-09 09:49]: > - how to give developers the possibility of seeing what's in the queue > (daily rsyncs are not good enough for this; I've frequently pulled > packages from the accepted queue to check that bug fixes have been > correctly applied) The queue could theoretically just be rsynced every 15 minutes or so. -- Martin Michlmayr [EMAIL PROTECTED]
Re: recovery status update
On Tue, Dec 09, 2003 at 10:14:08PM -0500, Aaron M. Ucko wrote: > Clint Adams <[EMAIL PROTECTED]> writes: > > > - how to run madison and wanna-build > > I thought the idea was for the unrestricted mirror to include a > read-only copy of the database madison consults. > > wanna-build presumably needs more real-time access, though. Not really. Wanna-build keeps its own bdb database, based on the output of quinn-diff. Provided the wanna-build box has (semi-)realtime access to the Packages- and Sources-files on auric (a requirement because of the way security updates are handled), it could technically run anywhere. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "Stop breathing down my neck." "My breathing is merely a simulation." "So is my neck, stop it anyway!" -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: recovery status update
Aaron M. Ucko wrote: > Clint Adams <[EMAIL PROTECTED]> writes: > > >>- how to run madison and wanna-build > > > I thought the idea was for the unrestricted mirror to include a > read-only copy of the database madison consults. > > wanna-build presumably needs more real-time access, though. Maybe those tools could trigger updating of the mirror before they are actually executed. (Just a random thought, probably completely useless, but I might just be lucky.) Cheers T. pgpWbipYxsrHj.pgp Description: PGP signature
Re: recovery status update
Clint Adams <[EMAIL PROTECTED]> writes: > - how to run madison and wanna-build I thought the idea was for the unrestricted mirror to include a read-only copy of the database madison consults. wanna-build presumably needs more real-time access, though. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: recovery status update
> - how to run the DELAYED queue (to give the possibility of deleting > things from it or to see what's in it) > > - how to give developers the possibility of seeing what's in the queue > (daily rsyncs are not good enough for this; I've frequently pulled > packages from the accepted queue to check that bug fixes have been > correctly applied) - how to run madison and wanna-build
Re: recovery status update
Josip Rodin <[EMAIL PROTECTED]> writes: > On Tue, Dec 09, 2003 at 03:37:55PM -0500, Aaron M. Ucko wrote: >> - how to verify that katie will process uploads as expected (I'd been >> running dinstall -n, via dput -D; I suppose it would be possible to >> upload separately to the mirror and test there, but that's awkward.) > > Seems to me that, with proper checks before upload and a properly done > upload itself, dinstall -n is superfluous. I can't remember when was the > last time I got my stuff rejected by e.g. a competing upload, mistaken > number, or anything like that... And even if something does get rejected, > you only have to wait around five minutes to find out. Hm, yeah, I must admit that there's much less call for this now that automatic feedback occurs every 15 minutes rather than only once a day. >> I believe http://incoming.debian.org/ is functioning as usual (though >> it's a bit hard to tell shortly after a dinstall run ;-) ). Yep. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: recovery status update
On Tue, Dec 09, 2003 at 03:37:55PM -0500, Aaron M. Ucko wrote: > - how to verify that katie will process uploads as expected (I'd been > running dinstall -n, via dput -D; I suppose it would be possible to > upload separately to the mirror and test there, but that's awkward.) Seems to me that, with proper checks before upload and a properly done upload itself, dinstall -n is superfluous. I can't remember when was the last time I got my stuff rejected by e.g. a competing upload, mistaken number, or anything like that... And even if something does get rejected, you only have to wait around five minutes to find out. -- 2. That which causes joy or happiness.
Re: recovery status update
Julian Gilbey <[EMAIL PROTECTED]> writes: > It makes a lot of sense to restrict auric permanently and have an > up-to-date mirror for general access purposes. The issues I can think > of are: Although I agree that there is definitely something to be said for this approach, I would like to note an additional issue with it: - how to verify that katie will process uploads as expected (I'd been running dinstall -n, via dput -D; I suppose it would be possible to upload separately to the mirror and test there, but that's awkward.) > - how to run the DELAYED queue Extra ftp upload directories? sftp access to the full queue area? > - how to give developers the possibility of seeing what's in the queue I believe http://incoming.debian.org/ is functioning as usual (though it's a bit hard to tell shortly after a dinstall run ;-) ). Other queues, especially queue/new, can also be interesting to inspect, but mirror delay there would hardly be the end of the world. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: recovery status update
On Fri, Dec 05, 2003 at 01:51:54AM +, James Troup wrote: > Where can I login? > -- > > There's been a fair bit of talk post-compromise about restricting > access to machines running (core) services. At the moment, the only > thing I'm (personally) doing is not enabling non-services accounts on > auric (ftp-master) and klecker (security, non-US, qa, nm, www-master) > immediately. Obviously, it's useful for random developers to have > access to e.g. the postgres database of the archive, so the current > plan if the restricted nature of auric becomes permanent is to mirror > the system daily to another box that would be unrestricted. [This > would have the added bonus of giving us a hot spare for > disasters/arson attacks etc.] > > Basically the whole issue of what, if anything, to restrict is still > up in the air. I'm looking for input/opinions/discussion on this. If > you need access to the machines running the archives, please tell me > (or probably better yet, start a thread on debian-devel) why. It makes a lot of sense to restrict auric permanently and have an up-to-date mirror for general access purposes. The issues I can think of are: - how to run the DELAYED queue (to give the possibility of deleting things from it or to see what's in it) - how to give developers the possibility of seeing what's in the queue (daily rsyncs are not good enough for this; I've frequently pulled packages from the accepted queue to check that bug fixes have been correctly applied) Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: recovery status update
Steve Langasek wrote: > Hmm, I'm pretty sure the box is running stable, so this should be a > non-issue (for now). I see; thanks for the clarification. I just wanted to make sure... Roland
Re: recovery status update
On Fri, Dec 05, 2003 at 01:17:25PM +0100, Roland Bauerschmidt wrote: > James Troup wrote: > > As part of the recovery process, db.debian.org has migrated, both to a > > new host (because the old box was on it's last legs and HP kindly > > donated a shiny new one to replace it), and to a newer version of LDAP > > (because it was still using potato's OpenLDAP). > > Which exact version of OpenLDAP and which database backend are you > using? The BDB backend has severe problems if incorrectly configured > (i.e. a DB_CONFIG file is missing or the cachesize specified there is > too small). We're working on that at the moment; libdb4.2 4.2.51 is > supposed to fix the problem, though a correctly cachesize is still > important for performance. Hmm, I'm pretty sure the box is running stable, so this should be a non-issue (for now). Cheers, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: recovery status update
James Troup wrote: > As part of the recovery process, db.debian.org has migrated, both to a > new host (because the old box was on it's last legs and HP kindly > donated a shiny new one to replace it), and to a newer version of LDAP > (because it was still using potato's OpenLDAP). Which exact version of OpenLDAP and which database backend are you using? The BDB backend has severe problems if incorrectly configured (i.e. a DB_CONFIG file is missing or the cachesize specified there is too small). We're working on that at the moment; libdb4.2 4.2.51 is supposed to fix the problem, though a correctly cachesize is still important for performance. Roland
Re: recovery status update
Hi James, first let me thank you for your good work so far on the recovery of the debian machines. I just wanted to add one note: On [05/12/03 1:51], James Troup wrote: > Use the anonymous upload queue on ftp-master. I believe you want to > use something like "dupload --to anonymous-ftp-master foo.changes" for > dupload and "dput ftp-master foo.changes" for, err, dput. But I don't > use either of these programs and haven't tested that. The default configuration of dput was changed in the past to use the anonymous upload-queues. Only if people really want to use scp/rsync (like I do when testing new releases), it's necessary to specify the host. Otherwise it's enough if people use "dput foo.changes", if they haven't modified the default configuration (except for username. ;-) Christian -- Debian Developer (http://www.debian.org) 1024D/B7CEC7E8 44BD 1F9E A997 3BE2 A44F 96A4 1C98 EEF3 B7CE C7E8 pgpU4h5ObJ9DG.pgp Description: PGP signature
