mailping-cron(1) [debian man page]

2004-04-15

      mailping

      0.0.4

MAILPING-CRON(1)						     Mailping							  MAILPING-CRON(1)

NAME

       mailping-cron - run periodic processing to test email service availability and functioning

SYNOPSIS

       mailping-cron

DESCRIPTION

	mailping-cron processes incoming emails, updates status and sends out probe messages.

       The idea is to configure multiple email "circuits", send probe messages regularly, and see whether they complete the circuit and how long
       it took.

   Setting up a circuit
	1.  Give a name to the circuit, hereafter referred to as circuit.

	2.  Arrange for a local email address to be delivered to maildir /var/lib/mailping/state/circuit/incoming/. See mailping-store.

	3.  Create a configuration for the circuit, by creating directory /etc/mailping/circuit.

	   If you need non-default sender and/or recipient addresses, create files from and to there, containing the sender and recipient
	   addresses suitable for the circuit.

	4.  You're done! Munin should now see the data.

   Testing multiple servers
       To test functioning of more than one email server, arrange an email alias at a remote site pointing to an address on your server, and set
       the address of that alias here.

       Here's an example of testing a system consisting of two email servers and everything in that path (smarthosts, primary MXs, virus checkers,
       etc.):

       Local address <mailping+that@this.example.com> is delivered with mailping-store to /var/lib/mailping/state/that/incoming/.

       Remote address <echo@that.example.com> is an alias that redirects all email to <mailping+that@this.example.com>.

	/etc/mailping/that/to is set to <echo@that.example.com>.

FILES

       /etc/mailping/circuit/from
	   Sender address for the probe emails. Default: <currentuserid@fullyqualifiedhostname>.

       /etc/mailping/circuit/to
	   Recipient address for the probe emails. You must arrange for the email to eventually get delivered to the maildir
	   /var/lib/mailping/state/circuit/incoming/.  mailping-store will probably be useful in that. Default:
	   <currentuserid+circuit@fullyqualifiedhostname>

       /etc/mailping/circuit/admin
	   Admistrative address, set as Reply-To in probe messages. Default: do not add Reply-To.

       /etc/mailping/circuit/interval
	   How often a probe message is sent, in seconds. Default: 600 seconds.

       /var/lib/mailping/state/circuit/
	   Stored state for the probing.

       /var/lib/mailping/state/circuit/junk/
	   Maildir used to store all messages in incoming that do not look like probe messages. Read and delete them regularly.

       /var/lib/mailping/state/circuit/broken/
	   Maildir used to store all messages in incoming that do look like probe messages, but a corresponding pending entry cannot be found.
	   Duplicated probe messages cause these. Read and delete them regularly.

ENVIRONMENT

       MAILPING_CONFIGDIR
	   Override the location of the configuration directory. Default: /etc/mailping

       MAILPING_STATEDIR
	   Override the location of the state directory. Circuit states are stored in the state subdirectory of this directory, in subdirectories
	   named after the circuit name. Default: /var/lib/mailping

SEE ALSO

	mailping-store(1), mailping-success(1), mailping-latency(1)

AUTHOR

       Tommi Virtanen <tv@havoc.fi>
       Havoc Consulting
	   Author.

COPYRIGHT

       Copyright (C) 2004 Havoc Consulting

mailping 0.							    2004-04-15							  MAILPING-CRON(1)

DK(3)							     Library Functions Manual							     DK(3)

NAME

       dk - Datakit conversations

SYNOPSIS

       bind #kname /net/dk
       bind #iname /net/dk

       ctlfd = open(".../ctl", ORDWR);
       write(ctlfd, "push dkmux", 10);
       write(ctlfd, "config csc [no]restart name nvc window", n);

DESCRIPTION

       A  Datakit  device--either  k  for the regular Datakit or i for the Incon--is a directory containing up to 256 directories, one per virtual
       circuit, named 0 through 255, and a special file named clone.  The specifier name matches the Datakit device to a physical device that  its
       virtual circuits are multiplexed over (see dkmux below).

       Normally,  the  standard routines dial, hangup, listen, and announce (see dial(2)) are used to make, listen for, and control calls over any
       network.  The routines expect the following properties of any multiplexed network, not just Datakit.

       Opening the clone file opens the ctl file of an unused virtual circuit.	Reading any ctl file returns  the  name  of  the  virtual  circuit
       directory.  For example, reading #k/17/ctl will return the string 17.

       Each virtual circuit directory contains the files:

       ctl	 to control the virtual circuit: establish a connection, hang it up, etc.

       data	 to converse with the remote end (via read and write)

       listen	 to listen for calls (after announcing; see below)

       other	 information about the conversation

       raddr	 the address of the remote end

       ruser	 the id of the user at the remote end (when applicable)

       To set up and tear down virtual circuits a process writes textual commands to the ctl file:

       connect addr	 connect to address addr.  If the connection fails, the write returns an error.

       hangup		 tear down a connected virtual circuit.

       announce name	 announce the readiness to accept calls to name.

       accept n 	 accept the call on virtual circuit n.

       reject n e	 reject the call on virtual circuit n with error code e.  E must be a number from 0 to 7.

       Once  a	virtual  circuit is set up, a process can converse with the remote service by reading and writing the data file.  Write boundaries
       are preserved.

       Accepting calls to name requires the following dance:

       1)     announce name on a virtual circuit.

       2)     open the listen file in that virtual circuit's directory.  When a call comes in on a virtual circuit for name, the open will  return
	      with the file descriptor open to the control file of the incoming virtual circuit.

       3)     accept or reject the call by writing an accept or reject command to the ctl file of the announced virtual circuit.

       A dkmux module pushed onto a stream makes that stream a multiplexed connection to a Datakit.  The subsequent config control message config-
       ures the multiplexer and matches it to a dk device.  The parameters to the config message are

       csc    the line number of the common signaling channel (must be > 0)

       nvc    the number of virtual circuits (optional; default chosen by Datakit)

       [no]restart
	      the word restart or norestart (optional; default is restart).  Restart tells the Datakit to  forget  all	previous  connections  and
	      authentications for this machine.

       name   The name used in binding dk device.

       window the default URP window size for virtual circuits on this Datakit line (default is 2048).

FILES

       #k/clone
       #k/[0-255]
       #k/[0-255]/data
       #k/[0-255]/ctl
       #k/[0-255]/listen
       #k/[0-255]/ruser
       #k/[0-255]/raddr

SEE ALSO

       stream(3), dkconfig(8), datakit(3)

SOURCE

       /sys/src/9/*/devdk.c

																	     DK(3)