Re: [Monotone-devel] Usher difficulties

[Ethan Blanton]

Richard Levitte - VMS Whacker spake unto us the following wisdom:
> In message <address@hidden> on Mon, 10 Apr 2006 09:48:49 -0400, Ethan Blanton 
> <address@hidden> said:
> eblanton> First, usher has not been updated to exec 'mtn' by default
> eblanton> rather than 'monotone'; this is not a big deal to work
> eblanton> around (usher -m mtn), but the default should probably be
> eblanton> changed.  A trivial patch is attached.
> 
> Applied, committed and pushed.

I saw that, thank you very much.

> eblanton> Second, with both the usher from 0.26-pre3 and the usher
> eblanton> from 0.26 as released, I am having trouble serving some
> eblanton> databases which worked in 0.26-pre2.  I am serving three
> eblanton> databases from three 'local' stanzas
> eblanton> (net.elitists.elb.configs.*, edu.purdue.cs.gsb.guide.*, and
> eblanton> net.elitists.ical.*), and when I try to connect to
> eblanton> net.elitists.elb.configs.fvwm, usher spawns a server for
> eblanton> net.elitists.ical.* and connects my pull to that server --
> eblanton> needless to say, this doesn't work.  A copy of my usher
> eblanton> server file is likewise attached.
> 
> Aha, yeah, the trouble is that usher was originally built to handle
> the distinction between different sub-servers by hostname only, and
> you use the same hostname for all of them.  I did make a change so it
> would accept several stanzas with the same hostname, but it seems I
> didn't look closely enough at the the rest of the code, so you're
> currently stuck with having to separate the sub-servers at a hostname
> level.
>
> I have the same goal as you, to have sub-servers differentiated by
> branch patterns as well as hostnames, so I'll take a closer look in a
> few days and see what can be done with it.

Ahh, interesting.  I assumed this was a regression, because it
previously worked OK for me -- but it's possible that this was simply
coincidence, as it appears to be dependent on the order of the stanza
definitions (the last-defined server appears to be the one it starts
with some reliability, according to a few naive tests).  I see this
(multiple databases from the same host) as a pretty useful use-case
for usher, given the way monotone servers work, so I look forward to 
your further review.  ;-)

> eblanton> (Additionally, usher dumps core on ^c, which isn't a huge
> eblanton> deal in and of itself, but makes me nervous -- it appears to
> eblanton> be double-destroying one of its data structures, but I
> eblanton> haven't had time to dig too deep.)
> 
> Hmm, well, since usher is just a communication proxy of sorts, I see
> that as a minor problem unless it introduces corruption into the
> network streams.  I'll parrot Nathaniel here by saying "patches
> welcome!" :-)

Of course, of course ... that is the way of open source.  :-) I'll
take a look if I get a chance, but honestly the C++ishness is quite a
put-off for me.  A brief look didn't show me the problem, it appears
that something is probably being explicitly deleted and then
implicitly destroyed by a destructor or something (WAG, not fact).
The only reason it concerns me is that if there is an actual corrupt
data structure (I don't think there is until shutdown), it could
present an opportunity for a clever (or not so clever) attacker to
inject code someplace we wouldn't like to see it.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

signature.asc
Description: Digital signature