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
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
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 hend...@topoi.pooq.com 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 hend...@topoi.pooq.com 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 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 hend...@topoi.pooq.com 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 20110203160429.ga5...@topoi.pooq.com on Thu, 3 Feb 2011 11:04:29 -0500, Hendrik Boom hend...@topoi.pooq.com 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 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 hend...@topoi.pooq.com 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 hend...@topoi.pooq.com 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)
In message 20110131075604.ga14...@topoi.pooq.com on Mon, 31 Jan 2011 02:56:04 -0500, Hendrik Boom hend...@topoi.pooq.com 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 hend...@topoi.pooq.com said: hendrik hendrik hendrik (2) Is there a comment convention for the usher config file? hendrik hendrikcomment 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 hend...@topoi.pooq.com 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 rich...@levitte.org 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
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)
In message 20101119201102.ga25...@topoi.pooq.com on Fri, 19 Nov 2010 15:11:02 -0500, Hendrik Boom hend...@topoi.pooq.com said: hendrik (1) The listen addr in the sample script is 0.0.0.0:4691. hendrik hendrikThe 4691 is the usual monotone port number. hendrik hendrikBut I'm not familiar with IP to know what the 0.0.0.0 means. Does hendrikit 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 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 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)
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 monotonemtn -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 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 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 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 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 monotonemtn -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
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
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 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 tbrow...@prjek.net said: tbrownaw There is an actual release of usher available now. It's tagged as tbrownaw usher-0.99 available from tbrownawmtn://monotone.ca/contrib?net.venge.monotone.usher tbrownaw and there is a tarball available at tbrownawhttp://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 tbrownawhttp://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
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: [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: 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
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 information exchange might be retained for a period of six months or longer:
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
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
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
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/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
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
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
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: [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
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 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
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
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: 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
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
