Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

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)

Check Out this Related Man Page

NATM(4) 						   BSD Kernel Interfaces Manual 						   NATM(4)

NAME

     natm -- Native Mode ATM protocol layer

DESCRIPTION

     The BSD ATM software comes with a native mode ATM protocol layer which provides socket level access to AAL0 and AAL5 virtual circuits.  To
     enable this protocol layer, add
	   options NATM
     to your kernel configuration file and re-make the kernel (do not forget to do ``make clean'').

NATM API

     The NATM layer uses a struct sockaddr_natm to specify a virtual circuit:

	   struct sockaddr_natm {
	     u_int8_t	   snatm_len;		   /* length */
	     u_int8_t	   snatm_family;	   /* AF_NATM */
	     char	   snatm_if[IFNAMSIZ];	   /* interface name */
	     u_int16_t	   snatm_vci;		   /* vci */
	     u_int8_t	   snatm_vpi;		   /* vpi */
	   };

     To create an AAL5 connection to a virtual circuit with VPI 0, VCI 201 one would use the following:

	     struct sockaddr_natm snatm;
	     int s, r;
	     s = socket(AF_NATM, SOCK_STREAM, PROTO_NATMAAL5);
				  /* note: PROTO_NATMAAL0 is AAL0 */
	     if (s < 0) { perror("socket"); exit(1); }
	     bzero(&snatm, sizeof(snatm));
	     snatm.snatm_len = sizeof(snatm);
	     snatm.snatm_family = AF_NATM;
	     sprintf(snatm.snatm_if, "en0");
	     snatm.snatm_vci = 201;
	     snatm.snatm_vpi = 0;
	     r = connect(s, (struct sockaddr *)&snatm, sizeof(snatm));
	     if (r < 0) { perror("connect"); exit(1); }
	     /* s now connected to ATM! */

     The socket() call simply creates an unconnected NATM socket.  The connect() call associates an unconnected NATM socket with a virtual circuit
     and tells the driver to enable that virtual circuit for receiving data.  After the connect() call one can read() or write() to the socket to
     perform ATM I/O.

Internal NATM operation
     Internally, the NATM protocol layer keeps a list of all active virtual circuits on the system in natm_pcbs.  This includes circuits currently
     being used for IP to prevent NATM and IP from clashing over virtual circuit usage.

     When a virtual circuit is enabled for receiving data, the NATM protocol layer passes the address of the protocol control block down to the
     driver as a receive ``handle''.  When inbound data arrives, the driver passes the data back with the appropriate receive handle.  The NATM
     layer uses this to avoid the overhead of a protocol control block lookup.	This allows us to take advantage of the fact that ATM has already
     demultiplexed the data for us.

CAVEATS

     The NATM protocol support is subject to change as the ATM protocols develop.  Users should not depend on details of the current implementa-
     tion, but rather the services exported.

SEE ALSO

     en(4), fatm(4), hatm(4), natmip(4), patm(4)

AUTHORS

     Chuck Cranor of Washington University implemented the NATM protocol layer along with the EN ATM driver in 1996 for NetBSD.

BSD
								 December 29, 1997							       BSD
Man Page