Re: The Debian vote taking machinery (Very Long)
>>"Jason" == Jason Gunthorpe <jgg@debian.org> writes:
Jason> On Mon, 25 Feb 2002, Manoj Srivastava wrote:
>> In the current method, an incoming vote is fed to a script
>> that, on the fly, checks the signature on the message, queries the
>> LDAP for canonical information, generates a response, extracts the
>> vote information, and writes it out to a plain text database.
Jason> Aside from the last bit, this is the script I constructed for
Jason> Darren specifically for this purpose. It is essentially the
Jason> same script that is used by the LDAP gateway and does a large
Jason> wack of stuff to ensure validity of the PGP signed mails. I do
Jason> not recommend replacing it, it took a very long time to get
Jason> all the MIME crap right (stupid mailers not following
Jason> standards).
Umm. Are you implying that the MIME libraries out there don't
work? Well, if that is the case, people can vote using mailx or
something. (I find little merit in promoting non standards compliant
behaviour)
Jason> I think you actually have some of the details wrong, the front
Jason> end python script actually talks to a perl script that does
Jason> the back end processing (this is where the locking problems
Jason> you mention would be hiding)
I did not separate the different parrts of the current system,
true. But yes, it is Exim calling a puthon script that calls perl
scripts that write to a text database (and heaven help you if it
fails while writing the database)
Jason> Further, I think you are likely wrong about the locking. The
Jason> gpgwrapper script does fcntl locking and will only run a
Jason> single instance of it's child script. This is a bit hard to
Jason> see since it is a side effect of they way it uses its internal
Jason> replay cache..
I see. So Rauls patches were not required, through an obscure
side effect of an upstream library that could change. Pardon me while
I do not feel particularly reassured.
Jason> Currently all mail is spooled into a standard mail spool
Jason> immediately on recipit by Exim, this is 100% correct and
Jason> guarenteed. Exim also automatically BCC's to the vote
Jason> machinery, so the voter gets immediate feedback on the vote.
That's nice, though I think an immediate feedback is not
really required -- if you do not get a ack within, say, 12 hours,
that would be sufficient.
In order to generate that singe exit non zero to exim on the
forward, we are doing all the vote processing, incluyding a very
hairy database write, on the fly.
Jason> The vote machinery uses it's return code in the same way
Jason> procmail does to use exim as a queueing agent, this ensures no
Jason> mail is lost, everything is 100% certain to get a response or
Jason> a bounce.
Yes. The fact that the database could be lost, and there is no
easy way to replay from the collected mbox still remain.
Jason> Frankly, I do not think you will find any flaws (aside from
Jason> asthetic ones, the bounce failure responses are ugly as sin,
Jason> but correct..) in the current gpgwrapper script. I do not
Jason> think you will have time to complete and test a new vote
Jason> infrastructure in time (we did this last time, it sucked).
I think the problem was that the script tries to do way too
much at one go in order to feed a success/bounce back to the voter.
Simpler, modular, idempotent scripts can be done in the time
frame, I think.
manoj
--
He, in a few minutes ravished this fair creature, or at least would
have ravished her, if she had not, by a timely compliance, prevented
him. Henry Fielding, "Jonathan Wild"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: