[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: