[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [rfc] New package idea with policy problems



On Thu, Jun 08, 2000 at 07:52:09PM +0100, Roger Gammans wrote:
> Proposal for Configuration Scheme Management System/Package
> ==========================================================
> This a proposal for a package called `sites', although schemes might
> be a better name this is avoided due to limit confusion with a certain
> programming language.

Hmmm.

I've written support for something similar for the ifup/ifdown
utilities. It works at a finer granularity than PCMCIA schemes, so you
can have one "scheme" for your WaveLAN connection and another for your
UTP connection, eg.

At its most basic you say:

	# ifup eth0=eth0-home

and ifup will look at the ifup-eth0 schema in your /etc/network/interfaces
file, which might say:

	iface eth0-home inet dhcp
		name-server 130.102.2.15
		http-proxy http://proxy.uq.edu.au:80/
		chrony-online 255.255.255.255/130.102.2.14

and then run the scripts in /etc/network/if-pre-up.d and
/etc/network/if-up.d, passing the above as environment variables.

There's also automated stuff so you can just say `ifup eth0' and it'll
work out which "scheme" you really want.

How I'm doing this is somewhat different to what you're doing. First, I,
personally, don't care for moving config files about and doing symlinks
and such, so instead I modify them in place with little perl fragments.
That's not such a big deal.

Hmmm. I've uploaded ifupdwon 0.6.0 (which is current) to
ifupdown.sourceforge.net. You should be able to download and compile it
(diverting the /sbin/ifup and /sbin/ifdown binaries netbase provides,
if you like) and have a look at it. I haven't updated the documentation
yet (tsk), but you can test most of the new features with something like:

/etc/network/interfaces:
	auto lo eth0
	mapping eth0
		script /usr/local/sbin/scheme-mapping
		map home eth0-home
		map work eth0-work
	iface eth0-home inet dhcp
	iface eth0-work inet static
		address 192.168.1.2
		netmask 255.255.255.0
		network 192.168.1.0
		gateway 192.168.1.1
		name-server 192.168.1.1

/usr/local/sbin/scheme-mapping:
	#!/bin/sh -e
	iface="$1"
	which=""
	scheme=`cat /etc/scheme`
	while read tstscheme newiface; do
		if [ "$tstscheme" = "$scheme" ]; then
			which="$newiface"
		fi
	done
	if [ "$which" ]; then
		echo $which
		exit 0
	else
		exit 1
	fi

/etc/network/if-up.d/10update-resolv == /etc/network/if-down.d/10update-resolv
	#!/bin/sh -e
	if [ "$IF_NAME_SERVER" = "" ]; then exit 0; fi
	case $MODE in
		"start")
			(
			echo "##BEGIN ADDED"
			for ns in $IF_NAME_SERVER; do
				echo "nameserver $ns"
			done
			) >> /etc/resolv.conf
			;;
		"stop")
			perl -i -n -e '$ignore = 1 if (m/^..BEGIN AUTOAJADDED$/); print unless ($ignore); $ignore = 0 if (m/^..END AUTOAJADDED$/);' /etc/resolv.conf
			;;
	esac

> All schemes must contain all the listed configuration files for all the 
> interesting packages, although this does not preclude such files being 
> symlinks to the another configuration schemes equivalent.[1]

I'm not doing that this way: for me, the scripts in /etc/netword/if-*.d/
will only do anything at all if the appropriate parameter is listed in the
interfaces file. So since DHCP servers generally tell me the name-server,
I don't bother specifying that by hand, and just let the DHCP server
work it out. When I'm disconnected, I don't have a nameserver at all,
or I have whatever might've gotten left around by my DHCP client.

> At switch time the following occurs,[2] 

Similarly, I don't have a "switch" operation: you can only down an
interface, and then bring it back up as something else.

> Installation
> ------------
> This is tricky I can't see what it can do safely, sensibly and within
> policy. If the rest of it hasn't blown policy right out of the water.

conffiles should never be automatically changed, but then, they should
never *need* to be automatically changed either.

Changing ordinary config files, specifically at the request of the admin
is fine, of course.

I'm not sure how maintainer scripts would cope with the config files being
symlinks, but I imagine they should work okay.

> Removal
> -------
> Umm The same applies here really. Purging the package could be
> messy, unless it resets it cofniguration on removal. If so
> how should it determine which scheme to use. 

Whatever the current scheme is? Prompt the admin?

> Aware Packages
> --------------

I'd hope most packages could become aware of this and provide scripts in
/etc/network/if*.d/. Things that come to mind are changing the upstream
proxy for squid on a laptop, changing news servers, starting particular
services (NFS, portmap, a web server) only on some particular networks,
and so forth.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.

  ``We reject: kings, presidents, and voting.
                 We believe in: rough consensus and working code.''
                                      -- Dave Clark

Attachment: pgpfw9qrJd9jk.pgp
Description: PGP signature


Reply to: