State tables and state transition graphs

[Teddy Hogeborn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We're pleased that you find the project interesting.  Nominally, the
information you seek should be available on the web site by combining
the README file with the manual pages, which all explain in great
detail the inner workings of both server and client, but maybe I can
be of some help by trying to distill what you want.

See below for my attempt at a listing of server states, but let me
first answer your direct questions.

Lee Winter <lee.j.i.winter at gmail.com> writes:

> Case 1:  Client boots first.
>     In this case I think the client simply waits for the server to
> boot and announce itself.  The fundamental assumption is that the
> server can handle a request from the client before it has
> established that the client is up and running.  Is that true?

Yes.

> Case 2:  Server first, client boots immediately thereafter.  This is
> quite similar to case #1, but the first message received here is the
> client's broadcast request, while in case #1 the first message
> received would be the server's announcement.

We avoid having to deal with all this directly in our code by using
the Avahi library (for the ZeroConf protocol).  The Mandos server
starts to listen on a port, and says to the Avahi library: "Hey, I'm a
Mandos server, tell anyone who wants to find Mandos servers where to
find me.", and the Avahi daemon then does the rest.

The client, in effect, says to the Avahi library "Look for Mandos
servers, and when you find one, call this function, OK?".  That
function, which connects to a Mandos server and tries to get a
password from it, will then be called once for every Mandos server
found until the function succeeds in getting a password.  If no Mandos
servers provide a password, the client will therefore automatically
wait until such servers appear.

So you see, Avahi does a lot of the heavy lifting for us.  We don't
maintain any significant state ourselves for the sake of clients
finding servers and server announcing themselves.

In regards to the server keeping track of the state of clients, you
should note that this does not affect the clients; Mandos clients do
not run anything special once they have gotten the password and
started booting off the unlocked device.  It's all done on the server,
and the design is fairly simple:  The server periodically tries to run
a so-called "checker" program (by default "fping").  If the program
succeeds, it means that a client is alive and a timer for the
"disabling" of that client is reset.  If the timer is allowed to run
out, the client will be marked as "disabled", which means that it will
subsequently be denied passwords from the server.  The timer for each
client is constantly running, and only the periodic success of the
checker is keeping the timer from running out and the client from
being disabled.  Again, this has nothing to do with the Mandos client,
which only exists in the initrd and whose job is finished after
booting.

> Case 6.  Server boots, client boots, goes down long enough for the
> server to notice but not long enough to trigger the timeout.  Is any
> state lost?

Each time a checker succeds, the disabling timer will be reset and the
client will be viewed as just a good client as it was before.  Please
note: When a checker *fails*, this does exactly *nothing* to the
internal state of the server!  The timer will, however, not be reset,
and it will inexorably go on ticking and eventually trigger a
disabling of the client.  But a failing checker does not trigger a
state change.

> Case 7.  Server boots, client boots, goes down longer than the
> timeout, and then reboots with manual intervention to overcome the
> timeout.  Some time later the client reboots within the timeout
> interval.  Does the server provide service to the client

No, it is still "disabled".

> or is some manual intervention necessary on the server to reset the
> expired timeout?

Yes.  In the current version (1.0.11), you'd restart the server to get
all clients "enabled" again.  For the next major version (tentatively
numbered "1.1"), we've implemented a D-Bus API to the server, and plan
to provide both a command line tool and a text GUI tool to manipulate
server internals, so you'll be able to go in and see all the clients
and their status, re-enable clients or do "one-off" approval of
reboots.

But for now, you'll have to restart the Mandos server to enable a
disabled client.

> I'm sure the list above does not visit every possible state, but it
> is my starting point.  Are there other states of a server-to-client
> relationship besides
> a. server down
> b. server just booted (no client status info yet)
> c. server sees client alive
> d. server sees client dead < timeout
> e. server sees client dead >= timeout?

All of "b", "c", and "d" are the same state (except that in state "c",
the server also resets the timer for the client, but the timer always
continues to tick.).  It's also a bit of a misnomer to say that in
state "e" the server "sees client dead", because the server doesn't
"see" the client dead.  It's just that when the server hasn't seen the
client *alive* for some time it automatically disables the client from
getting passwords, irrespectively of what happens with the actual
checking of the client.

Let's see if I can take a stab at enumerating the different states:

0. Server stopped.
1. Server running, client enabled.
2. Server running, client enabled, checker running.
3. Server running, client disabled.

Rules:
  i) In state 0, when changing to state 1, start a timer with a
     timeout.
 ii) In states 1 or 2, a timer timeout will cause a change to state 3.
iii) In state 1, wait for a bit and then change to state 2.
 iv) In state 2, when a checker completes successfully, reset the
     timer before changing to state 1.  If the checker is
     unsuccessful, just change to state 1 without touching the timer.

I hope this will be enlightening.

> For each of the above usage cases please tell me whether I should
> expect the client to reboot unattended

In states "a" and "e" (and "0" and "3"), the client can not boot
unattended.  In all other states, it will be able to do so.

/Teddy Hogeborn

P.S.  Do I have your permission to re-send your mails and mine to the
public mandos-dev mailing list?  I think they would be useful to have
in the archive.

- -- 
The Mandos Project
http://www.fukt.bsnet.se/mandos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKpcAYOWBmT5XqI90RAieqAJ9rbh3c9xTR3r8XqyQCWQ8L75muNACfdbKa
YhkgtDvDqAil/P+kcxXeLhw=
=cAuE
-----END PGP SIGNATURE-----