From owner-freebsd-stable@FreeBSD.ORG Tue Nov 18 17:06:57 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE6981065673 for ; Tue, 18 Nov 2008 17:06:57 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id D6D0F8FC1A for ; Tue, 18 Nov 2008 17:06:56 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 9A28235E2E; Tue, 18 Nov 2008 18:03:45 +0100 (CET) Date: Tue, 18 Nov 2008 18:08:31 +0100 From: cpghost To: "Bjoern A. Zeeb" Message-ID: <20081118170831.GA2264@phenom.cordula.ws> References: <5FD58BCD6B4C409DA7E7C30150FB10C7@multiplay.co.uk> <20081117.233619.85395429.sthaug@nethelp.no> <20081118081153.GQ51761@server.vk2pj.dyndns.org> <20081118.103424.74710091.sthaug@nethelp.no> <20081118113811.GB1136@phenom.cordula.ws> <20081118120244.U61259@maildrop.int.zabbadoz.net> <20081118132305.GB958@phenom.cordula.ws> <20081118134228.GC958@phenom.cordula.ws> <20081118135622.L61259@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081118135622.L61259@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable@freebsd.org, sthaug@nethelp.no Subject: Re: ifconfig(8) interface description field X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2008 17:06:57 -0000 On Tue, Nov 18, 2008 at 01:58:09PM +0000, Bjoern A. Zeeb wrote: > >> Some network management apps could also decide to use the description > >> field as a repository for more dynamic data; data that could be queried > >> by applications running on the hosts. Here too, would'nt it be more > >> efficient if descr. were in-kernel? > >> > >> For persistence, an /etc/rc.d script could always set the static > >> interface descriptions via ifconfig calls any way it likes, including > >> reading those definitions from a config file. Everything else will > >> probably be set remotely via the network management software, which > >> itself has its own persistence store (usually a database). > > > > Another reason you want to avoid using a file for this: what about > > appliances that run as dedicated routers and boot from a flash-based > > read-only filesystem? How would you change the interface description > > (remotely or on the console) if you can't write to a file? > > So how would you make it persistent across a reboot if you cannot write > it anywhere? This would be done remotely by the network management system (NMS) The NMS will notice that the node rebooted, and will send to its snmpd the description of its interfaces. snmpd runs on the node, and will call an ifconfig ioctl to store this description in kernel memory. From then on, you could ssh to the box, and look around by calling ifconfig(8) manually: you'all immediately know what each interface is intended for. If you have hundreds of nodes, you'll appreciate the convenience! The presistence occurs at the NMS site: it is merely mirrored onto the nodes. So why store this on the nodes at all, as it is redundant and already persistently available in the NMS? Well, in practice, NMS can and do break down every now and then for all kinds of reasons (database problems, server problems, network problems to the NMS server, ...). But a NOC can't afford to wait for the NMS be available again to reconfigure some important nodes on a backbone. Even when the NMS is down, you'll still have to manually ifconfig(8) some interfaces on crucial backbone nodes. When the NMS is available again, it will poll all the snmpd of its managed hosts, and will update its own database if things changed in the mean time on the nodes. That's the easiest way to synchronize the NMS database back with the manual changes at the nodes that occured while the NMS was down. (Sure, there's a little time window where information can be lost: that's just after the manual ifconfig(8) and the polling of the snmpd by the NMS. But, hey, if THIS happened, you could still use some logfile (script(1)?) of your manual changes to catch this. The normal workflow is to manage at the NMS and to push the data to the nodes, the reverse workflow is for emergencies only.) The point I'm trying to make, is that diskless systems, or systems with read-only filesystems should still be configurable, remotely and manually; and the configuration data (in this case it's the description strings of its interfaces) will have to be stored in memory. For something as trivial as description strings, kernel memory seems like a good idea. If user memory is preferred and absolutely needed, one could always write an ifconfigd daemon and store it there; but *that* seems like overkill for such a simple change. > Bjoern A. Zeeb Stop bit received. Insert coin for new game. -cpghost. -- Cordula's Web. http://www.cordula.ws/