Re: [Monotone-devel] usher documentation
On 11/27/2015 07:03 AM, Hendrik Boom wrote: I'm specfically looking to find out how to get usher to reread the configuration file. It tries to be a good Unix daemon, and catches SIGHUP for this. There's also a command thru usherctl. Either it didn't work, or I don't know how to SUGHUP. I tried kill -1 After that the usher process was still running, but I couldn't connect to it. Actually killing it completely and then restarting it from scratch made it work again. Upon restarting, of course it read the new configuration. ...yep, it's broken. :( I pushed a couple new revisions on nvm.contrib.usher, one with a test that fails if it hangs on SIGHUP and one that makes that pass. The last revision 591a8f14... ought to work, or at least to fail differently if there are other related problems. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher documentation
On Sat, 21 Nov 2015 21:40:06 -0600, Timothy Brownawell wrote: > On 11/21/2015 07:47 PM, Hendrik Boom wrote: >> Where does usher documentation hide out now? > It's in doc/documentation.html . I don't know that this is available > online anywhere other than thru viewmtn. Found it in the source code, shich I still had lying around. Thanks. > >> I'm specfically looking to find out how to get usher to reread the >> configuration file. > It tries to be a good Unix daemon, and catches SIGHUP for this. There's > also a command thru usherctl. Either it didn't work, or I don't know how to SUGHUP. I tried kill -1 After that the usher process was still running, but I couldn't connect to it. Actually killing it completely and then restarting it from scratch made it work again. Upon restarting, of course it read the new configuration. -- hendrik > >> I suppose I can look up the process id with ps, kill it, and reissue >> the startup command, but is there a more elegant way? >> >> I seem wtill to be running usher-0.99, by the way. I suppose I should >> look for a newer one, too. > That's the only version that was ever released, altho I see > h:net.venge.monotone.contrib.usher does have later activity. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher documentation
On 11/21/2015 07:47 PM, Hendrik Boom wrote: Where does usher documentation hide out now? It's in doc/documentation.html . I don't know that this is available online anywhere other than thru viewmtn. I'm specfically looking to fine out how to get usher to reread the configuration file. It tries to be a good Unix daemon, and catches SIGHUP for this. There's also a command thru usherctl. I suppose I can look up the process id with ps, kill it, and reissue the startup command, but is there a more elegant way? I seem wtill to be running usher-0.99, by the way. I suppose I should look for a newer one, too. That's the only version that was ever released, altho I see h:net.venge.monotone.contrib.usher does have later activity. ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] usher documentation
Where does usher documentation hide out now? I'm specfically looking to fine out how to get usher to reread the configuration file. I suppose I can look up the process id with ps, kill it, and reissue the startup command, but is there a more elegant way? I seem wtill to be running usher-0.99, by the way. I suppose I should look for a newer one, too. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher locks db
In message on Fri, 25 May 2012 15:59:51 + (UTC), Hendrik Boom said: hendrik> Is there a reason for usher to keep a database locked after the netsync hendrik> is finished? hendrik> hendrik> I just sync'd from my laptop to my server using usher; a subsequent hendrik> attempt to checkout on the server (witout usher, of course) failed hendrik> because the database was locked. >From the source: // keep local servers around for this many seconds after the last // client disconnects from them (only accurate to ~10 seconds) int const server_idle_timeout = 60; Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher locks db
On Fri, 25 May 2012 15:59:51 +, Hendrik Boom wrote: > Is there a reason for usher to keep a database locked after the netsync > is finished? > > I just sync'd from my laptop to my server using usher; a subsequent > attempt to checkout on the server (witout usher, of course) failed > because the database was locked. Maybe I just didn't wait long enough? It's unlocked now, several hours later. Are there time-outs? --hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] usher locks db
Is there a reason for usher to keep a database locked after the netsync is finished? I just sync'd from my laptop to my server using usher; a subsequent attempt to checkout on the server (witout usher, of course) failed because the database was locked. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
In message <20110203160429.ga5...@topoi.pooq.com> on Thu, 3 Feb 2011 11:04:29 -0500, Hendrik Boom said: hendrik> I don't really see a big difference between the script being hendrik> protected and the separate file being protected. Unless the hendrik> file with the scripts gets to be huge with a lot of stuff hendrik> that doesn't need protection, of course. There's another point, and it's that if needed, a script is easier to upgrade (if need be) if the data is separate. We've been hitting that one a couple of times on code.monotone.ca. hendrik> > There's a little bit more done to check that the monotone server has hendrik> > started correctly. Usher waits for the server to output something and hendrik> > expects the first line to contain "beginning service". If that hendrik> > doesn't happen, it will consider the fork a failure, hence the error hendrik> > message. Maybe there should be a little bit more text explaining that hendrik> > one might get more answers from the appropriate log... hendrik> hendrik> Maybe the message should say that the monotone server failed hendrik> to start up correctly. That, after all, seems to be what's hendrik> being tested. When I saw the message that the fork failed, I hendrik> immediately started looking for ways that tthe executable hendrik> file 'mtn' might not be there or have the wrong permissions, hendrik> etc. etc. It's clearly better to look in the log file. If mtn can't be started, it will say "execvp failed". But you make a point here, that some of the messages are a bit cryptic and really require that you know usher by source... It could be smart to make sure they're are a little bit more verbose, and thereby comprehensible. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Thu, Feb 03, 2011 at 10:28:06AM +0100, Richard Levitte wrote:
> In message <20110203072618.ga27...@topoi.pooq.com> on Thu, 3 Feb 2011
> 02:26:18 -0500, Hendrik Boom said:
>
> When it comes to automatic starts, such as starting a monotone server
> under usher, this is of course a problem (as it is with all mechanisms
> that require a password). The solution still involves the
> get_passphrase hook (the deprecation is more for users than server
> maintainers), and make sure it's appropriately protected, or to use
> the expanded version contrib/get_passphrase_from_file.lua, which has
> the passphrases it need to cover in a separate file (which should be
> appropriately protected).
I don't really see a big difference between the script being protected
and the separate file being protected. Unless the file with the scripts
gets to be huge with a lot of stuff that doesn't need protection, of
course.
>
> hendrik> > hendrik> Or does it misreport a successful fork with an invalid
> hendrik> > hendrik> monotone command as a failed fork? Or ... (fill in the
> real
> hendrik> > hendrik> explanation here, please?)
> hendrik> >
> hendrik> > Well, an invalid command of some sort WOULD result in a failed
> fork,
> hendrik> > so that's definitely a plausible explanation. Check the log in
> hendrik> > {logdir}.
> hendrik>
> hendrik> Well, as long as the monotone process gets started, even if it
> hendrik> immediately complains and exits, the fork itself has succeeded, so
> at
> hendrik> the very least it's a misleading error message. But at this point
> hendrik> that's just a quibble.
>
> There's a little bit more done to check that the monotone server has
> started correctly. Usher waits for the server to output something and
> expects the first line to contain "beginning service". If that
> doesn't happen, it will consider the fork a failure, hence the error
> message. Maybe there should be a little bit more text explaining that
> one might get more answers from the appropriate log...
Maybe the message should say that the monotone server failed to
start up correctly. That, after all, seems to be what's being tested.
When I saw the message that the fork failed, I immediately started
looking for ways that tthe executable file 'mtn' might not be there or
have the wrong permissions, etc. etc.
-- hendrik
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
In message <20110203072618.ga27...@topoi.pooq.com> on Thu, 3 Feb 2011 02:26:18
-0500, Hendrik Boom said:
hendrik> On Wed, Feb 02, 2011 at 12:09:23AM +0100, Richard Levitte wrote:
hendrik> > In message <20110201200533.ga8...@topoi.pooq.com> on Tue, 1 Feb 2011
15:05:33 -0500, Hendrik Boom said:
hendrik> >
hendrik> > In your configuration file, you have a logdir setting. You
hendrik> > might want to look at the log file there (write.log, I believe).
hendrik>
hendrik> Yes.. There is oe now. I stopped looking because for a while there
hendrik> wasn't one, but one has now showed up. It seems to be asking me for a
hendrik> passphrase for key ID hend...@topoi.pooq.com {599fffe...}
hendrik>
hendrik> Presumably, monotone wants a passphrase wo start up in server mode.
hendrik>
hendrik> What's the recommended way to provide one nowadays? The method
hendrik> involving the get_passphrase hook that the tutorial says is deprecated
hendrik> because of insecurity? It does have to be available when there's no
hendrik> user logged in on the server machine.
When it comes to automatic starts, such as starting a monotone server
under usher, this is of course a problem (as it is with all mechanisms
that require a password). The solution still involves the
get_passphrase hook (the deprecation is more for users than server
maintainers), and make sure it's appropriately protected, or to use
the expanded version contrib/get_passphrase_from_file.lua, which has
the passphrases it need to cover in a separate file (which should be
appropriately protected).
hendrik> > hendrik> Or does it misreport a successful fork with an invalid
hendrik> > hendrik> monotone command as a failed fork? Or ... (fill in the real
hendrik> > hendrik> explanation here, please?)
hendrik> >
hendrik> > Well, an invalid command of some sort WOULD result in a failed fork,
hendrik> > so that's definitely a plausible explanation. Check the log in
hendrik> > {logdir}.
hendrik>
hendrik> Well, as long as the monotone process gets started, even if it
hendrik> immediately complains and exits, the fork itself has succeeded, so at
hendrik> the very least it's a misleading error message. But at this point
hendrik> that's just a quibble.
There's a little bit more done to check that the monotone server has
started correctly. Usher waits for the server to output something and
expects the first line to contain "beginning service". If that
doesn't happen, it will consider the fork a failure, hence the error
message. Maybe there should be a little bit more text explaining that
one might get more answers from the appropriate log...
Cheers,
Richard
--
Richard Levitte rich...@levitte.org
http://richard.levitte.org/
"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Wed, Feb 02, 2011 at 12:09:23AM +0100, Richard Levitte wrote:
> In message <20110201200533.ga8...@topoi.pooq.com> on Tue, 1 Feb 2011 15:05:33
> -0500, Hendrik Boom said:
>
> In your configuration file, you have a logdir setting. You might want
> to look at the log file there (write.log, I believe).
Yes.. There is oe now. I stopped looking because for a while there
wasn't one, but one has now showed up. It seems to be asking me for a
passphrase for key ID hend...@topoi.pooq.com {599fffe...}
Presumably, monotone wants a passphrase wo start up in server mode.
What's the recommended way to provide one nowadays? The method
involving the get_passphrase hook that the tutorial says is deprecated
because of insecurity? It does have to be available when there's no
user logged in on the server machine.
> hendrik> Or does it misreport a successful fork with an invalid
> hendrik> monotone command as a failed fork? Or ... (fill in the real
> hendrik> explanation here, please?)
>
> Well, an invalid command of some sort WOULD result in a failed fork,
> so that's definitely a plausible explanation. Check the log in
> {logdir}.
Well, as long as the monotone process gets started, even if it
immediately complains and exits, the fork itself has succeeded, so at
the very least it's a misleading error message. But at this point
that's just a quibble.
Thanks.
-- hendrik
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
In message <20110201200533.ga8...@topoi.pooq.com> on Tue, 1 Feb 2011 15:05:33
-0500, Hendrik Boom said:
hendrik> On Mon, Nov 08, 2010 at 02:04:46PM -0500, Hendrik Boom wrote:
hendrik> >
hendrik> > I guess now comes the inevitable flood of stupid questions as i try
to
hendrik> > make sense of the documentation.
hendrik> >
hendrik>
hendrik> Well, I have usher running, and depending on how I write the
hendrik> configuration file it reports I have one or two servers, called
"write",
hendrik> the one I want to start with, and "local", the one inherited form the
hendrik> example in the documentation.
hendrik>
hendrik> But when I try to sync with "write" from another computer, I geet
hendrik> problems:
hendrik>
hendrik> hendrik@notlookedfor:~/write/Melinda$ mtn sync
4691://topoi.pooq.com/write
hendrik> enter passphrase for key ID [hend...@notlookedfor.topoi.pooq.com]
(ad968be7...):
hendrik> mtn: connecting to 4691://topoi.pooq.com/write
hendrik> mtn: Received warning from usher: Cannot fork server.
hendrik> mtn: peer 4691://topoi.pooq.com/write IO terminated connection in
working state (error)
hendrik> mtn: error: I/O failure while talking to peer
4691://topoi.pooq.com/write, disconnecting
hendrik> hendrik@notlookedfor:~/write/Melinda$
In your configuration file, you have a logdir setting. You might want
to look at the log file there (write.log, I believe).
hendrik> Can I get usher to tell me what the command it uses really
hendrik> is, so I can try it in isolation?
Basically, if we say that {monotone} and {local} are the values of the
settings with corresponding names, it does this:
{monotone} server --bind=127.0.0.1:{randomport} {local}
hendrik> Or does it misreport a successful fork with an invalid
hendrik> monotone command as a failed fork? Or ... (fill in the real
hendrik> explanation here, please?)
Well, an invalid command of some sort WOULD result in a failed fork,
so that's definitely a plausible explanation. Check the log in
{logdir}.
--
Richard Levitte rich...@levitte.org
http://richard.levitte.org/
"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Mon, Nov 08, 2010 at 02:04:46PM -0500, Hendrik Boom wrote:
>
> I guess now comes the inevitable flood of stupid questions as i try to
> make sense of the documentation.
>
Well, I have usher running, and depending on how I write the
configuration file it reports I have one or two servers, called "write",
the one I want to start with, and "local", the one inherited form the
example in the documentation.
But when I try to sync with "write" from another computer, I geet
problems:
hendrik@notlookedfor:~/write/Melinda$ mtn sync 4691://topoi.pooq.com/write
enter passphrase for key ID [hend...@notlookedfor.topoi.pooq.com]
(ad968be7...):
mtn: connecting to 4691://topoi.pooq.com/write
mtn: Received warning from usher: Cannot fork server.
mtn: peer 4691://topoi.pooq.com/write IO terminated connection in working state
(error)
mtn: error: I/O failure while talking to peer 4691://topoi.pooq.com/write,
disconnecting
hendrik@notlookedfor:~/write/Melinda$
Presumably something is still wrong with my configuration.
It looks as if usher does recieve the connection, identifies the
correct server ("write") in the script below, and fails to fork to start the
server.
Hers's the configuration file (password replaced):
userpass"hendrik" "notthepasswordd"
monotone"/usr/local/bin/mtn" "-k" "hend...@topoi.pooq.com"
listenaddr "0.0.0.0:4691"
adminaddr "127.0.0.1:12345"
logdir "/farhome/hendrik/monotone/usher-log/"
server "write"
host"0.0.0.0"
pattern "com.pooq.hendrik.write*"
local "-d" "/farhome/hendrik/monotone/write.db"
server "local"
host"127.0.0.1"
pattern "*"
local "-d" "/usr/local/src/managed/my.db"
Now when I try to execute the command suggested by the monotone line,
/usr/local/bin/mtn -k hend...@topoi.pooq.com
the shell starts monotone OK, although of course monotone immediately
complains at length that it's an invalid commant. But from the shell, the
"fork" succeeds.
Can I get usher to tell me what the command it uses really is,
so I can try it in isolation? Or does it misreport a successful fork
with an invalid monotone command as a failed fork? Or ... (fill in
the real explanation here, please?)
By the way, looking at the computer where usher is running, for each
attempt to sync it gives me three requests to enter the passphrase
for hend...@topoi.pooq.com. But entering the passphrase there doesn't
seem to have any effect.
By the way, the monotone running on the usher machine is 0.99.1;
the version on the client machine is 0.48 -- the one distributed
recently in testing as 0.48.3
-- hendrik
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] usher comments
On Mon, Jan 31, 2011 at 09:09:33AM +0100, Richard Levitte wrote: > In message <20110131075604.ga14...@topoi.pooq.com> on Mon, 31 Jan 2011 > 02:56:04 -0500, Hendrik Boom said: > > hendrik> On Sat, Nov 20, 2010 at 02:22:37AM +0100, Richard Levitte wrote: > hendrik> > In message <20101119201102.ga25...@topoi.pooq.com> on Fri, 19 Nov > 2010 15:11:02 -0500, Hendrik Boom said: > hendrik> > > hendrik> > hendrik> (2) Is there a comment convention for the usher config > file? > hendrik> > > hendrik> > comment "This is a lengthy comment" > hendrik> > hendrik> The comment has to be in quotes? > hendrik> Are newlines allowed? > hendrik> Should this be documented in > hendrik> https://code.monotone.ca/p/contrib/page/UsherDocumentation/ > hendrik> ? > > Quoted from that page: > > The configuration file for usher approximately follows monotone's > "basic_io" format > > See http://monotone.thomaskeller.biz/docbuild/html/Formats.html#Formats > for the basic_io format. > > Maybe the usher documentation should point to the monotone > documentation for this. Actually, I've just discovered by accident that a '#' at the stat of a line seems to make the entire line be interpreted as a comment, quotes not needed. That seems not to be mentioned in either https://code.monotone.ca/p/contrib/page/UsherDocumentation/ or http://monotone.thomaskeller.biz/docbuild/html/Formats.html#Formats Thanks. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
In message <20110131075604.ga14...@topoi.pooq.com> on Mon, 31 Jan 2011 02:56:04 -0500, Hendrik Boom said: hendrik> On Sat, Nov 20, 2010 at 02:22:37AM +0100, Richard Levitte wrote: hendrik> > In message <20101119201102.ga25...@topoi.pooq.com> on Fri, 19 Nov 2010 15:11:02 -0500, Hendrik Boom said: hendrik> > hendrik> > hendrik> (2) Is there a comment convention for the usher config file? hendrik> > hendrik> > comment "This is a lengthy comment" hendrik> hendrik> The comment has to be in quotes? hendrik> Are newlines allowed? hendrik> Should this be documented in hendrik> https://code.monotone.ca/p/contrib/page/UsherDocumentation/ hendrik> ? Quoted from that page: The configuration file for usher approximately follows monotone's "basic_io" format See http://monotone.thomaskeller.biz/docbuild/html/Formats.html#Formats for the basic_io format. Maybe the usher documentation should point to the monotone documentation for this. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Sat, Nov 20, 2010 at 02:22:37AM +0100, Richard Levitte wrote: > In message <20101119201102.ga25...@topoi.pooq.com> on Fri, 19 Nov 2010 > 15:11:02 -0500, Hendrik Boom said: > > hendrik> (2) Is there a comment convention for the usher config file? > > comment "This is a lengthy comment" The comment has to be in quotes? Are newlines allowed? Should this be documented in https://code.monotone.ca/p/contrib/page/UsherDocumentation/ ? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher and older installations...
Actually, never mind that. A little more mind twisting and I got how to do this: server ".catchall." pattern "" local "--confdir=/etc/monotone" "--db=/var/lib/monotone/default.mtn" "--no-standard-rcfiles" "--rcfile=/etc/monotone/hooks.lua" "--keydir=/var/lib/monotone/keys" It plays perfectly together with other stanzas that has different server names and no pattern prefix :-) Cheers, Richard In message <20101125.104925.114451813.rich...@levitte.org> on Thu, 25 Nov 2010 10:49:25 +0100 (CET), Richard Levitte said: richard> Hey, richard> richard> I've had a look at usher for a bit, and I was wondering how one would richard> do a smooth transition from having a monotone server to having richard> something that's controlled with usher, and was thinking that a way to richard> do this is to have usher be a transparent drop in replacement. richard> richard> However, because usher really does require a server name (project richard> name?), complete transparency isn't possible. richard> richard> So, I was wondering, would this be at all interesting? richard> richard> I was imagining that a way to configure this would be with a catch all richard> stanza, like this: richard> richard> server "" richard> local "--confdir=/etc/monotone" "--db=/var/lib/monotone/default.mtn" "--no-standard-rcfiles" "--rcfile=/etc/monotone/hooks.lua" "--keydir=/var/lib/monotone/keys" richard> richard> (this is, by the way, how I'd set up usher so it could replace the richard> monotone server on Debian that's installed with the monotone-server richard> package) richard> richard> It is, of course, possible to do with a stanza like this: richard> richard> server "" richard> pattern "*" richard> local "--confdir=/etc/monotone" "--db=/var/lib/monotone/default.mtn" "--no-standard-rcfiles" "--rcfile=/etc/monotone/hooks.lua" "--keydir=/var/lib/monotone/keys" richard> richard> But that only works if the users pull like this: richard> richard> mtn pull mtn://host?* richard> richard> and not with the following (perfectly valid, because there is such a richard> branch in /var/lib/monotone/default.mtn): richard> richard> mtn pull mtn://host?cookie richard> richard> The reason for this is that the pattern in the usher configuration is richard> truly just a pattern prefix, not a true glob... And the question is, richard> really, how one compares one glob with another. richard> richard> So the question is, is there a good way to get the transparency that I richard> want? Is it desirable, not just by me? richard> richard> Cheers, richard> Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Usher and older installations...
Hey, I've had a look at usher for a bit, and I was wondering how one would do a smooth transition from having a monotone server to having something that's controlled with usher, and was thinking that a way to do this is to have usher be a transparent drop in replacement. However, because usher really does require a server name (project name?), complete transparency isn't possible. So, I was wondering, would this be at all interesting? I was imagining that a way to configure this would be with a catch all stanza, like this: server "" local "--confdir=/etc/monotone" "--db=/var/lib/monotone/default.mtn" "--no-standard-rcfiles" "--rcfile=/etc/monotone/hooks.lua" "--keydir=/var/lib/monotone/keys" (this is, by the way, how I'd set up usher so it could replace the monotone server on Debian that's installed with the monotone-server package) It is, of course, possible to do with a stanza like this: server "" pattern "*" local "--confdir=/etc/monotone" "--db=/var/lib/monotone/default.mtn" "--no-standard-rcfiles" "--rcfile=/etc/monotone/hooks.lua" "--keydir=/var/lib/monotone/keys" But that only works if the users pull like this: mtn pull mtn://host?* and not with the following (perfectly valid, because there is such a branch in /var/lib/monotone/default.mtn): mtn pull mtn://host?cookie The reason for this is that the pattern in the usher configuration is truly just a pattern prefix, not a true glob... And the question is, really, how one compares one glob with another. So the question is, is there a good way to get the transparency that I want? Is it desirable, not just by me? Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
In message <20101119201102.ga25...@topoi.pooq.com> on Fri, 19 Nov 2010 15:11:02 -0500, Hendrik Boom said: hendrik> (1) The listen addr in the sample script is 0.0.0.0:4691. hendrik> hendrik>The 4691 is the usual monotone port number. hendrik> hendrik>But I'm not familiar with IP to know what the 0.0.0.0 means. Does hendrik>it mean it listens on all interfaces on the machine? Yes. hendrik> (2) Is there a comment convention for the usher config file? comment "This is a lengthy comment" -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Mon, Nov 08, 2010 at 02:04:46PM -0500, Hendrik Boom wrote: > > I guess now comes the inevitable flood of stupid questions as i try to > make sense of the documentation. More stupid question. (1) The listen addr in the sample script is 0.0.0.0:4691. The 4691 is the usual monotone port number. But I'm not familiar with IP to know what the 0.0.0.0 means. Does it mean it listens on all interfaces on the machine? (2) Is there a comment convention for the usher config file? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote: > There is an actual release of usher available now. It's tagged as > usher-0.99 available from >mtn://monotone.ca/contrib?net.venge.monotone.usher > and there is a tarball available at >http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz I started over after compiling and installing mtn 0.99.1. I configured, compile, and ran the check and it passed, ending up by saying: Test finished. PASS test1 PASS: test/run-tests.sh = 1 test passed = make[1]: Leaving directory `/farhome/hendrik/dv/usher/usher-0.99' -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On 11/09/2010 10:31 PM, Hendrik Boom wrote: On Tue, Nov 09, 2010 at 08:50:26PM -0600, Timothy Brownawell wrote: On 11/08/2010 01:49 PM, Hendrik Boom wrote: On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote: There is an actual release of usher available now. It's tagged as usher-0.99 available from mtn://monotone.ca/contrib?net.venge.monotone.usher and there is a tarball available at http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz I did the ./configure, and make, and then I did make test I got a lot of stuff that looked like errors, but I suspect that the complete test environment wasn't available on my system. I don't, to my knowledge, have a server mtn://127.0.0.1:8691/prjek-s?net.prjek.separate or is that something the test scripts should have set up? . It works on at least Debian and FreeBSD. Using a Debian stable running on a 64-bit AMD64. It wants socat installed, and it doesn't properly handle when monotone sends the query string as part of the server name (it shouldn't do that and 0.99 doesn't, but I think 0.48 does). It really should handle that, and test against multiple monotone versions if available... If I understand you correctly, this is just a problem with the test suite, and not with usher itself? So I can just proceed to use usher without bothering with the tests? Yes. Of course, to be sure, I should install socat and repeat. And if I still have trouble, try with mtn 0.99? Is sending the query string as part of the server name a problem for usher, or just for the test suite? It's a problem for usher itself, I'll try to get it fixed in the next day or two. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Tue, Nov 09, 2010 at 08:50:26PM -0600, Timothy Brownawell wrote: > On 11/08/2010 01:49 PM, Hendrik Boom wrote: >> On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote: >>> There is an actual release of usher available now. It's tagged as >>> usher-0.99 available from >>> mtn://monotone.ca/contrib?net.venge.monotone.usher >>> and there is a tarball available at >>> http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz >> >> I did the ./configure, and make, and then I did make test >> I got a lot of stuff that looked like errors, but I suspect that the >> complete test environment wasn't available on my system. I don't, to my >> knowledge, have a server mtn://127.0.0.1:8691/prjek-s?net.prjek.separate >> or is that something the test scripts should have set up? >> >>> . It works on at least Debian and FreeBSD. >> >> Using a Debian stable running on a 64-bit AMD64. > > It wants socat installed, and it doesn't properly handle when monotone > sends the query string as part of the server name (it shouldn't do that > and 0.99 doesn't, but I think 0.48 does). It really should handle that, > and test against multiple monotone versions if available... If I understand you correctly, this is just a problem with the test suite, and not with usher itself? So I can just proceed to use usher without bothering with the tests? Of course, to be sure, I should install socat and repeat. And if I still have trouble, try with mtn 0.99? Is sending the query string as part of the server name a problem for usher, or just for the test suite? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On 11/08/2010 12:36 PM, Hendrik Boom wrote: Well, I did download the tarball, http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz and untarred it. The README file says The documentation is in doc/documentation.html. But there is no doc directory to be found in the tarball. Looks like I forgot to put it in EXTRA_DIST to have it included in the tarball, so it's only in the source tree. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On 11/08/2010 01:04 PM, Hendrik Boom wrote: On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote: There is an actual release of usher available now. It's tagged as usher-0.99 available from mtn://monotone.ca/contrib?net.venge.monotone.usher and there is a tarball available at http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz . It works on at least Debian and FreeBSD. You can also browse the source at http://code.monotone.ca/p/contrib/source/tree/t:usher-0.99/ and see the documentation at http://code.monotone.ca/p/contrib/source/file/t:usher-0.99/doc/documentation.html I guess now comes the inevitable flood of stupid questions as i try to make sense of the documentation. I'm not clear what happens to authentication. Have I messed something? The example configuration has the line monotone"mtn" "-k" "my_key" This suggests to me that the various monotones in the herd are going to be performing actions fot the user whose key is "my_key". What happens to the identity of the remote user who is initiating the sync operation? That's the server key, the same as you give to "mtn serve". The remote user still authenticates with their own key; this is the key the server uses to authenticate to them. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On 11/08/2010 01:49 PM, Hendrik Boom wrote: On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote: There is an actual release of usher available now. It's tagged as usher-0.99 available from mtn://monotone.ca/contrib?net.venge.monotone.usher and there is a tarball available at http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz I did the ./configure, and make, and then I did make test I got a lot of stuff that looked like errors, but I suspect that the complete test environment wasn't available on my system. I don't, to my knowledge, have a server mtn://127.0.0.1:8691/prjek-s?net.prjek.separate or is that something the test scripts should have set up? . It works on at least Debian and FreeBSD. Using a Debian stable running on a 64-bit AMD64. It wants socat installed, and it doesn't properly handle when monotone sends the query string as part of the server name (it shouldn't do that and 0.99 doesn't, but I think 0.48 does). It really should handle that, and test against multiple monotone versions if available... ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
Am 08.11.10 19:36, schrieb Hendrik Boom: > On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote: >> There is an actual release of usher available now. It's tagged as >> usher-0.99 available from >>mtn://monotone.ca/contrib?net.venge.monotone.usher > > This is what I've been waiting for! But my browser had other ideas ... > >> You can also browse the source at >>http://code.monotone.ca/p/contrib/source/tree/t:usher-0.99/ >> and see the documentation at >> >> http://code.monotone.ca/p/contrib/source/file/t:usher-0.99/doc/documentation.html > > Whe I enter this URL into my iceweasel browser, it tell me: > > You have chosen to open > >* documentation.html > > which is a: HTML Text > from: http://code.monotone.ca > > What should iceweasel do with this file? > > * Open with [ /usr/bin/galeon (default) ] > * Save File > * Do this automatically for files like this from now on. > > [ X cancel ] [ OK ] > > The drop-down menu that suggests using galeon (another browser) > presents me to choose between >[ /usr/bin/galeon (default) ] > and >Other... > > Is this weird, or what? Iceweasel not knowing what to do with HTML? > And suggesting handing it over to another browser? Its because individual files are represented with Content-disposition: attachment and that makes the browser open up the "save as" dialog. I linked the 0.99 version of the documentation now with a wiki page where you can just view it: http://code.monotone.ca/p/contrib/page/UsherDocumentation/ Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote:
> There is an actual release of usher available now. It's tagged as
> usher-0.99 available from
>mtn://monotone.ca/contrib?net.venge.monotone.usher
> and there is a tarball available at
>http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz
I did the ./configure, and make, and then I did make test
I got a lot of stuff that looked like errors, but I suspect that the
complete test environment wasn't available on my system. I don't, to my
knowledge, have a server mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
or is that something the test scripts should have set up?
> . It works on at least Debian and FreeBSD.
Using a Debian stable running on a 64-bit AMD64.
-- hendrik
make check-TESTS
make[1]: Entering directory `/farhome/hendrik/dn/usher/usher-0.99'
TESTDIR=/farhome/hendrik/dn/usher/usher-0.99/test-dir
Running test test1...
Copying scripts...
scripts
scripts/foobar.sh
bound to 127.0.0.1:23345
bound to 127.0.0.1:8691
Testing: serve example 127.0.0.1:25436
Testing: multipull 3 mtn://HOST/prjek-s?net.prjek.separate
mtn: misuse: database
/farhome/hendrik/dn/usher/usher-0.99/test-dir/test1/example.mtn does not exist
mtn: setting default server to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: setting default branch include pattern to 'net.prjek.separate'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: Received warning from usher: No server named 'prjek-s?net.prjek.separate'
mtn: error: I/O failure while talking to peer
mtn://127.0.0.1:8691/prjek-s?net.prjek.separate, disconnecting
mtn: setting default server to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: setting default branch include pattern to 'net.prjek.separate'
Testing: multipull 3 'mtn://HOST/prjek?net.prjek.{fnord,foobar}'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: Received warning from usher: No server named 'prjek-s?net.prjek.separate'
mtn: error: I/O failure while talking to peer
mtn://127.0.0.1:8691/prjek-s?net.prjek.separate, disconnecting
mtn: setting default server to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: setting default branch include pattern to 'net.prjek.separate'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek-s?net.prjek.separate
mtn: Received warning from usher: No server named 'prjek-s?net.prjek.separate'
mtn: error: I/O failure while talking to peer
mtn://127.0.0.1:8691/prjek-s?net.prjek.separate, disconnecting
mtn: setting default server to
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: setting default branch include pattern to 'net.prjek.{fnord,foobar}'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: Received warning from usher: No server named
'prjek?net.prjek.{fnord,foobar}'
mtn: error: I/O failure while talking to peer
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}, disconnecting
mtn: setting default server to
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: setting default branch include pattern to 'net.prjek.{fnord,foobar}'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: Received warning from usher: No server named
'prjek?net.prjek.{fnord,foobar}'
mtn: error: I/O failure while talking to peer
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}, disconnecting
Testing: multipull 3 mtn://HOST/example?org.example
mtn: setting default server to
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: setting default branch include pattern to 'net.prjek.{fnord,foobar}'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}
mtn: Received warning from usher: No server named
'prjek?net.prjek.{fnord,foobar}'
mtn: error: I/O failure while talking to peer
mtn://127.0.0.1:8691/prjek?net.prjek.{fnord,foobar}, disconnecting
mtn: setting default server to mtn://127.0.0.1:8691/example?org.example
mtn: setting default branch include pattern to 'org.example'
mtn: setting default branch exclude pattern to ''
mtn: doing anonymous pull; use -kKEYNAME if you need authentication
mtn: connecting to mtn://127.0.0.1:8691/example?org.example
mtn: Received warning from usher: No server named 'example?org.example'
mtn: error: I/O failure while talking to peer
mtn://127.0.0.1:8691/exampl
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote: > There is an actual release of usher available now. It's tagged as > usher-0.99 available from >mtn://monotone.ca/contrib?net.venge.monotone.usher > and there is a tarball available at >http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz > . It works on at least Debian and FreeBSD. > > You can also browse the source at >http://code.monotone.ca/p/contrib/source/tree/t:usher-0.99/ > and see the documentation at > > http://code.monotone.ca/p/contrib/source/file/t:usher-0.99/doc/documentation.html I guess now comes the inevitable flood of stupid questions as i try to make sense of the documentation. I'm not clear what happens to authentication. Have I messed something? The example configuration has the line monotone"mtn" "-k" "my_key" This suggests to me that the various monotones in the herd are going to be performing actions fot the user whose key is "my_key". What happens to the identity of the remote user who is initiating the sync operation? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Fri, Nov 05, 2010 at 11:46:03PM -0500, Timothy Brownawell wrote: > There is an actual release of usher available now. It's tagged as > usher-0.99 available from >mtn://monotone.ca/contrib?net.venge.monotone.usher This is what I've been waiting for! But my browser had other ideas ... > You can also browse the source at >http://code.monotone.ca/p/contrib/source/tree/t:usher-0.99/ > and see the documentation at > > http://code.monotone.ca/p/contrib/source/file/t:usher-0.99/doc/documentation.html Whe I enter this URL into my iceweasel browser, it tell me: You have chosen to open * documentation.html which is a: HTML Text from: http://code.monotone.ca What should iceweasel do with this file? * Open with [ /usr/bin/galeon (default) ] * Save File * Do this automatically for files like this from now on. [ X cancel ] [ OK ] The drop-down menu that suggests using galeon (another browser) presents me to choose between [ /usr/bin/galeon (default) ] and Other... Is this weird, or what? Iceweasel not knowing what to do with HTML? And suggesting handing it over to another browser? Well, I did download the tarball, >http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz and untarred it. The README file says The documentation is in doc/documentation.html. But there is no doc directory to be found in the tarball. Of course, when in the browser I select 'save file' and tell it where to put it, it saves it away nicely. Then iceweasel has no trouble showing me the contents of the saved file, which appears to be -- what else? -- documentation! -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
On Sat, Nov 06, 2010 at 06:36:38AM +0100, Richard Levitte wrote: > This is a piece of software I'd like to see debianised... > > I see there's an ld debian branch... I wonder whether it should be a replacement for monotone-server. In function, if not in name. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
This is a piece of software I'd like to see debianised... I see there's an ld debian branch... Cheers, Richard In message <4cd4dd8b.4080...@prjek.net> on Fri, 05 Nov 2010 23:46:03 -0500, Timothy Brownawell said: tbrownaw> There is an actual release of usher available now. It's tagged as tbrownaw> usher-0.99 available from tbrownaw>mtn://monotone.ca/contrib?net.venge.monotone.usher tbrownaw> and there is a tarball available at tbrownaw>http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz tbrownaw> . It works on at least Debian and FreeBSD. tbrownaw> tbrownaw> You can also browse the source at tbrownaw>http://code.monotone.ca/p/contrib/source/tree/t:usher-0.99/ tbrownaw> and see the documentation at tbrownaw> http://code.monotone.ca/p/contrib/source/file/t:usher-0.99/doc/documentation.html tbrownaw> tbrownaw> There will be a 1.0 release around the same time as monotone 1.0. tbrownaw> tbrownaw> -- tbrownaw> Timothy tbrownaw> tbrownaw> Free public monotone hosting: http://mtn-host.prjek.net -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] usher 0.99 release (name-based virtual hosting for monotone)
There is an actual release of usher available now. It's tagged as usher-0.99 available from mtn://monotone.ca/contrib?net.venge.monotone.usher and there is a tarball available at http://mtn-host.prjek.net/projects/webhost/files/usher-0.99.tar.gz . It works on at least Debian and FreeBSD. You can also browse the source at http://code.monotone.ca/p/contrib/source/tree/t:usher-0.99/ and see the documentation at http://code.monotone.ca/p/contrib/source/file/t:usher-0.99/doc/documentation.html There will be a 1.0 release around the same time as monotone 1.0. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] usher installation
Would there be documentation around for the installation, care, and feeding of usher? -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher
Am 11.06.2010 00:26, schrieb Timothy Brownawell: > On 06/09/2010 07:21 AM, Thomas Keller wrote: >> Am 17.04.2010 17:39, schrieb Timothy Brownawell: >>> On 04/15/2010 02:13 AM, Thomas Keller wrote: Let's concentrate first to put usher in a release-capable state so packagers (like me :) can pick it up. If it packaged I'll have a much easier way to convince the guys over there at indefero some time to install and configure it as monotone helper for the use case. >> >> Do you have this still on your schedule somewhere...? Is there anything >> I could help you out with? > > I got it so that 'make distcheck' works, so I suppose the only things > left are making sure it works on *bsd, and then properly documenting > which monotone client version is required for explicit server names to > work (right now it's documented as 0.48). I pushed a couple of documentation changes and other minor things which should make the first release a bit more "sound". Please go ahead and tweak things further as you like, otherwise I'd propose we should tag the current state as version 0.1 (or whatever you like) and release it on the wild. I thought it might be worthwhile to add "companion" projects such as mtn-browse, monotone-viz, guitone, TracMonotone and now usher to monotone's new download page, so people can easily pick these up together with monotone's packages. We'd include a short description, a link to the latest version and and optionally also link to the home page of the particular project. Wrt hosting I'd say it would be the easiest if you'd upload the tarball somewhere on your server or on SF. Thanks, Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher
On 06/09/2010 07:21 AM, Thomas Keller wrote: Am 17.04.2010 17:39, schrieb Timothy Brownawell: On 04/15/2010 02:13 AM, Thomas Keller wrote: Let's concentrate first to put usher in a release-capable state so packagers (like me :) can pick it up. If it packaged I'll have a much easier way to convince the guys over there at indefero some time to install and configure it as monotone helper for the use case. Seems reasonable. Hi Tim! Do you have this still on your schedule somewhere...? Is there anything I could help you out with? Thomas. I got it so that 'make distcheck' works, so I suppose the only things left are making sure it works on *bsd, and then properly documenting which monotone client version is required for explicit server names to work (right now it's documented as 0.48). -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher
Am 17.04.2010 17:39, schrieb Timothy Brownawell: > On 04/15/2010 02:13 AM, Thomas Keller wrote: >> Let's concentrate first to put usher in a release-capable state so >> packagers (like me :) can pick it up. If it packaged I'll have a much >> easier way to convince the guys over there at indefero some time to >> install and configure it as monotone helper for the use case. > > Seems reasonable. Hi Tim! Do you have this still on your schedule somewhere...? Is there anything I could help you out with? Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: netsync connection info cleanup Was: Re: [Monotone-devel] usher
On 04/15/2010 07:59 AM, Thomas Keller wrote: Am 15.04.2010 13:33, schrieb Thomas Keller: I played around with [mtn://-style uris] further, there are a couple of serious bugs in this feature. Apparently the uri scheme only works if a port (and may it only be the standard port 4691) is given and thats also the reason why the tests don't alert the problem, becase they always run a local mtn instance on the non-standard port. Furthermore, known-servers gets the complete URI instead of just the hostname set when the mtn uri is used: known-servers: mtn://guitone.thomaskeller.biz:4691 f814415176bf04178c64895b19ef99752159626d known-servers: mtn://guitone.thomaskeller.biz:4691?include=net.venge.monotone.guitone f814415176bf04178c64895b19ef99752159626d This leads to new entries each time the branch pattern changes only slightly and means also that the user is alerted of a "new server" each time. It needs to include everything up to the '?' I think. For file: or ssh: there could be different databases (on the same host for the case of ssh) that you want different patterns for (since it stores this now), and the default server would need to include the path if it's file: or ssh: . I don't had the time yet to debug this further, I only re-assured that parse_uri() itself doesn't seem to be the problem, because port-less URIs are tested there and the test succeeds. I started a new branch (net.venge.monotone.connection_info_cleanup) where I tried to fix some of the issues. mtn://server-style URIs with no port should work already, also the known-servers problem has been fixed. However there is a bug in our parse_uri() implementation: If no scheme (f.e. mtn://) is given, it treats the string as path rather than as hostname. This leads to the problem that the scheme-less default server setting we store in the db vars is not treated correctly and that a host which is entered by the user is now also parsed wrongly. As I said, I'd rather change the implementation of parse_uri than forcing the user to pull "mtn://monotone.ca" instead of just "monotone.ca"... This should work now. parse_uri() will check for things that look like only a hostname or ip address and maybe a port, and skip most of the logic. It also uses everything before the query string in the db vars, and also uses that for the 'peer' string in the network session. This is what gets sent to the usher, so giving mtn://monotone.ca/foobar?include=... would send "mtn://monotone.ca/foobar" to the usher where it currently sends only the hostname (and the normal way of "mtn sy monotone.ca ..." would still send just the hostname), which should make it possible to use usher with neither wildcard dns nor pattern-based dispatch. I'll try to refactor some of the code afterwards and move the parsing logic (also for include / exclude patterns) into netsync_connection_info. I started already by adding a get_port() method which either returns the default mtn port or a custom port parsed from the argument. Thomas. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher
On 04/15/2010 02:13 AM, Thomas Keller wrote: Am 15.04.2010 04:50, schrieb Timothy Brownawell: Finally, what speaks against integrating usher in monotone's base completly? As in make it all a single binary? Not sure what the benefit would be, Well, I haven't looked at the code and its probably too different from mtn's network code, but I imagined a new "proxy" mode in `mtn serve` which would do just what usher does today. And we'd instantly also get a server-side administrative console within mtn itself to manage the server's running netsync connections and server setups. But thats probably too much and too hard for now... Yeah, the code really is completely different. And probably not as good at the moment. Let's concentrate first to put usher in a release-capable state so packagers (like me :) can pick it up. If it packaged I'll have a much easier way to convince the guys over there at indefero some time to install and configure it as monotone helper for the use case. Seems reasonable. and I like the more modular approach. For instance I have a half-written usher library in C# somewhere, I imagine that sort of thing would be more difficult if usher was baked into monotone. Out of interest - what does this library do? It doesn't do much of anything at the moment. ;) Mostly it's (meant to end up) like the standalone c++ usher, except with the admin interface and serverlist reader replaced with a function-call interface. The idea being that it might be easier to integrate with something serving a website interface, although it would have the downside of needing to interrupt any netsync connections in order to change the frontend. Perhaps a better choice would just be to expand the admin interface so it can be used to add/delete server definitions, and then have a library to wrap that depends on the goals I guess, having a single daemon would be easier to set up but more disruptive to upgrade than a pair that talk to eachother. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher
On Wed, Apr 14, 2010 at 09:50:08PM -0500, Timothy Brownawell wrote: > On 04/14/2010 02:29 AM, Thomas Keller wrote: >> >> Thats right - I also wondered if its worthwhile to merge-into-dir usher >> to the main monotone tree and include it in the base distribution. Usher >> makes only very very little sense without monotone and if its packaged >> right with monotone, you would not need to spend time setting up a web >> page, bug tracker, etc pp, but the development of both could be >> synchronized. > > Hm. Or do we want a separate branch, with monotone and the various tools > (usher, viewmtn, guitone, mtn-viz) all merge-into-dir'ed into it? > >> Finally, what speaks against integrating usher in monotone's base completly? > > As in make it all a single binary? Not sure what the benefit would be, > and I like the more modular approach. For instance I have a half-written > usher library in C# somewhere, I imagine that sort of thing would be > more difficult if usher was baked into monotone. Usher can permanently monitor the incoming port, and start monotones on specific databases as needed (isn't that the way it works now?) This also means that some of those specific monotones can be started by users working on that server machine, and by users activating monotone by other protocols (such as ssh). There will be occasional mutual exclusion, but all these monotone databases remain mostly accessible. This would not be the case if there was just one binary, and just one permanent monotone process jealously owning its flock of data bases. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
netsync connection info cleanup Was: Re: [Monotone-devel] usher
Am 15.04.2010 13:33, schrieb Thomas Keller: > I played around with [mtn://-style uris] further, there are a couple of > serious bugs in > this feature. Apparently the uri scheme only works if a port (and may it > only be the standard port 4691) is given and thats also the reason why > the tests don't alert the problem, becase they always run a local mtn > instance on the non-standard port. > > Furthermore, known-servers gets the complete URI instead of just the > hostname set when the mtn uri is used: > > known-servers: mtn://guitone.thomaskeller.biz:4691 > f814415176bf04178c64895b19ef99752159626d > known-servers: > mtn://guitone.thomaskeller.biz:4691?include=net.venge.monotone.guitone > f814415176bf04178c64895b19ef99752159626d > > This leads to new entries each time the branch pattern changes only > slightly and means also that the user is alerted of a "new server" each > time. > > I don't had the time yet to debug this further, I only re-assured that > parse_uri() itself doesn't seem to be the problem, because port-less > URIs are tested there and the test succeeds. I started a new branch (net.venge.monotone.connection_info_cleanup) where I tried to fix some of the issues. mtn://server-style URIs with no port should work already, also the known-servers problem has been fixed. However there is a bug in our parse_uri() implementation: If no scheme (f.e. mtn://) is given, it treats the string as path rather than as hostname. This leads to the problem that the scheme-less default server setting we store in the db vars is not treated correctly and that a host which is entered by the user is now also parsed wrongly. As I said, I'd rather change the implementation of parse_uri than forcing the user to pull "mtn://monotone.ca" instead of just "monotone.ca"... I'll try to refactor some of the code afterwards and move the parsing logic (also for include / exclude patterns) into netsync_connection_info. I started already by adding a get_port() method which either returns the default mtn port or a custom port parsed from the argument. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher
Am 15.04.2010 09:13, schrieb Thomas Keller: > Am 15.04.2010 04:50, schrieb Timothy Brownawell: >>> Maybe there is a third way, which would require changes in monotone >>> though: what about picking the database / server to use for netsync >>> directly from the client? I vaguely remember that we introduced an URL >>> schema in monotone a couple of versions ago (0.40 or so) and while its >>> nowhere documented beside in NEWS (not even functional in 0.47 for me >>> anymore, I get a network error "service name resolution failed for: >>> mtn", but the lua test still seems to run through), >> >> Huh, that's not good. >> >> ...I don't get that error, but it's treating the whole thing as the >> pattern instead of parsing it out. Different behavior, maybe something's >> uninitialized? Something more to look at, I guess... > > I haven't looked into that any further, but I'm putting that on my > agenda. Especially since the unit tests still seem to run through this > might as well be some kind of weird local / shell error (I'm using zsh > here). I played around with it further, there are a couple of serious bugs in this feature. Apparently the uri scheme only works if a port (and may it only be the standard port 4691) is given and thats also the reason why the tests don't alert the problem, becase they always run a local mtn instance on the non-standard port. Furthermore, known-servers gets the complete URI instead of just the hostname set when the mtn uri is used: known-servers: mtn://guitone.thomaskeller.biz:4691 f814415176bf04178c64895b19ef99752159626d known-servers: mtn://guitone.thomaskeller.biz:4691?include=net.venge.monotone.guitone f814415176bf04178c64895b19ef99752159626d This leads to new entries each time the branch pattern changes only slightly and means also that the user is alerted of a "new server" each time. I don't had the time yet to debug this further, I only re-assured that parse_uri() itself doesn't seem to be the problem, because port-less URIs are tested there and the test succeeds. Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic information exchange might be retained for a period of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher
Am 15.04.2010 04:50, schrieb Timothy Brownawell: >> Maybe there is a third way, which would require changes in monotone >> though: what about picking the database / server to use for netsync >> directly from the client? I vaguely remember that we introduced an URL >> schema in monotone a couple of versions ago (0.40 or so) and while its >> nowhere documented beside in NEWS (not even functional in 0.47 for me >> anymore, I get a network error "service name resolution failed for: >> mtn", but the lua test still seems to run through), > > Huh, that's not good. > > ...I don't get that error, but it's treating the whole thing as the > pattern instead of parsing it out. Different behavior, maybe something's > uninitialized? Something more to look at, I guess... I haven't looked into that any further, but I'm putting that on my agenda. Especially since the unit tests still seem to run through this might as well be some kind of weird local / shell error (I'm using zsh here). >> it looks like it >> could be used for that: >> >> mtn://monotone.ca?include=...&exclude=... >> >> What about expanding this to >> >> mtn://monotone.ca/server?include=...&exclude=... >> >> and adding some logic the normal mtn server to bail out if the /server >> part is found for a non-usher server? > > The server can't tell the difference, so it can't know to bail. But then > it probably doesn't really matter. Well, the "server" part would probably be the same as some kind of new --server option we introduce for netsync and this needs to be serialized in the data stream to the server somehow, so of course once the code has been adapted for that, it should just ignore it. We might have to introduce another netsync version for this though. >> I'd also look into adding support for these kind of URIs to mtn clone, >> which currently still needs a branch argument. > > I suppose that should be >mtn://monotone.ca/server?branch=... > ? Out of my head I'd have said "use the `include`" argument and let clone check if only one include pattern is given (without expansion syntax), but it might be better to have a dedicated branch argument for that. The interesting question is how this argument is interpreted when used in "normal" netsync operations - especially when further `include` and `exclude` arguments are given. We could make it mutual exclusive, i.e. either let them give a branch argument or a list of include / exclude patterns, what do you think? >>> I suppose this isn't that big a deal, >>> might as well just tag current head as a release I guess? >> >> Thats right - I also wondered if its worthwhile to merge-into-dir usher >> to the main monotone tree and include it in the base distribution. Usher >> makes only very very little sense without monotone and if its packaged >> right with monotone, you would not need to spend time setting up a web >> page, bug tracker, etc pp, but the development of both could be >> synchronized. > > Hm. Or do we want a separate branch, with monotone and the various tools > (usher, viewmtn, guitone, mtn-viz) all merge-into-dir'ed into it? I don't think thats a good idea, because it puts the burden on the person which manages this branch to keep all tools compilable and running together, and at least for mtn-viz this is a problem, because nobody took up the maintenance from Olivier for this until now. No, I thought that only merging usher into monotone's dir makes the most sense, because its a very useful and probably quite often needed extension for monotone and we could tie both parts better together (f.e. you wouldn't need to use your own copied basicio class). Just as mtnopt is part of the distribution today, usher would be another supplement for multi-database serving. >> Finally, what speaks against integrating usher in monotone's base >> completly? > > As in make it all a single binary? Not sure what the benefit would be, Well, I haven't looked at the code and its probably too different from mtn's network code, but I imagined a new "proxy" mode in `mtn serve` which would do just what usher does today. And we'd instantly also get a server-side administrative console within mtn itself to manage the server's running netsync connections and server setups. But thats probably too much and too hard for now... Let's concentrate first to put usher in a release-capable state so packagers (like me :) can pick it up. If it packaged I'll have a much easier way to convince the guys over there at indefero some time to install and configure it as monotone helper for the use case. > and I like the more modular approach. For instance I have a half-written > usher library in C# somewhere, I imagine that sort of thing would be > more difficult if usher was baked into monotone. Out of interest - what does this library do? Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz Please note that according to the EU law on data retention, information on every electronic in
Re: [Monotone-devel] usher
On 04/14/2010 02:29 AM, Thomas Keller wrote: While the DNS-/hostname-based approach seems to be the best way to distinguish different projects, its not always possible to configure that easily, even though only a wildcard DNS entry is needed. I'm currently (seriously) looking into integrating mtn in indefero and they won't set up a DNS entry just to support another VCS, so pattern matching is (for now) the only possibility. But given the name clash you describe above its probably not the best. Makes sense. Maybe there is a third way, which would require changes in monotone though: what about picking the database / server to use for netsync directly from the client? I vaguely remember that we introduced an URL schema in monotone a couple of versions ago (0.40 or so) and while its nowhere documented beside in NEWS (not even functional in 0.47 for me anymore, I get a network error "service name resolution failed for: mtn", but the lua test still seems to run through), Huh, that's not good. ...I don't get that error, but it's treating the whole thing as the pattern instead of parsing it out. Different behavior, maybe something's uninitialized? Something more to look at, I guess... it looks like it could be used for that: mtn://monotone.ca?include=...&exclude=... What about expanding this to mtn://monotone.ca/server?include=...&exclude=... and adding some logic the normal mtn server to bail out if the /server part is found for a non-usher server? The server can't tell the difference, so it can't know to bail. But then it probably doesn't really matter. I'd also look into adding support for these kind of URIs to mtn clone, which currently still needs a branch argument. I suppose that should be mtn://monotone.ca/server?branch=... ? I suppose this isn't that big a deal, might as well just tag current head as a release I guess? Thats right - I also wondered if its worthwhile to merge-into-dir usher to the main monotone tree and include it in the base distribution. Usher makes only very very little sense without monotone and if its packaged right with monotone, you would not need to spend time setting up a web page, bug tracker, etc pp, but the development of both could be synchronized. Hm. Or do we want a separate branch, with monotone and the various tools (usher, viewmtn, guitone, mtn-viz) all merge-into-dir'ed into it? Finally, what speaks against integrating usher in monotone's base completly? As in make it all a single binary? Not sure what the benefit would be, and I like the more modular approach. For instance I have a half-written usher library in C# somewhere, I imagine that sort of thing would be more difficult if usher was baked into monotone. -- Timothy Free public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher
Hi Tim!
Am 14.04.2010 04:44, schrieb Timothy Brownawell:
>> What happens if somebody pulls or pushes changes with "com.project*" or
>> some other wildcard-using pattern to the server? Would this fail because
>> neither server would be able to respond? What would happen for a pattern
>> like "{com.project-1,com.project-2}"?
>
> Both would fail. It looks for servers where the server pattern is an
> initial substring of the client's include pattern, and IIRC uses the
> matching one with the longest pattern in the case of multiple matches.
Ok, I thought something similar.
>> What is the status of usher currently anyways? I haven't seen an
>> official release of it (no tags at least), but it seems to be proven
>> stable over the last couple of years. If there would be an offical
>> release, packagers would be able to pick it up easier and could provide
>> it as tool on top of monotone.
>
> I use a slightly modified version for mtn-host.prjek.net (it gets the
> list of servers by listing a directory instead of directly from a config
> file), and it seems to work well enough. This also uses only the
> hostname to select which server to use, like if you were to only specify
> "host" and not "pattern" line in the config file.
>
> The pattern-based dispatch really should be more intelligent I guess,
> expand all the braces and make sure all the parts match the same server
> (and just make for example having "com" on one server and "com.project"
> on another be a config error).
While the DNS-/hostname-based approach seems to be the best way to
distinguish different projects, its not always possible to configure
that easily, even though only a wildcard DNS entry is needed. I'm
currently (seriously) looking into integrating mtn in indefero and they
won't set up a DNS entry just to support another VCS, so pattern
matching is (for now) the only possibility. But given the name clash you
describe above its probably not the best.
Maybe there is a third way, which would require changes in monotone
though: what about picking the database / server to use for netsync
directly from the client? I vaguely remember that we introduced an URL
schema in monotone a couple of versions ago (0.40 or so) and while its
nowhere documented beside in NEWS (not even functional in 0.47 for me
anymore, I get a network error "service name resolution failed for:
mtn", but the lua test still seems to run through), it looks like it
could be used for that:
mtn://monotone.ca?include=...&exclude=...
What about expanding this to
mtn://monotone.ca/server?include=...&exclude=...
and adding some logic the normal mtn server to bail out if the /server
part is found for a non-usher server?
I'd also look into adding support for these kind of URIs to mtn clone,
which currently still needs a branch argument.
> I suppose this isn't that big a deal,
> might as well just tag current head as a release I guess?
Thats right - I also wondered if its worthwhile to merge-into-dir usher
to the main monotone tree and include it in the base distribution. Usher
makes only very very little sense without monotone and if its packaged
right with monotone, you would not need to spend time setting up a web
page, bug tracker, etc pp, but the development of both could be
synchronized.
Finally, what speaks against integrating usher in monotone's base completly?
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] usher
On 04/13/2010 07:12 PM, Thomas Keller wrote:
Hi!
I know usher is around for quite a long time now, but I just started
playing with it tonight. One thing I don't quite get is how instance
separation based on pattern matching is supposed to work - imagine you
have these two different setups
server "project-1"
pattern "com.project-1"
local "-d" "/path/to/project-1.mtn"
server "project-2"
pattern "com.project-2"
local "-d" "/path/to/project-2.mtn"
What happens if somebody pulls or pushes changes with "com.project*" or
some other wildcard-using pattern to the server? Would this fail because
neither server would be able to respond? What would happen for a pattern
like "{com.project-1,com.project-2}"?
Both would fail. It looks for servers where the server pattern is an
initial substring of the client's include pattern, and IIRC uses the
matching one with the longest pattern in the case of multiple matches.
What is the status of usher currently anyways? I haven't seen an
official release of it (no tags at least), but it seems to be proven
stable over the last couple of years. If there would be an offical
release, packagers would be able to pick it up easier and could provide
it as tool on top of monotone.
I use a slightly modified version for mtn-host.prjek.net (it gets the
list of servers by listing a directory instead of directly from a config
file), and it seems to work well enough. This also uses only the
hostname to select which server to use, like if you were to only specify
"host" and not "pattern" line in the config file.
The pattern-based dispatch really should be more intelligent I guess,
expand all the braces and make sure all the parts match the same server
(and just make for example having "com" on one server and "com.project"
on another be a config error). I suppose this isn't that big a deal,
might as well just tag current head as a release I guess?
--
Timothy
Free public monotone hosting: http://mtn-host.prjek.net
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] usher
Hi!
I know usher is around for quite a long time now, but I just started
playing with it tonight. One thing I don't quite get is how instance
separation based on pattern matching is supposed to work - imagine you
have these two different setups
server "project-1"
pattern "com.project-1"
local "-d" "/path/to/project-1.mtn"
server "project-2"
pattern "com.project-2"
local "-d" "/path/to/project-2.mtn"
What happens if somebody pulls or pushes changes with "com.project*" or
some other wildcard-using pattern to the server? Would this fail because
neither server would be able to respond? What would happen for a pattern
like "{com.project-1,com.project-2}"?
What is the status of usher currently anyways? I haven't seen an
official release of it (no tags at least), but it seems to be proven
stable over the last couple of years. If there would be an offical
release, packagers would be able to pick it up easier and could provide
it as tool on top of monotone.
Thomas.
--
GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] usher on BSD
Has anyone managed to use usher on any BSD host?
I managed to compile it with the following patch, but is still doesn't
work: it hangs on the first attempt of connections and must be then
kill-9'ed.
#
# old_revision [2f2e1e9d2e91998278fb7e4c9b7168aed96dc322]
#
# patch "src/administrator.cc"
# from [21179df6f7338fab09b61035dca2cb9a116dd8e6]
#to [79ca54c69501d3a75565e1b0a3feb45415fa9931]
#
# patch "src/server.cc"
# from [55442d680c936f59823a36aea57a25443955a99b]
#to [952b9ec1c689192b9e584142500bb1165b2c523d]
#
--- src/administrator.cc21179df6f7338fab09b61035dca2cb9a116dd8e6
+++ src/administrator.cc79ca54c69501d3a75565e1b0a3feb45415fa9931
@@ -22,6 +22,8 @@ using boost::lexical_cast;
#include
#include
+#include
+#include
namespace defaults
{
--- src/server.cc 55442d680c936f59823a36aea57a25443955a99b
+++ src/server.cc 952b9ec1c689192b9e584142500bb1165b2c523d
@@ -14,6 +14,11 @@ using std::cerr;
#include
#include
+#include
+#include
+#include
+#include
+
#include
using boost::lexical_cast;
--
Lapo Luchini - http://lapo.it/
“ECC curves are divided into three groups, weak curves, inefficient
curves, and curves patented by Certicom” (Peter Gutmann, 2001-08-10)
signature.asc
Description: OpenPGP digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Usher on BSD
usher doesn't compile on FreeBSD unless you add some headers: , in src/administrator.cc and ,,, in src/server.cc. I didn't (yet) check if the produced executable actually works. Did anyone perchance port/test it already on any BSD? Else, I'll probably test it in the weekend. -- Lapo Luchini - http://lapo.it/ “There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence.” (Jeremy S. Anderson) signature.asc Description: OpenPGP digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher documentation patch
In message <[EMAIL PROTECTED]> on Tue, 20 Jun 2006 19:35:27 +0200, Marcel van der Boom <[EMAIL PROTECTED]> said: marcel> While deploying i updated the usher.txt (README) file. Patch applied, and on server_manager.cc as well. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Usher documentation patch
We (xaraya) recently started using usher, from the net.venge.contrib.usher branch. We deployed it because we have multiple databases in use to separate our core, modules, themes and languages respectively. These database were served on different ports and usher looked like an attractive option to solve: 1. handling requests where people accidently forgot to specify the right port name, leading to revisions ending up in the wrong database 2. allowing to serve the databases on different machines while keeping the interface for users the same 3. early bail-out for 'wrong' branchnames (we use a pretty strict prefix policy for branches and feature branches) 4. easier firewall management. Items 1., 3. and 4. are in place for us now, i couldnt get the second to work. While deploying i updated the usher.txt (README) file. Patch attached. The changes in server.cc and server_manager.cc are specific to us, so probably not to be committed. marcel usherdoc.mtndiff Description: Binary data -- Marcel van der Boom HS-Development BV -- http://www.hsdev.com So! webapplicatie framework -- http://make-it-so.info smime.p7s Description: S/MIME cryptographic signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Usher pattern matching (was Re: [Monotone-devel] Usher crashes)
On Sat, May 13, 2006 at 11:19:19PM -0500, Timothy Brownawell wrote: > On Sat, 2006-05-13 at 23:29 -0300, Jeronimo Pellegrini wrote: > > And even if I try to make it match against pattern, it fails, > > because of the way operator== works for struct prefix. Is this > > intentional? Shouldn't it also do partial matches? > > It should, and I think now it does. Yes! It works now. :-) > As you can probably tell, this hasn't exactly had extensive testing > since being reorganized. ;-p That's OK -- we're testing it. Thanks for writing usher -- it's very useful! J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: Usher pattern matching (was Re: [Monotone-devel] Usher crashes)
On Sat, 2006-05-13 at 23:29 -0300, Jeronimo Pellegrini wrote:
> OK, I'll compile the problems I found before:
>
> > If I use:
>
> > server "main"
> > host "localhost"
> > pattern "info.aleph0"
> > local "-d" "/home/jeronimo/monotone/main.db" "*"
>
> > And try to sync brahch info.aleph0.my_branch
>
> It won't work.
>
> > Neither if I try:
> > pattern "info.aleph0.*"
>
> > But if I use:
> > pattern "info.aleph0.my_branch"
>
> It works, but only if I fix line 185 of server_manager::connect_to_server
> where it matches pattern against host:
>
> if (!srv && !pattern.empty() && !by_pattern.empty())
> {
> i = by_pattern.lower_bound(pattern);
> if (i != by_pattern.end() && i->first == prefix(host))
>
Um, that should be fixed now.
> And even if I try to make it match against pattern, it fails,
> because of the way operator== works for struct prefix. Is this
> intentional? Shouldn't it also do partial matches?
It should, and I think now it does.
As you can probably tell, this hasn't exactly had extensive testing
since being reorganized. ;-p
Tim
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Usher pattern matching (was Re: [Monotone-devel] Usher crashes)
OK, I'll compile the problems I found before:
> If I use:
> server "main"
> host "localhost"
> pattern "info.aleph0"
> local "-d" "/home/jeronimo/monotone/main.db" "*"
> And try to sync brahch info.aleph0.my_branch
It won't work.
> Neither if I try:
> pattern "info.aleph0.*"
> But if I use:
> pattern "info.aleph0.my_branch"
It works, but only if I fix line 185 of server_manager::connect_to_server
where it matches pattern against host:
if (!srv && !pattern.empty() && !by_pattern.empty())
{
i = by_pattern.lower_bound(pattern);
if (i != by_pattern.end() && i->first == prefix(host))
And even if I try to make it match against pattern, it fails,
because of the way operator== works for struct prefix. Is this
intentional? Shouldn't it also do partial matches?
J.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher crashes
> Right now I just need to find out why usher can't find the server, but
> it will eventually work. :-)
I found it.
If I use:
server "main"
host "localhost"
pattern "info.aleph0"
local "-d" "/home/jeronimo/monotone/main.db" "*"
And try to sync brahch:
info.aleph0.my_branch
Neither if I try:
server "main"
host "localhost"
pattern "info.aleph0.*"
local "-d" "/home/jeronimo/monotone/main.db" "*"
But if I use:
pattern "info.aleph0.my_branch"
it works.
It will not match. So it seems that I need to specify each branch in one
separate server?
I took a look at server_manager.cc, and found this:
if (!srv && !pattern.empty() && !by_pattern.empty())
{
i = --by_pattern.upper_bound(pattern);
if (i->first == prefix(host))
srv = i->second;
}
Is the inner if correct? Shouldn't it match against pattern, instead of
host?
Also, I tried to change "host" to "pattern", but it still doesn't match
my_branch (as above). I don't understand exactly what prefix::operator==
does.
I just started ot read the code, so I may be writing a lot of nonsense...
J.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher crashes
On Sat, May 13, 2006 at 06:16:36PM -0500, Timothy Brownawell wrote: > On Sat, 2006-05-13 at 12:22 -0300, Jeronimo Pellegrini wrote: > > Hi. > > I just compiled usher, and started it: > > > > $ ./usher -m "mtn -kmy_key" -a 127.0.0.1:1 usher.cfg > > It treats the -m argument as an executable name, not a command line. So > it'll be looking for an execuable named "mtn -kmy_key", not looking for > an execuable named "mtn" and giving the "-kmy_key" argument. Really I > should probably replace this argument with a line in the config file, > which could allow for this. Ah. I see... > I see it needs better documentation. > > It finds a matching server by first looking for one with a correct > 'host' line. If there isn't a matching host line, then it looks for a > matching 'pattern' line. > > The 'host' line is matched as a prefix of the hostname that the client > is given to talk to, and the 'pattern' line is matched as a prefix of > the include pattern. In each case, it takes the longest one that > matches. > > Note that the 'pattern' line is a string prefix of the include pattern, > not a glob. > > Also, you still have to provide the pattern argument that the serve > command requires in the 'local' line. And since it sounds like this > argument is going away soon, I'm not going to have it try to guess it. Well, I can see lots of problems with what I was doing! > This might be fixed now. Yep. It doesn't crash anymore! :-) Thanks a lot, Tim! Right now I just need to find out why usher can't find the server, but it will eventually work. :-) J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher crashes
On Sat, 2006-05-13 at 12:22 -0300, Jeronimo Pellegrini wrote:
> Hi.
> I just compiled usher, and started it:
>
> $ ./usher -m "mtn -kmy_key" -a 127.0.0.1:1 usher.cfg
It treats the -m argument as an executable name, not a command line. So
it'll be looking for an execuable named "mtn -kmy_key", not looking for
an execuable named "mtn" and giving the "-kmy_key" argument. Really I
should probably replace this argument with a line in the config file,
which could allow for this.
> usher.cfg has the following:
>
>
> userpass "jp" "no_I_wont_tell_you"
>
> server "phd"
> host "localhost"
> pattern "info.aleph0.phd*"
> local "-d" "/home/jeronimo/monotone/phd.db"
>
> server "main"
> host "localhost"
> pattern "info.aleph0.*"
> local "-d" "/home/jeronimo/monotone/main.db"
> =
>
> I hope that matching first "info.aleph0.phd*" and later "info.aleph0.*"
> is not a problem...
I see it needs better documentation.
It finds a matching server by first looking for one with a correct
'host' line. If there isn't a matching host line, then it looks for a
matching 'pattern' line.
The 'host' line is matched as a prefix of the hostname that the client
is given to talk to, and the 'pattern' line is matched as a prefix of
the include pattern. In each case, it takes the longest one that
matches.
Note that the 'pattern' line is a string prefix of the include pattern,
not a glob.
Also, you still have to provide the pattern argument that the serve
command requires in the 'local' line. And since it sounds like this
argument is going away soon, I'm not going to have it try to guess it.
> Now, from another host:
>
> ==
> $ mtn push rumi
> mtn: connecting to rumi
> mtn: error: I/O failure while talking to peer rumi, disconnecting
> ==
>
> And at rumi, who is running usher:
>
> ==
> Segmentation fault
> ==
>
> I ran usher under gdb (the same command line options were passed), and got
> this:
>
> =
> Program received signal SIGSEGV, Segmentation fault.
> server_manager::prefix::cmp (this=0xbfffeffc, [EMAIL PROTECTED]) at
> basic_string.h:269
> 269 { return &((reinterpret_cast<_Rep*> (_M_data()))[-1]); }
> (gdb) where
> #0 server_manager::prefix::cmp (this=0xbfffeffc, [EMAIL PROTECTED]) at
> basic_string.h:269
> #1 0x0805cee3 in server_manager::prefix::operator== (this=0xbfffeffc, [EMAIL
> PROTECTED]) at server_manager.cc:55
> #2 0x0806041f in server_manager::connect_to_server (this=0xbfffefd0, [EMAIL
> PROTECTED], [EMAIL PROTECTED]) at stl_tree.h:176
> #3 0x08056421 in channel::process_selected (this=0x8081810, [EMAIL
> PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at channel.cc:101
> #4 0x080675a9 in main (argc=6, argv=0x8081808) at stl_list.h:135
> ==
This might be fixed now.
> Also, I noticed that usher will start and pretend that everything is OK,
> even if one of the local databases does not exist. Maybe the server
> could exit with an error, or at least issue a warning?
It doesn't actually parse the arguments in the 'local', it just passes
them on to the server. So it can't know there's a problem until the
server fails to start.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher crashes
On Sat, May 13, 2006 at 05:20:49PM -0500, Timothy Brownawell wrote: > On Sat, 2006-05-13 at 12:27 -0300, Jeronimo Pellegrini wrote: > > Also... > > I just realized from the email I sent that usher is also not > > requiring the USERPASS command befor LIST and STATUS, and probably > > before any other command. > > Hmm, it seems I broke some things in the rewrite. This should be fixed > now. Yes, now it tells me that I should log in first. But it's still crashing :-( I'll try to do some more tests later, and post the results. J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher crashes
On Sat, 2006-05-13 at 12:27 -0300, Jeronimo Pellegrini wrote: > Also... > I just realized from the email I sent that usher is also not > requiring the USERPASS command befor LIST and STATUS, and probably > before any other command. Hmm, it seems I broke some things in the rewrite. This should be fixed now. > Also, I tried to use a wrong username and password, and usher did > not close the connection. Odd. It closes it when I try that. Tim ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher crashes
Also... I just realized from the email I sent that usher is also not requiring the USERPASS command befor LIST and STATUS, and probably before any other command. Also, I tried to use a wrong username and password, and usher did not close the connection. J. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Usher crashes
Hi.
I just compiled usher, and started it:
$ ./usher -m "mtn -kmy_key" -a 127.0.0.1:1 usher.cfg
usher.cfg has the following:
userpass "jp" "no_I_wont_tell_you"
server "phd"
host "localhost"
pattern "info.aleph0.phd*"
local "-d" "/home/jeronimo/monotone/phd.db"
server "main"
host "localhost"
pattern "info.aleph0.*"
local "-d" "/home/jeronimo/monotone/main.db"
=
I hope that matching first "info.aleph0.phd*" and later "info.aleph0.*"
is not a problem...
OK, so I did:
=
$ telnet localhost 1
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
LIST
main phd
Connection closed by foreign host.
$ telnet localhost 1
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
STATUS main
SLEEPING
Connection closed by foreign host.
==
OK, everything is there, and usher is running.
Now, from another host:
==
$ mtn push rumi
mtn: connecting to rumi
mtn: error: I/O failure while talking to peer rumi, disconnecting
==
And at rumi, who is running usher:
==
Segmentation fault
==
I ran usher under gdb (the same command line options were passed), and got this:
=
Program received signal SIGSEGV, Segmentation fault.
server_manager::prefix::cmp (this=0xbfffeffc, [EMAIL PROTECTED]) at
basic_string.h:269
269 { return &((reinterpret_cast<_Rep*> (_M_data()))[-1]); }
(gdb) where
#0 server_manager::prefix::cmp (this=0xbfffeffc, [EMAIL PROTECTED]) at
basic_string.h:269
#1 0x0805cee3 in server_manager::prefix::operator== (this=0xbfffeffc, [EMAIL
PROTECTED]) at server_manager.cc:55
#2 0x0806041f in server_manager::connect_to_server (this=0xbfffefd0, [EMAIL
PROTECTED], [EMAIL PROTECTED]) at stl_tree.h:176
#3 0x08056421 in channel::process_selected (this=0x8081810, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]) at channel.cc:101
#4 0x080675a9 in main (argc=6, argv=0x8081808) at stl_list.h:135
==
Also, I noticed that usher will start and pretend that everything is OK,
even if one of the local databases does not exist. Maybe the server
could exit with an error, or at least issue a warning?
Thanks,
J.
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher difficulties
In message <[EMAIL PROTECTED]> on Mon, 10 Apr 2006 16:09:52 +0200 (CEST), Richard Levitte - VMS Whacker <[EMAIL PROTECTED]> said: richard> In message <[EMAIL PROTECTED]> on Mon, 10 Apr 2006 09:48:49 -0400, Ethan Blanton <[EMAIL PROTECTED]> said: richard> richard> eblanton> Second, with both the usher from 0.26-pre3 and the richard> eblanton> usher from 0.26 as released, I am having trouble richard> eblanton> serving some databases which worked in 0.26-pre2. richard> eblanton> I am serving three databases from three 'local' richard> eblanton> stanzas (net.elitists.elb.configs.*, richard> eblanton> edu.purdue.cs.gsb.guide.*, and richard> eblanton> net.elitists.ical.*), and when I try to connect to richard> eblanton> net.elitists.elb.configs.fvwm, usher spawns a richard> eblanton> server for net.elitists.ical.* and connects my pull richard> eblanton> to that server -- needless to say, this doesn't richard> eblanton> work. A copy of my usher server file is likewise richard> eblanton> attached. richard> richard> Aha, yeah, the trouble is that usher was originally built to richard> handle the distinction between different sub-servers by richard> hostname only, and you use the same hostname for all of them. richard> I did make a change so it would accept several stanzas with richard> the same hostname, but it seems I didn't look closely enough richard> at the the rest of the code, so you're currently stuck with richard> having to separate the sub-servers at a hostname level. richard> richard> I have the same goal as you, to have sub-servers richard> differentiated by branch patterns as well as hostnames, so richard> I'll take a closer look in a few days and see what can be richard> done with it. I've been experimenting and thinking, and figured that I hadn't entirely understood how usher was meant to work. Basically, what I said is still how it is, for entries that have a hostname, they will be selected by hostname only. However, IF there is no entry with a matching hostname, usher will also check for a matching pattern. And this is actually the way it should be, usher is primarly built to provide so called virtual hosting, and only uses "virtual patterns" as a fallback. I've made a few changes in usher.cc, so it will tell you a bit better what happens, and I think that will be the extent of what I do with it. BTW, the fix I provided earlier wasn't at all about being able to have several entries with the same hostname, it was about avoiding segfaults when usher removed hosts or patterns from earlier entries when a new one with the same hostname of pattern was loaded. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher difficulties
Richard Levitte - VMS Whacker spake unto us the following wisdom: > In message <[EMAIL PROTECTED]> on Mon, 10 Apr 2006 09:48:49 -0400, Ethan > Blanton <[EMAIL PROTECTED]> 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Usher difficulties
In message <[EMAIL PROTECTED]> on Mon, 10 Apr 2006 09:48:49 -0400, Ethan Blanton <[EMAIL PROTECTED]> 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. 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. 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!" :-) Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Usher difficulties
First, usher has not been updated to exec 'mtn' by default rather than
'monotone'; this is not a big deal to work around (usher -m mtn), but
the default should probably be changed. A trivial patch is attached.
Second, with both the usher from 0.26-pre3 and the usher from 0.26 as
released, I am having trouble serving some databases which worked in
0.26-pre2. I am serving three databases from three 'local' stanzas
(net.elitists.elb.configs.*, edu.purdue.cs.gsb.guide.*, and
net.elitists.ical.*), and when I try to connect to
net.elitists.elb.configs.fvwm, usher spawns a server for
net.elitists.ical.* and connects my pull to that server -- needless to
say, this doesn't work. A copy of my usher server file is likewise
attached. (Additionally, usher dumps core on ^c, which isn't a huge
deal in and of itself, but makes me nervous -- it appears to be
double-destroying one of its data structures, but I haven't had time
to dig too deep.)
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
userpass usher-admin fakepass
server guide
host nestor.cs.purdue.edu
host localhost
pattern edu.purdue.cs.gsb.guide.*
local -k [EMAIL PROTECTED] -d /homes/eblanton/stuff/monotone/server/guide.mtn
edu.purdue.cs.guide*
server configs
host nestor.cs.purdue.edu
host localhost
pattern net.elitists.elb.configs.*
local -k [EMAIL PROTECTED] -d /homes/eblanton/stuff/monotone/server/configs.mtn
net.elitists.elb.configs.*
server ical
host nestor.cs.purdue.edu
host localhost
pattern net.elitists.ical*
local -k [EMAIL PROTECTED] -d /homes/eblanton/stuff/monotone/server/ical.mtn
net.elitists.ical*
#
# old_revision [512820e126f1c9d6e60612aff1e95f7fe3af983a]
#
# patch "contrib/usher.cc"
# from [599b754c575694458973cf7ecd5be5fd5a03c06d]
#to [fe0d5a16bd4b84cf969228c6e05f1cff85614379]
#
--- contrib/usher.cc599b754c575694458973cf7ecd5be5fd5a03c06d
+++ contrib/usher.ccfe0d5a16bd4b84cf969228c6e05f1cff85614379
@@ -16,7 +16,7 @@
// Usage: usher [-l address[:port]] [-a address:port] [-p pidfile]
//
// options:
-// -m the monotone command, defaults to "monotone"
+// -m the monotone command, defaults to "mtn"
// -l address and port to listen on, defaults to 0.0.0.0:4691
// -a address and port to listen for admin commands
// -p a file (deleted on program exit) to record the pid of the usher in
@@ -51,8 +51,8 @@
// A request to server "hostname" will be directed to the
// server at :, if that stem is marked as remote,
// and to a local server managed by the usher, started with the given
-// arguments ("monotone serve --bind=something "),
-// if it is marked as local.
+// arguments ("mtn serve --bind=something "), if it is
+// marked as local.
// Note that "hostname" has to be an initial substring of who the client asked
// to connect to, but does not have to match exactly. This means that you don't
// have to know in advance whether clients will be asking for
@@ -161,7 +161,7 @@
// defaults, overridden by command line
int listenport = 4691;
string listenaddr = "0.0.0.0";
-string monotone = "monotone";
+string monotone = "mtn";
// keep local servers around for this many seconds after the last
// client disconnects from them (only accurate to ~10 seconds)
signature.asc
Description: Digital signature
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
