debianqueued -- daemon for managing Debian upload queues ======================================================== Copyright (C) 1997 Roman Hodek $Id: README,v 1.20 1999/07/08 09:35:37 ftplinux Exp $ Copyright and Disclaimer ------------------------ This program is free software. You can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation: either version 2 or (at your option) any later version. This program comes with ABSOLUTELY NO WARRANTY! You're free to modify this program at your will, according to the GPL, and I don't object if you modify the program. But it would be nice if you could send me back such changes if they could be of public interest. I will try to integrate them into the mainstream version then. Installation ------------ debianqueued has been written for running a new Debian upload queue at ftp.uni-erlangen.de, but I tried to keep it as general as possible and it should be useable for other sites, too. If there should be non-portabilities, tell me about them and we'll try to get them fixed! Before installing debianqueued, you should have the following utilities installed: - pgp (needed for checking signatures) - ssh & Co. (but not necessarily sshd, only client programs used) - md5sum (for checking file integrity) - mkfifo (for creating the status FIFO) - GNU tar - gzip - ar (for analyzing .deb files) The daemon needs a directory of its own where the scripts reside and where it can put certain files. This directory is called $queued_dir in the Perl scripts and below. There are no special requirements where in the filesystem hierarchy this directory should be. All configurations are done in file 'config' in $queued_dir. For security reasons, the $queued_dir should not be in a public FTP area, and should be writeable (as the files in it) only for the user maintaining the local debianqueued. The file Queue.README and Queue.message in the distribution archive are examples for README and .message files to put into the queue directory. Modify them as you like, or don't install them if you don't like them... Running debianqueued -------------------- debianqueued is intended to run all time, not as a cron job. Unfortunately, you can't start it at system boot time automatically, because a human has to type in the pass phrase for the ssh key. So you have to start the daemon manually. The daemon can be stopped by simply killing it (with SIGTERM preferrably). SIGTERM and SIGINT are blocked during some operations, where it could leave files in a inconsistent state. So it make take some time until the daemon really dies. If you have the urgent need that it goes away immediately, use SIGQUIT. Please don't use SIGKILL except unavoidable, because the daemon can't clean up after this signal. For your convenience, the daemon can kill and restart itself. If you start debianqueued with a "-k" argument, it tries to kill a running daemon (and it complains if none is running.) If "-r" is on the command line, it tries to kill a running daemon first if there is one. (If not, it starts anyway, but prints a little warning.) If a daemon is running and a new one is started without "-r", you get an error message about this. This is to protect you from restarting the daemon without intention. The other script, dqueued-watcher, is intended as cron job, and it watches that the daemon is running, in case that it should crash sometimes. It also takes care of updating the Debian keyring files if necessary. You should enter it e.g. like 0,30 * * * * .../dqueued-watcher into your crontab. (Assuming you want to run it every 30 minutes, which seems a good compromise.) Both scripts (debianqueued and dqueued-watcher) need no special priviledges and thus can be run as an ordinary user (not root). You can create an own user for debianqueued (e.g. "dqueue"), but you need not. The only difference could be which ssh key is used for connects to the target host. But you can configure the file to take the ssh key from in the config file. The Config File --------------- The config file, $queued_dir/config, is plain Perl code and is included by debianqueued and dqueued-watcher. You can set the following variables there: - $debug: Non-zero values enable debugging output (to log file). The following are all programs that debianqueued calls. You should always use absolute pathnames! - $pgp, $ssh, $scp, $ssh_agent, $ssh_add, $md5sum, $mail, $mkfifo, $tar, $gzip, $ar Notes: o $mail should support the -s option for supplying a subject. Therefore choose mailx if your mail doesn't know -s. o $tar should be GNU tar, several GNU features are used (e.g. --use-compress-program). o $ar must be able to unpack *.deb files and must understand the 'p' command. Better check this first... If you don't define $ar (or define it to be empty), debianqueued won't be able to extract a maintainer address from .deb files. (Which isn't that disturbing...) - @test_binaries: All binaries listed in this variable are tested to be present before each queue run. If any is not available, the queue run is delayed. This test can be useful if those binaries reside on NFS filesystems which may be (auto-)mounted only slowly. It is specially annoying for users if pgp can't be found and a .changes is deleted. - $ssh_options: Options passed to ssh and scp on every call. General ssh configuration should be done here and not in ~/.ssh/config, to avoid dependency on the user's settings. A good idea for $ssh_options seems to be -o'BatchMode yes' -o'FallBackToRsh no' -o'ForwardAgent no' -o'ForwardX11 no' -o'PasswordAuthentication no' -o'StrictHostKeyChecking yes' - $ssh_key_file: The file containing the ssh key you want the daemon to use for connects to the target host. If you leave this empty, the default ~/.ssh/identity is used, which may or may not be what you want. - $incoming: This names the queue directory itself. Probably it will be inside the public FTP area. Don't forget to allow uploads to it in ftpaccess if you're using wu-ftpd. Maybe you should also allow anonymous users to rename files in that directory, to fix upload problems (they can't delete files, so they have to move the errorneous file out of the way). But this introduces a denial-of-service security hole, that an attacker renames files of other people and then a job won't be done. But at least the data aren't lost, and the rename command probably was logged by ftpd. Nevertheless, there's no urgent need to allow renamings, because the queue daemon deletes all bad files automatically, so they can be reuploaded under the same name. Decide on your own... - $keep_files: This is a regular expression for files that never should be deleted in the queue directory. The status file must be included here, other probable candicates are .message and/or README files. - $chmod_on_target: If this variable is true (i.e., not 0 or ""), all files belonging to a job are changed to mode 644 only on the target host. The alternative (if the variable is false, i.e. 0) is to change the mode already locally, after the sizes and md5 sums have been verified. The latter is the default. The background for this is the following: The files must be word-readable on master for dinstall to work, so they must be at least mode 444, but 644 seems more useful. If the upload policy of your site says that uploaded files shouldn't be readable for world, the queue daemon has to change the permission at some point of time. (scp copies a file's permissions just as the contents, so after scp, the files on the target have the same mode as in the queue directory.) If the files in the queue are mode 644 anyway, you don't need to care about this option. The default --to give word read permission in the queue already after some checks-- is obviously less restrictive, but might be against the policy of your site. The alternative keeps the files unreadable in the queue in any case, and they'll be readable only on the target host. - $statusfile: This is the name of the status file or FIFO, through which users can ask the daemon what it's currently doing. It should normally be in the queue directory. If you change the name, please don't forget to check $keep_files. See also the own section on the status file. If you leave $statusfile empty, the daemon doesn't create and manage a status file at all, if you don't want it. Unfortunately, dqueued-watcher's algorithm to determine whether it already has reported a missing daemon depends on the status file, so this doesn't work anymore in this case. You'll get dead daemon mails on every run of dqueued-watcher. - $statusdelay: If this number is greater than 0, the status file is implemented as a regular file, and updated at least every $statusdelay seconds. If $statusdelay is 0, the FIFO implementation is used (see status file section). - $keyring: The name of the PGP keyring the daemon uses to check PGP signatures of .changes files. This is usually $queued_dir/debian-keyring.pgp. It should contain exactly the keys of all Debian developers (i.e. those and no other keys). - $gpg_keyring: The name of the GnuPG keyring. The daemon now alternatively accepts GnuPG signatures on .changes and .commands files. The value here is usually $queued_dir/debian-keyring.gpg. It should contain only keys of Debian developers (but not all developers have a GPG key yet...). - $keyring_archive: Path of the debian-keyring.tar.gz file inside a Debian mirror. The file is "/debian/doc/debian-keyring.tar.gz" on ftp.debian.org, don't know where you mirror it to... Leave it empty if you don't have that file on your local machine. But then you'll have to update the keyring manually from time to time. - $keyring_archive_name: Name of the PGP keyring file in the archive $keyring_archive. Currently "debian-keyring*/debian-keyring.pgp". - $gpg_keyring_archive_name: Name of the GnuPG keyring file in the archive $keyring_archive. Currently "debian-keyring*/debian-keyring.gpg". - $logfile: The file debianqueued writes its logging data to. Usually "log" in $queued_dir. - $pidfile: The file debianqueued writes its pid to. Usually "pid" in $queued_dir. - $target: Name of the target host, i.e. the host where the queue uploads to. Usually "master.debian.org". (Ignored with "copy" upload method.) - $targetlogin: The login on the target to use for uploads. (Ignored with "copy" and "ftp" upload methods; "ftp" always does anonymous logins.) - $targetdir: The directory on the target to where files should be uploaded. On master.debian.org this currently is "/home/Debian/ftp/private/project/Incoming". - $max_upload_retries: This is the number how often the daemon tries to upload a job (a .changes + the files belonging to it). After that number is exhausted, all these files are deleted. - $log_age: This is how many days are waited before logfiles are rotated. (The age of the current log files is derived from the first date found in it.) - $log_keep: How many old log files to keep. The current logfile is what you configured as $logfile above, older versions have ".0", ".1.gz", ".2.gz", ... appended. I.e., all old versions except the first are additionally gzipped. $log_keep is one higher than the max. appended number that should exist. - $mail_summary: If this is set to a true value (not 0 and not ""), dqueued-watcher will send a mail with a summary of the daemon's acivities whenever logfiles are rotated. - $summary_file: If that value is a file name (and not an empty string), dqueued-watcher will write the same summary of daemon activities as above to the named file. This can be in addition to sending a mail. - @nonus_packages: This is a (Perl) list of names of packages that must be uploaded to nonus.debian.org and not to master. Since the queue daemon only can deal with one target, it can't do that upload and thus must reject the job. Generally you can treat this variable as a list of any packages that should be rejected. All the following timing variables are in seconds: - $upload_delay_1: The time between the first (failed) upload try and the next one. Usually shorter then $upload_delay_2 for quick retry after transient errors. - $upload_delay_2: The time between the following (except the first) upload retries. - $queue_delay: The time between two queue runs. (May not be obeyed too exactly... a few seconds deviation are normal). - $stray_remove_timeout: If a file not associated with any .changes file is found in the queue directory, it is removed after this many seconds. - $problem_report_timeout: If there are problems with a job that could also be result of a not-yet-complete upload (missing or too small files), the daemon waits this long before reporting the problem to the uploader. This avoids warning mails for slow but ongoing uploads. - $no_changes_timeout: If files are found in the queue directory that look like a Debian upload (*.tar.gz, *.diff.gz, *.deb, or *.dsc files), but aren't accompanied by a .changes file, then debianqueued tries to notify the uploader after $no_changes_timeout seconds about this. This value is somewhat similar to $problem_report_timeout, and the values can be equal. Since there's no .changes, the daemon can't never be sure who really uploaded the files, but it tries to extract the maintainer address from all of the files mentioned above. If they're real Debian files (except a .orig.tar.gz), this works in most cases. - $bad_changes_timeout: After this time, a job with persisting problems (missing files, wrong size or md5 checksum) is removed. - $remote_timeout: This is the maximum time a remote command (ssh/scp) may take. It's to protect against network unreliabilities and the like. Choose the number sufficiently high, so that the timeout doesn't inadventedly kill a longish upload. A few hours seems ok. Contents of $queued_dir ----------------------- $queued_dir contains usually the following files: - config: The configuration file, described above. - log: Log file of debianqueued. All interesting actions and errors are logged there, in a format similar to syslog. - pid: This file contains the pid of debianqueued, to detect double daemons and for killing a running daemon. - debian-keyring.pgp, debian-keyring.gpg: These are the PGP and GnuPG key rings used by debianqueued to verify the signatures of .changes files. It should contain the keys of all Debian developers and no other keys. The current Debian key ring can be obtained from ftp.debian.org:/debian/doc/debian-keyring.tar.gz. dqueued-watcher supports the facility to update this file automatically if you also run a Debian mirror. - debianqueued, dqueued-watcher: The Perl scripts. All filenames except "config" can be changed in the config file. The files are not really required to reside in $queued_dir, but it seems practical to have them all together... Details of Queue Processing --------------------------- The details of how the files in the queue are processed may be a bit complicated. You can skip this section if you're not interested in those details and everything is running fine... :-) The first thing the daemon does on every queue run is determining all the *.changes files present. All of them are subsequently read and analyzed. The .changes MUST contain a Maintainer: field, and the contents of that field should be the mail address of the uploader. The address is used for sending back acknowledges and error messages. (dinstall on master uses the same convention.) Next, the PGP or GnuPG signature of the .changes is checked. The signature must be valid and must belong to one of the keys in the Debian keyring (see config variables $keyring and $gpg_keyring). This ensures that only registered Debian developers can use the upload queue to transfer files to master. Then all files mentioned in the Files: field of the .changes are checked. All of them must be present, and must have correct size and md5 checksum. If any of this conditions is violated, the upload doesn't happen and an error message is sent to the uploader. If the error is a incorrect size/md5sum, the file is also deleted, because it has to be reuploaded anyway, and it could be the case that the uploader cannot easily overwrite a file in the queue dir (due to upload permission restrictions). If the error is a missing file or a too small file, the error message is hold back for some time ($problems_report_timeout), because they can also be result of an not-yet-complete upload. The time baseline for when to send such a problem report is the maximum modification time of the .changes itself and all files mentioned in it. When such a report is sent, the setgid bit (show as 'S' in ls -l listing, in group x position) on the .changes is set to note that fact, and to avoid the report being sent on every following queue run. If any modification time becomes greater than the time the setgid bit was set, a new problem report is sent, because obviously something has changed to the files. If a job is hanging around for too long with errors ($bad_changes_timeout), the .changes and all its files are deleted. The base for that timeout is again the maximum modification time as explained above. If now the .changes itself and all its files are ok, an upload is tried. The upload itself is done with scp. In that stage, various errors from the net and/or ssh can occur. All these simply count as upload failures, since it's not easy to distinguish transient and permanent failures :-( If the scp goes ok, the md5sums of the files on the target are compared with the local ones. This is to ensure that the transfer didn't corrupt anything. On any error in the upload or in the md5 check, the files written to the target host are deleted again (they may be broken), and an error message is sent to the uploader. The upload is retied $upload_delay_1 seconds later. If it fails again, the next retries have a (longer) delay $upload_delay_2 between them. At most $max_upload_retries retries are done. After all these failed, all the files are deleted, since it seems we can't move them... For remembering how many tries were alredy done (and when), debianqueued uses a separate file. Its name is the .changes' filename with ".failures" appended. It contains simply two integers, the retry count and the last upload time (in Unix time format). After a successfull upload, the daemon also checks for files that look like they belonged to the same job, but weren't listed in the .changes. Due to experience, this happens rather often with .orig.tar.gz files, which people upload though they're aren't needed nor mentioned in the .changes. The daemon uses the filename pattern _* to find such unneeded files, where the Debian revision is stripped from . The latter is needed to include .orig.tar.gz files, which don't have the Debian revision part. But this also introduces the possibility that files of another upload for the same package but with another revision are deleted though they shouldn't. However, this case seems rather unlikely, so I didn't care about it. If such files are deleted, that fact is mentioned in the reply mail to the uploader. If any files are found in the queue dir that don't belong to any .changes, they are considered "stray". Such files are remove after $stray_remove_timeout. This should be around 1 day or so, to avoid files being removed that belong to a job, but whose .changes is still to come. The daemon also tries to find out whether such stray files could be part of an incomplete upload, where the .changes file is still missing or has been forgotten. Files that match the patterns *.deb, *.dsc, *.diff.gz, or *.tar.gz are analyzed whether a maintainer address can be extracted from them. If yes, the maintainer is notified about the incomplete upload after $no_changes_timeout seconds. However, the maintainer needs not really be the uploader... It could be a binary-only upload for another architecture, or a non-maintainer upload. In these cases, the mail goes to the wrong wrong person :-( But better than not writing at all, IMHO... The status file --------------- debianqueued provides a status file for the user in the queue directory. By reading this file, the user can get an idea what the daemon is currently doing. There are two possible implementations of the status file: as a plain file, or as a named pipe (FIFO). Both have their advantages and disadvantages. If using the FIFO, the data printed (last ping time, next queue run) are always up to date, because they're interrogated (by a signal) just at the time the FIFO is opened for reading. Also, the daemon hasn't to care about the status file if nobody accesses it. The bad things about the FIFO: It is a potential portability problem, because not all systems have FIFOs, or they behave different than I expect... But the more severe problem: wu-ftpd refuses to send the contents of a FIFO on a FTP GET request :-(( It does an explicit check whether a file to be retrieved is a regular file. This can be easily patched [1], but not everybody wants to do that or can do that (but I did it for ftp.uni-erlangen.de). (BTW, there could still be problems (races) if more than one process try to read the status file at the same time...) The alternative is using a plain file, which is updated regularily by the daemon. This works on every system, but causes more overhead (the daemon has to wake up each $statusdelay seconds and write a file), and the time figures in the file can't be exact. $statusdelay should be a compromise between CPU wastage and desired accuracy of the times found in the status file. I think 15 or 30 seconds should be ok, but your milage may vary. If the status file is a FIFO, the queue daemon forks a second process for watching the FIFO (so don't wonder if debianqueued shows up twice in ps output :-), to avoid blocking a reading process too long until the main daemon has time to watch the pipe. The status daemon requests data from the main daemon by sending a signal (SIGUSR1). Nevertheless it can happen that a process that opens the status file (for reading) is blocked, because the daemon has crashed (or never has been started, after reboot). To minimize chances for that situation, dqueued-watcher replaces the FIFO by a plain file (telling that the daemon is down) if it sees that no queue daemon is running. [1]: This is such a patch, for wu-ftpd-2.4.2-BETA-13: --- wu-ftpd/src/ftpd.c~ Wed Jul 9 13:18:44 1997 +++ wu-ftpd/src/ftpd.c Wed Jul 9 13:19:15 1997 @@ -1857,7 +1857,9 @@ return; } if (cmd == NULL && - (fstat(fileno(fin), &st) < 0 || (st.st_mode & S_IFMT) != S_IFREG)) { + (fstat(fileno(fin), &st) < 0 || + ((st.st_mode & S_IFMT) != S_IFREG && + (st.st_mode & S_IFMT) != S_IFIFO))) { reply(550, "%s: not a plain file.", name); goto done; } Command Files ------------- The practical experiences with debianqueued showed that users sometimes make errors with their uploads, resulting in misnamed or corrupted files... Formerly they didn't have any chance to fix such errors, because the ftpd usually doesn't allow deleting or renaming files in the queue directory. (If you would allow this, *anybody* can remove/rename files, which isn't desirable.) So users had to wait until the daemon deleted the bad files (usually ~ 24 hours), before they could start the next try. To overcome this, I invented the *.command files. The daemon looks for such files just as it tests for *.changes files on every queue run, and processes them before the usual jobs. *.commands files must be PGP or GnuPG signed by a known Debian developer (same test as for *.changes), so only these people can give the daemon commands. Since Debian developers can also delete files in master's incoming, the *.commands feature doesn't give away any security. The syntax of a *.commands file is much like a *.changes, but it contains only two (mandatory) fields: Uploader: and Commands. Uploader: contains the e-mail address of the uploader for reply mails, and should have same contents as Maintainer: in a .changes. Commands: is a multi-line field like e.g. Description: or Changes:. Every continuation line must start with a space. Each line in Commands: contains a command for the daemon that looks like a shell command (but it isn't one, the daemon parses and executes it itself and doesn't use sh or the respective binaries). Example: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Uploader: Roman Hodek Commands: rm hello_1.0-1_i386.deb mv hello_1.0-1.dsx hello_1.0-1.dsc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBNFiQSXVhJ0HiWnvJAQG58AP+IDJVeSWmDvzMUphScg1EK0mvChgnuD7h BRiVQubXkB2DphLJW5UUSRnjw1iuFcYwH/lFpNpl7XP95LkLX3iFza9qItw4k2/q tvylZkmIA9jxCyv/YB6zZCbHmbvUnL473eLRoxlnYZd3JFaCZMJ86B0Ph4GFNPAf Z4jxNrgh7Bc= =pH94 -----END PGP SIGNATURE----- The only commands implemented at this time are 'rm' and 'mv'. No options are implemented, and filenames may not contain slashes and are interpreted relative to the queue directory. This ensures that only files there can be modified. 'mv' always takes two arguments. 'rm' can take any number of args. It also knows about the following shell wildcard chars: *, ?, and [...]. {..,..} constructs are *not* supported. The daemon expands these patterns itself and doesn't use sh for that (for security reasons). *.commands files are processed before the usual *.changes jobs, so if a commands file fixes a job so that it can be processed, that processing happens in the same queue run and no unnecessary delay is introduced. The uploader of a *.commands will receive a reply mail with a comment (OK or error message) to each of the commands given. The daemon not only logs the contents of the Uploader: field, but also the owner of the PGP/GnuPG key that was used to sign the file. In case you want to find out who issued some commands, the Uploader: field is insecure, since its contents can't be checked. Security Considerations ----------------------- You already know that debianqueued uses ssh & Co. to get access to master, or in general any target host. You also probably know that you need to unlock your ssh secret key with a passphrase before it can be used. For the daemon this creates a problem: It needs the passphrase to be able to use ssh/scp, but obviously you can't type in the phrase every time the daemon needs it... It would also be very ugly and insecure to write the passphase into some config file of the daemon! The solution is using ssh-agent, which comes with the ssh package. This agent's purpose is to store passphrases and give it to ssh/scp/... if they need it. ssh-agent has to ways how it can be accessed: through a Unix domain socket, or with an inherited file descriptor (ssh-agent is the father of your login shell then). The second method is much more secure than the first, because the socket can be easily exploited by root. On the other hand, an inherited file descriptor can be access *only* from a child process, so even root has bad chances to get its hands on it. Unfortunately, the fd method has been removed in ssh-1.2.17, so I STRONGLY recommend to use ssh-1.2.16. (You can still have a newer version for normal use, but separate binaries for debianqueued.) Also, using debianqueued with Unix domain sockets is basically untested, though I've heard that it doesn't work... debianqueued starts the ssh-agent automatically and runs ssh-add. This will ask you for your passphrase. The phrase is stored in the agent and available only to child processes of the agent. The agent will also start up a second instance of the queue daemon that notices that the agent is already running. Currently, there's no method to store the passphrase in a file, due to all the security disadvantages of this. If you don't mind this and would like to have some opportunity to do it nevertheless, please ask me. If there's enough demand, I'll do it. New Upload Methods ------------------ Since release 0.9, debianqueued has two new upload methods as alternatives to ssh: copy and ftp. The copy method simply moves the files to another directory on the same host. This seems a bit silly, but is for a special purpose: The admins of master intend to run an upload queue there, too, in the future to avoid non-anonymous FTP connections, which transmit the password in cleartext. And, additionally to simply moving the files, the queue daemon also checks the signature and integrity of uploads and can reject non-US packages. The ftp method uploads to a standard anon-FTP incoming directory. The intention here is that you could create second-level queue daemons. I.e., those daemons would upload into the queue of another daemon (and, for example, this could be the queue of the daemon on master). However, the ftp method still has some limitations: 1) Files in the target dir can't be deleted. 2) Uploaded files can't be verified as good as with the other methods. 3) $chmod_on_target often doesn't work. 4) The check for a writable incoming directory leaves temporary files behind. Ad 1): In anon-FTP incoming directories removing of files usually isn't allowed (this would widely open doors to denial-of-service attacks). But debianqueued has to remove files on the target as part of handling upload errors. So if an transmission error happens during a job, the bad file can't be deleted. On the next try, the file is already present on the target and can't be overwritten, so all the following tries will fail, too, except the upstream queue daemon has deleted them already. And if the .changes was among the files already (at least partially) uploaded, the daemon even will think that the whole job is already present on the target and will delete the job in its queue. Ad 2): Uploaded files are usually verified with md5sum if they're really the same as the originals. But getting the md5sum for a file on a FTP server usually isn't possible. It's currently handled as follows: If the server supports a SITE MD5SUM command (non-standard!), then this is used and you have the same checking quality. Otherwise, debianqueued falls back to only comparing the file sizes. This is better than nothing, but doesn't detected changed contents that don't result in size changes. Ad 3): Often SITE CHMOD (standard) isn't allowed in incoming directories. If this is the case, $chmod_on_target must be off, otherwise all uploads will fail. The mode of uploaded files if forced anyway by the FTP server in most cases. Ad 4): As you know, the queue daemon has a special check if the target directory is writable at all (it isn't during a freeze) to protect against repeated upload errors. (Jobs would be even deleted otherwise if the target dir is unaccessible for too long.) This check is performed by creating a test file and deleting it immediately again. But since in FTP incoming dirs deletion isn't permitted, the temporary file ("junk-for-writable-test-DATE") will remain there. As a partial fix, the daemon deletes such files immediately, it doesn't even wait for $stray_remove_timeout. So if the upload goes to the queue dir of an upstream debianqueued, those temporary files won't be there for long. These problems of the FTP method might be remove in future, if I have better ideas how to bypass the limitations of anon-FTP incoming directories. Hints welcome :-) # Local Variables: # mode: indented-text # End: