/usr/share/doc/monotone/html/Network-Service-Revisited.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Created by GNU Texinfo 6.0, http://www.gnu.org/software/texinfo/ -->
<head>
<title>monotone documentation: Network Service Revisited</title>

<meta name="description" content="monotone documentation: Network Service Revisited">
<meta name="keywords" content="monotone documentation: Network Service Revisited">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="index.html#Top" rel="start" title="Top">
<link href="General-Index.html#General-Index" rel="index" title="General Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="Tutorial.html#Tutorial" rel="up" title="Tutorial">
<link href="Advanced-Uses.html#Advanced-Uses" rel="next" title="Advanced Uses">
<link href="Branching-and-Merging.html#Branching-and-Merging" rel="prev" title="Branching and Merging">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.indentedblock {margin-right: 0em}
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smalllisp {margin-left: 3.2em}
kbd {font-style: oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nocodebreak {white-space: nowrap}
span.nolinebreak {white-space: nowrap}
span.roman {font-family: serif; font-weight: normal}
span.sansserif {font-family: sans-serif; font-weight: normal}
ul.no-bullet {list-style: none}
-->
</style>
<link rel="stylesheet" type="text/css" href="texinfo.css">


</head>

<body lang="en">
<a name="Network-Service-Revisited"></a>
<div class="header">
<p>
Previous: <a href="Branching-and-Merging.html#Branching-and-Merging" accesskey="p" rel="prev">Branching and Merging</a>, Up: <a href="Tutorial.html#Tutorial" accesskey="u" rel="up">Tutorial</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="General-Index.html#General-Index" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<a name="Network-Service-Revisited-1"></a>
<h3 class="section">2.13 Network Service Revisited</h3>

<p>Up until now, Jim has been using his laptop and database as a sort of
&ldquo;central server&rdquo; for the company; Abe and Beth have been syncing with
Jim, and learning of each other&rsquo;s work via Jim&rsquo;s database.  This has
worked fine while the product has been in early development; Jim has
good network connectivity in Japan, and has been staying home
concentrating on programming.  He has been able to leave his laptop
connected and running all the time, while his employees in different
time-zones work and sync their databases.  This is now starting to
change, and two problems are starting to cause occasional difficulties.
</p>
<ul>
<li> First, Jim is finding that he has to spend more of his time
travelling, demonstrating the new juicebot features to customers; thus
his laptop is spending more time disconnected from the network, or
connected at dynamic addresses where it&rsquo;s not convenient for Abe and
Beth to find him and sync.

<p>This doesn&rsquo;t prevent them doing any work, but it does have some
uncomfortable consequences: they&rsquo;re more likely to have to manually
merge conflicting changes when they finally sync up and discover they&rsquo;ve
both come up with slightly different fixes for the same bug in the
meantime, and they&rsquo;re more exposed to loss of work if one of them
suffers a disk failure before they&rsquo;ve had a chance to sync that work
with another database.
</p>
</li><li> Second, because Jim has been using the one database file both for his
own local work, and for serving to the others in the team, he
occasionally finds that the monotone serve process (busy syncing with
Abe or Beth) has a lock on the database, while he&rsquo;s trying to do local
work like updates or commits.

<p>The level of project activity is picking up, and there are more and more
changes to be synced in the narrower window of time while Jim is
connected. He finds he sometimes needs to take down the server process
to do this local work, further exacerbating the first problem.
</p></li></ul>

<p>The juicebot team are resourceful, and by now quite used to working
independently.  While Jim has been away travelling, Abe and Beth have
come up with their own solution to the first problem: they&rsquo;ll run
servers from their databases, setting them up just like Jim did
previously.  That way, if Jim&rsquo;s database is offline, either Beth or Abe
can run the <code>serve</code> command and provide access for the other to
<code>sync</code> with.  Beth also has the idea to create a second database
for the <code>serve</code> process, and to <code>sync</code> her development
database with that server locally, avoiding locking contention between
multiple monotone processes on the one database file.
</p>
<p>When Jim reappears, the next person to <code>sync</code> with him will
often pass him information about both employees&rsquo; work that they&rsquo;ve
sync&rsquo;ed with each other in the meantime, just as he used to do. In fact,
Jim now finds it more convenient to initiate the sync with one of the
other servers when he has a spare moment and dynamic connectivity from a
hotel room or airport.  Changes will flow between servers automatically
as clients access them and trade with one another.
</p>
<p>This gets them by for a while, but there are still occasional
inconveniences.  Abe and Beth live in very different time-zones, and
don&rsquo;t always have reliable network connectivity, so sometimes Jim finds
that neither of them is online to sync with when he has the chance.  Jim
now also has several customers interested in beta-testing the new code,
and following changes as the bugs and issues they report are addressed.
</p>
<p>Jim decides it&rsquo;s time for a permanent server they can all sync with;
this way, everyone always knows where to go to get the latest changes,
and people can push their changes out without first calling their
friends and making sure that they have their servers running.
</p>
<p>Jim has rented some web server space on a service provider&rsquo;s shared
system for the JuiceBot Inc. public website, <code>www.juicebot.co.jp</code>;
he thinks this server will be a good place to host the central monotone
server too. He sets up a new monotone database on the server,
generates a new key specially for the server (so he doesn&rsquo;t have to
expose his own development private key on the shared system), and loads
in the team-members&rsquo; keys:
</p>
<div class="smallexample">
<pre class="smallexample">$ mtn --db=server.mtn db init
$ mtn genkey monotone-server@www.juicebot.co.jp
enter passphrase for key ID [monotone-server@www.juicebot.co.jp] (...): <i>&lt;Jim enters a new passphrase&gt;</i>
confirm passphrase for key ID [monotone-server@www.juicebot.co.jp] (...): <i>&lt;Jim confirms the passphrase&gt;</i>
mtn: generating key-pair 'monotone-server@www.juicebot.co.jp'
mtn: storing key-pair 'monotone-server@www.juicebot.co.jp' in /home/jim/.monotone/keys
mtn: key 'abe@juicebot.co.jp' has hash '78be08f7a2a316a9f7c6b0db544ed20673ea2190'
$ cat abe.pubkey beth.pubkey jim.pubkey | mtn --db=server.mtn read
mtn: read 3 packets
</pre></div>

<p>For the team members, he sets up the permissions files on the server
much like before &mdash; except that of course he needs to also grant his
<code>jim@juicebot.co.jp</code> key permission to access the new server.
For the beta-testers, Jim wants to allow them read-only access just to
the main JuiceBot 7 development line, but not to any of the
sub-branches where other experimental development is going on. He adds
some lines at the top of the <samp>~/.monotone/read-permissions</samp> on
the server, above the broader permissions given to team-members. See
<a href="Netsync-Permission-Hooks.html#get_005fnetsync_005fread_005fpermitted">get_netsync_read_permitted</a> for more details; the resulting file
looks like this:
</p>
<div class="smallexample">
<pre class="smallexample">comment &quot;Provide beta-testers with specific read-only access&quot;
pattern &quot;jp.co.juicebot.jb7&quot;
allow &quot;beta1@juicebot.co.jp&quot;
allow &quot;beta2@juicebot.co.jp&quot;
continue &quot;true&quot;

comment &quot;Fall-through, and allow staff access to all branches&quot;
pattern &quot;*&quot;
allow &quot;abe@juicebot.co.jp&quot;
allow &quot;beth@juicebot.co.jp&quot;
allow &quot;jim@juicebot.co.jp&quot;
</pre></div>


<p>Jim could log in and start the monotone process manually from his shell
account on the server, perhaps under a program like screen to let it
stay running while he&rsquo;s away. This would be one way of giving it the
server-key&rsquo;s passphrase each startup, but he wants to make sure that the
server is up all the time; if the host reboots while he&rsquo;s travelling and
the monotone server is down until he next logs in, things aren&rsquo;t much
better than before.  For the server to start automatically each time,
he&rsquo;ll need to use the <code>get_passphrase</code> hook in the server&rsquo;s
<samp>monotonerc</samp> file again.
</p>
<p>Because he&rsquo;s running on a shared server, Jim needs to be a little more
restrictive about which interfaces and addresses his new server process
will listen on. He should only accept connections at the address used
for his website, because some of the provider&rsquo;s other customers might
also want to publish their own monotone projects on this host.  Jim uses
the <samp>--bind=<var>address</var>:<var>port</var></samp> argument like so:
</p>
<div class="smallexample">
<pre class="smallexample">$ mtn --db=server.mtn --bind=www.juicebot.co.jp serve
</pre></div>

<p>This will start monotone listening on the default port (4691), but only
on the IP address associated with <code>www.juicebot.co.jp</code>.  Jim can do
this because his hosting provider has given him a dedicated IP address
for his website.  If the hosting provider offered only a single shared
IP address belonging to the server, each customer could bind a different
port number on that address.
</p>
<p>While he&rsquo;s first testing the setup, Jim uses
<samp>--bind=localhost:1234</samp>. This causes the monotone process to listen
only to port 1234 on the loopback interface 127.0.0.1, which is not
accessible from the network, so Jim doesn&rsquo;t expose an open port to the
rest of the world until he&rsquo;s satisfied with the permissions
configuration.  You can cause monotone to listen on all interfaces on
port 1234 by leaving out the address part like <samp>--bind=:1234</samp>.
</p>
<p>When he&rsquo;s satisfied the server is set up correctly, Jim does an initial
<code>sync</code> with the new database, filling it with all the revision
history currently on his laptop. While Jim has been busy setting up the
server, Abe and Beth have kept working; the server will catch up with
their latest changes when they next sync, too.
</p>
<p>All of the team members now want to sync with the new monotone server
by default.  Previously, they had been syncing with Jim&rsquo;s laptop by
default, even if they occasionally specified another team-member&rsquo;s
server on the command line when Jim was away, because monotone had
remembered the first server and branch patterns used in database vars
(see <a href="Vars.html#Vars">Vars</a>).  These vars can be seen as follows:
</p>
<div class="smallexample">
<pre class="smallexample">$ mtn list vars
database: default-exclude-pattern
database: default-include-pattern jp.co.juicebot.jb7*
database: default-server jim-laptop.juicebot.co.jp
known-servers: jim-laptop.juicebot.co.jp 9e9e9ef1d515ad58bfaa5cf282b4a872d8fda00c
known-servers: abe-laptop.juicebot.co.jp a2bb16a183247af4133621f7f5aefb21a9d13855
known-servers: www.juicebot.co.jp 120a99ch93b4f174432c13d3e3e9f2234aa92612
</pre></div>

<p>The team members can reset their local database vars accordingly:
</p>
<div class="smallexample">
<pre class="smallexample">$ mtn set database default-server www.juicebot.co.jp
</pre></div>

<p>With their new server, the juicebot team have gained the convenience of
a readily available common point of reference for syncs.  However, they
also know that this is there only as a convenience, and doesn&rsquo;t prevent
them working as they did before:
</p><ul>
<li> The team members can still sync with each other if needed.

<p>Hopefully, their new server won&rsquo;t ever be down, but sometimes they might
be working together while away from ready network access &mdash; fixing up
the last few issues and finalising presentation materials while
travelling to a sales conference, for example.  The server will learn of
these changes on the next sync.
</p></li><li> The team members continue to discover multiple heads and changes that
need merging, as before. Each team member can merge the heads, and will
produce the same revision id if they merge to the same result.

<p>They now develop a new habit out of courtesy, though &mdash; they try not to
leave multiple heads and unmerged changes on the server, at least not
for long. This saves them from repeating work, and also helps prevent
confusion for the beta-testers.  When each team member is ready to
<code>sync</code>, they develop the habit of doing a <code>pull</code> from
the server first.  If new revisions were received from the server, they
first <code>merge</code> their new revisions with the head(s) from the
server, and finally <code>sync</code> to publish their merged changes as
one.  If the last <code>sync</code> happens to pull in new revisions again
from the server, it means someone else has deposited new work at the
same time, and another <code>merge</code> and <code>sync</code> would probably
be polite.
</p></li><li> Jim knows he doesn&rsquo;t have to keep a special backup of the new server&rsquo;s
contents; if the server should fail, all the contents of its database
can be found amongst the other team members (especially because no
commits are done on the server itself).

<p>He does, however, take a copy of the server&rsquo;s private key, so he can
restore that if necessary.
</p></li><li> In fact, Jim realises that he can now commit a copy of the web site&rsquo;s
current contents into monotone on a new branch,
<code>jp.co.juicebot.www</code>, and keep a backup of that content too.

<p>Now he can use monotone to work on the website offline, and let other
team members add and edit the content; he can also preview changes
locally before updating the production content.  He keeps a workspace
checkout of this content in the webroot on the server, and runs a
monotone <code>update</code> in there when he wants to bring the public web
site up to date. Later, he&rsquo;ll think about using monotone&rsquo;s <a href="Quality-Assurance.html#Quality-Assurance">Quality Assurance</a> mechanisms and Event Notification <a href="Hooks.html#Hooks">Hooks</a>, so that the
web server can update itself automatically when appropriate new
revisions are received.
</p></li><li> Jim also knows that even if someone should break into the shared hosting
server and tamper with the database, they won&rsquo;t be able to inject
malicious code into the project, because all revisions are signed by the
team members, and he has set his <a href="Trust-Evaluation-Hooks.html#Trust-Evaluation-Hooks">Trust Evaluation Hooks</a> so he
doesn&rsquo;t trust the server key for signing revisions.

<p>In monotone, the important trust consideration is on the <em>signed
content</em>, rather than on the <em>replication path</em> by which that
content arrived in your database.
</p></li></ul>

<hr>
<div class="header">
<p>
Previous: <a href="Branching-and-Merging.html#Branching-and-Merging" accesskey="p" rel="prev">Branching and Merging</a>, Up: <a href="Tutorial.html#Tutorial" accesskey="u" rel="up">Tutorial</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="General-Index.html#General-Index" title="Index" rel="index">Index</a>]</p>
</div>



</body>
</html>
monotone-doc 1.1-7 / usr / share / doc / monotone / html / Network-Service-Revisited.html
