[CUWiN-Dev] Rev. 4085 disappearing default routes

dan blah dan.blah at gmail.com
Wed Jul 19 20:53:47 CDT 2006


On 7/19/06, David Young <dyoung at pobox.com> wrote:
> On Wed, Jul 19, 2006 at 08:20:25AM -0500, dan blah wrote:
> > On 7/19/06, David Young <dyoung at pobox.com> wrote:
> > >On Tue, Jul 18, 2006 at 11:00:09PM -0400, dan blah wrote:
> > >> isnt there a switch for that in the upgrade script... to not overwrite
> > >> the cuw_config.  maybe a default of appending the new cuw_config to
> > >> the old cuw_config with comments and a reminder at the end of the
> > >> upgrade stating to check the cuw_config for new changes.
> > >
> > >In the interests of giving operators an upgrade path, I think it is
> > >reasonable for /sbin/upgrade to understand any configuration file that is
> > >two minor revisions old, or newer, and convert it to the newest format.
> >
> > agreed as long as the operator is notified of this.
>
> It is fine to notify that this is happening, but the script is always
> going to do a better job than the operator at converting, because
> it can contain all of the knowledge of the developer who changed the
> configuration format.
>
> > eventually it
> > would be nice to see a 'smartened' /sbin/upgrade that would (if no
> > switch was provided for what to do with the cuw_config) do a diff on
> > the cuw_config and ask the operator what was desired.
>
> I disagree.  The operator does not need any choice but the one we give
> him now: either bring the old configuration over, or overwrite the
> old configuration with the configuration in the upgrade file.  If the
> operator wants to make refinements to a configuration, let him do that
> with nodeconfig or vi.
>
> > importantly would just be using the switches to overwrite and letting
> > people know with new version announcements that cuw_config vars have
> > changed and require attention.
>
> Dan, why do you want to abuse our operators and our developers in this
> way? :-) You propose both to complicate the upgrade script by adding
> operator choices, and to blithely overwrite an operator's configuration
> choices with a warning (read: apology) in the release announcement.
> You cruel, cruel man!

lol... well i just want to make sure custom vars are preserved (next email.)
>
> Dave
>
> --
> David Young             OJC Technologies
> dyoung at ojctech.com      Urbana, IL * (217) 278-3933
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
>


-- 
Daniel


More information about the CU-Wireless-Dev mailing list