[CUWiN-Dev] persistant configs...

David Young dyoung at pobox.com
Fri Nov 4 17:59:10 CST 2005


On Fri, Nov 04, 2005 at 12:44:51PM -0500, William Waites wrote:
> working with bsd routers and quagga, i've gotten into the habit of making use 
> of the integrated config with vtysh.
> 
> now that i've gotten my hands on a soekris board and have been hacking on it 
> for a bit, one thing that is a bit inconvenient is the way that persistant 
> configs work. to put it simply, "wr mem".
> 
> on the one hand, it is nice to have a standard, cookie-cutter, 
> all-configs-the-same sort of box, it makes it easy to drop in replacements, 
> for example, and fewer moving parts means potentially fewer things to break. 
> 
> on the other hand, one-size-fits all doesn't always work. it's nice to have a 
> simple way, where you don't have to go through the hoops of mounting and 
> unmounting filesystems and editing templates and such in order to, say, add a 
> static route, etc.
> 
> perhaps it would not be the worst idea to have / mounted read-write, and 
> twiddle the paths that quagga wants to use in order to make "wr mem" work as 
> expected?

Persistent configs are a pain.  I am interested to see patches in
this area.  Points to keep in mind:

        1 Most of the Zebra configuration is written by scripts at boot;
          how will you merge the 'wr mem' configuration with the
          auto-configured stuff?  This could get tricky.  Better to put
          Zebra under control of a dynamic configuration than to put a
          dynamic configuration under control of Zebra.  Hack vtysh?

        2 Configuration changes recorded to one partition have to move
          to the other partition when the operator does a software
          upgrade.  Maybe a partition should be reserved for a log of
          configuration changes.

        3 Leaving the root FFS mounted read-write is not acceptable on an
          appliance that can be rebooted or turned off at any time.

        4 There are problems with re-mounting FFS read-write/read-only.
          See NetBSD PR kern/30525.  Consider lobbying the responsible
          person to get that PR fixed.  (Be nice.)

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933


More information about the CU-Wireless-Dev mailing list