This directory contains example data (with DNS views) to load
into a fresh Netmagis installation. There are two main objectives:
    - show how to import your own data
    - quickly get a running Netmagis installation in order to
	test the software
Data are loaded through the "run-all.sh" script which you can copy
and adapt to suit your own needs. See installation documentation
on http://netmagis.org

Furthermore, these data are used during the development stages to
test the software.

This document explains the scenario used in this example.

- The company (Example Corporation) has a RFC 1918 network
    (172.16.0.0/16) and a DMZ (198.51.100.0/24 and 2001:db8:1234::/64)
    where some public servers are located.
- Example Corp has organized a non commercial event, which needs a
    dedicated website (www.example.org)

- on an network management point of view, some users can use Netmagis
    (see networks.txt and group.txt):
    - network engineers (members of the wheel group) are allowed
	to administer the application itself, and have extended
	rights on all networks
    - support staff (members of the staff group) are allowed to
	manage internal hosts

- on a DNS point of view (see view.txt, domain.txt and zones/* files):
    - the "external" DNS view shows some hosts in example.com and
	example.org (with IPv4 and IPv6 addresses). This view is
	accessed only by the wheel group members
	This view implies zone generation for:
	    example.com
	    example.org
	    100.51.198.in-addr.arpa
	    4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa
	Zone below is not generated for this view, since data are
	private:
	    16.172.in-addr.arpa
    - the "internal" DNS view shows all internal hosts as well
	as hosts located on the DMZ (i.e. external view), with
	one exception (see below)
	This view implies zone generation for:
	    example.com
	    16.172.in-addr.arpa
	    100.51.198.in-addr.arpa
	Zones below are not generated for this view, since they do
	not differ from external view and RR can thus be resolved by
	the public name server (with external zones):
	    example.org
	    4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa
    - for historical (i.e. bad) reasons, one server located on the
	internal network need to be reachable from the Internet
	with a public (NAT) address. Therefore, this server has
	a different IP address in external and internal views

- on a mail point of view (see mailrelay.txt and mailrole.txt):
    - all mail traffic is routed through mx[12].example.com
    - internal mail routing accepts mail to:
	sales.example.com
	and mail is redirected to mailhost.example.com located
	in the internal network. Consequently, an MX must be
	published in external view, and the associated mail
	relay is known only in the internal view