-
I suppose this belongs here... Begin forwarded message: > From: Douglas Mayle <douglas@...> > Date: July 31, 2008 2:44:01 PM EDT > To: operations-discussion@... > Subject: [operations discussion] Beefing up configuration merging in > fassembler... > Reply-To: operations-discussion@... > > I've been doing a lot of builds lately, and one of the things that > takes the most of my time in performing the build is the merging of > configuration files. It's not because it's that difficult of a > process, it's just that when building, you're prompted every couple > of minutes to look at the changes to a given config file, and then > after responding, there's a wait before you're needed again. > > I wrote a patch awhile ago to add merging capabilities which is > rudimentary, and ultimately based off of etc-update from gentoo. I > use this as a model, because I find it incredibly useful for > maintaining my system. I was originally thinking about trying to > mimic more of the behavior, or even change the process so that we > could make do with our more primitive tools, or use etc-update for > those who had it available and wished to do so. > > While talking to Paul, however, I got the idea of actually using etc- > update, embedding it into our build process (That's what open source > is all about ;-) ). It's just a bash script, so it would work on > all of the platforms we currently support, and building it in should > be backward compatible to previous fassembler builds. The script > has some notion of portage built in, but that's only used to > determine which directories to check for configuration merging. It > would be easy enough to replace that to match our needs. > > What do you guys think? Good idea? Got something better? I'd like > to know... > > Doug > > > -- > Archive: http://www.openplans.org/projects/operations/lists/operations-discussion/archive/2008/07/1217529842760 > To unsubscribe send an email with subject "unsubscribe" to operations-discussion@... > . Please contact operations-discussion-manager@... > for questions. >
-
Douglas Mayle wrote: > I suppose this belongs here... > > Begin forwarded message: > >> *From: *Douglas Mayle <douglas@... >> <mailto:douglas@...>> >> *Date: *July 31, 2008 2:44:01 PM EDT >> *To: *operations-discussion@... >> <mailto:operations-discussion@...> >> *Subject: **[operations discussion] Beefing up configuration merging >> in fassembler...* >> *Reply-To: *operations-discussion@... >> <mailto:operations-discussion@...> >> >> I've been doing a lot of builds lately, and one of the things that >> takes the most of my time in performing the build is the merging of >> configuration files. It's not because it's that difficult of a >> process, it's just that when building, you're prompted every couple of >> minutes to look at the changes to a given config file, and then after >> responding, there's a wait before you're needed again. >> >> I wrote a patch awhile ago to add merging capabilities which is >> rudimentary, and ultimately based off of etc-update from gentoo. I >> use this as a model, because I find it incredibly useful for >> maintaining my system. I was originally thinking about trying to >> mimic more of the behavior, or even change the process so that we >> could make do with our more primitive tools, or use etc-update for >> those who had it available and wished to do so. >> >> While talking to Paul, however, I got the idea of actually using >> etc-update, embedding it into our build process (That's what open >> source is all about ;-) ). It's just a bash script, so it would work >> on all of the platforms we currently support, and building it in >> should be backward compatible to previous fassembler builds. The >> script has some notion of portage built in, but that's only used to >> determine which directories to check for configuration merging. It >> would be easy enough to replace that to match our needs. >> >> What do you guys think? Good idea? Got something better? I'd like >> to know... it sounds good to me in theory, but i've never maintained gentoo box so i don't know exactly how etc-update works. can you describe exactly how this would change the workflow of a deployment upgrade? -r p.s.: i _have_ maintained freebsd boxes, which (at least when i was using freebsd) used mergemaster, but that worked very much like fassembler does currently, by churning for a while and then interactively prompting the user to examine and merge config differences.
-
On Jul 31, 2008, at 2:51 PM, Rob Miller wrote: > Douglas Mayle wrote: >> I suppose this belongs here... >> Begin forwarded message: >>> *From: *Douglas Mayle <douglas@... <mailto:douglas@... >>> >> >>> *Date: *July 31, 2008 2:44:01 PM EDT >>> *To: *operations-discussion@... <mailto:operations-discussion@... >>> > >>> *Subject: **[operations discussion] Beefing up configuration >>> merging in fassembler...* >>> *Reply-To: *operations-discussion@... <mailto:operations-discussion@... >>> > >>> >>> I've been doing a lot of builds lately, and one of the things that >>> takes the most of my time in performing the build is the merging >>> of configuration files. It's not because it's that difficult of a >>> process, it's just that when building, you're prompted every >>> couple of minutes to look at the changes to a given config file, >>> and then after responding, there's a wait before you're needed >>> again. >>> >>> I wrote a patch awhile ago to add merging capabilities which is >>> rudimentary, and ultimately based off of etc-update from gentoo. >>> I use this as a model, because I find it incredibly useful for >>> maintaining my system. I was originally thinking about trying to >>> mimic more of the behavior, or even change the process so that we >>> could make do with our more primitive tools, or use etc-update for >>> those who had it available and wished to do so. >>> >>> While talking to Paul, however, I got the idea of actually using >>> etc-update, embedding it into our build process (That's what open >>> source is all about ;-) ). It's just a bash script, so it would >>> work on all of the platforms we currently support, and building it >>> in should be backward compatible to previous fassembler builds. >>> The script has some notion of portage built in, but that's only >>> used to determine which directories to check for configuration >>> merging. It would be easy enough to replace that to match our >>> needs. >>> >>> What do you guys think? Good idea? Got something better? I'd >>> like to know... > > it sounds good to me in theory, but i've never maintained gentoo box > so i don't know exactly how etc-update works. can you describe > exactly how this would change the workflow of a deployment upgrade? > Sure... Instead of prompting each time there was a config change, fassembler would instead save a copy of the replacement file mangled following a certain algorithm. At the end of the build, if there were files to be merged, it would output a summary and directions on how to invoke the command. At that point, you invoke the command, and you're given a numbered list of files that have changes in them. For each file listed, you can select it from the list, and it will show you the differences, You are then given the option of replacing the old file, keeping it, or interactively merging the two. When merging, after the process is complete, you are returned to the same list of options, but also given the chance to compare the newly merged file against the original, double checking for errors. After manually handling any files you specifically interested in, you can then tell etc-update to automerge the rest, prompting you or not, depending on your preference. All of this uses the merge, diff, and editor defined on your system as default (e.g. on gentoo, this defaults to smerge, diff, and nano, but I've got my systems configured with smerge, colordiff, and vi...) > -r > > p.s.: i _have_ maintained freebsd boxes, which (at least when i was > using freebsd) used mergemaster, but that worked very much like > fassembler does currently, by churning for a while and then > interactively prompting the user to examine and merge config > differences. > > > -- > Archive: http://www.openplans.org/projects/fassembler/lists/fassembler-discussion/archive/2008/07/1217530293699 > To unsubscribe send an email with subject "unsubscribe" to fassembler-discussion@... > . Please contact fassembler-discussion-manager@... > for questions. >
-
Douglas Mayle wrote: > On Jul 31, 2008, at 2:51 PM, Rob Miller wrote: > >> Douglas Mayle wrote: >>>> While talking to Paul, however, I got the idea of actually using >>>> etc-update, embedding it into our build process (That's what open >>>> source is all about ;-) ). It's just a bash script, so it would >>>> work on all of the platforms we currently support, and building it >>>> in should be backward compatible to previous fassembler builds. The >>>> script has some notion of portage built in, but that's only used to >>>> determine which directories to check for configuration merging. It >>>> would be easy enough to replace that to match our needs. >>>> >>>> What do you guys think? Good idea? Got something better? I'd like >>>> to know... >> >> it sounds good to me in theory, but i've never maintained gentoo box >> so i don't know exactly how etc-update works. can you describe >> exactly how this would change the workflow of a deployment upgrade? >> > > Sure... > > Instead of prompting each time there was a config change, fassembler > would instead save a copy of the replacement file mangled following a > certain algorithm. At the end of the build, if there were files to be > merged, it would output a summary and directions on how to invoke the > command. At that point, you invoke the command, and you're given a > numbered list of files that have changes in them. For each file listed, > you can select it from the list, and it will show you the differences, > You are then given the option of replacing the old file, keeping it, or > interactively merging the two. When merging, after the process is > complete, you are returned to the same list of options, but also given > the chance to compare the newly merged file against the original, double > checking for errors. After manually handling any files you specifically > interested in, you can then tell etc-update to automerge the rest, > prompting you or not, depending on your preference. > > All of this uses the merge, diff, and editor defined on your system as > default (e.g. on gentoo, this defaults to smerge, diff, and nano, but > I've got my systems configured with smerge, colordiff, and vi...) +1 -r
-
On Thu, Jul 31, 2008 at 12:32:10PM -0700, Rob Miller wrote: > Douglas Mayle wrote: >> (snip) At the end of the build, if there were files to be merged, it >> would output a summary and directions on how to invoke the command. That sounds like good behavior when run with --no-interactive. Maybe if you don't specify --no-interactive, the default should be to invoke this command automatically at the end of the build? +1 regardless of that. - PW -- Paul Winkler http://www.openplans.org/people/slinkp/profile yahoo: slinkp23 AIM: slinkp1970
-
-
On Jul 31, 2008, at 3:17 PM, Douglas Mayle wrote: > Sure... > > Instead of prompting each time there was a config change, fassembler > would instead save a copy of the replacement file mangled following > a certain algorithm. At the end of the build, if there were files > to be merged, it would output a summary and directions on how to > invoke the command. At that point, you invoke the command, and > you're given a numbered list of files that have changes in them. > For each file listed, you can select it from the list, and it will > show you the differences, You are then given the option of > replacing the old file, keeping it, or interactively merging the > two. When merging, after the process is complete, you are returned > to the same list of options, but also given the chance to compare > the newly merged file against the original, double checking for > errors. After manually handling any files you specifically > interested in, you can then tell etc-update to automerge the rest, > prompting you or not, depending on your preference. > > All of this uses the merge, diff, and editor defined on your system > as default (e.g. on gentoo, this defaults to smerge, diff, and > nano, but I've got my systems configured with smerge, colordiff, and > vi...) An example session, for posterity: * IMPORTANT: 4 config files in '/etc' need updating. * See the CONFIGURATION FILES section of the emerge * man page to learn how to update config files. cezan ~ # etc-update Scanning Configuration files... Automerging trivial changes in: /etc/security/limits.conf Automerging trivial changes in: /etc/nanorc The following is the list of files which need updating, each configuration file is followed by a list of possible replacement files. 1) /etc/security/namespace.init (1) 2) /etc/pam.d/system-auth (1) Please select a file to edit by entering the corresponding number. (don't use -3, -5, -7 or -9 if you're unsure what to do) (-1 to exit) (-3 to auto merge all remaining files) (-5 to auto-merge AND not use 'mv -i') (-7 to discard all updates) (-9 to discard all updates AND not use 'rm -i'): 2 File: /etc/pam.d/._cfg0000_system-auth ****************************************************************************** *********************** Diff obscured by pager ******************************* ****************************************************************************** 1) Replace original with update 2) Delete update, keeping original as is 3) Interactively merge original with update 4) Show differences again Please select from the menu above (-1 to ignore this update): 2 Deleting /etc/pam.d/._cfg0000_system-auth rm: remove regular file `/etc/pam.d/._cfg0000_system-auth'? y The following is the list of files which need updating, each configuration file is followed by a list of possible replacement files. 1) /etc/security/namespace.init (1) Please select a file to edit by entering the corresponding number. (don't use -3, -5, -7 or -9 if you're unsure what to do) (-1 to exit) (-3 to auto merge all remaining files) (-5 to auto-merge AND not use 'mv -i') (-7 to discard all updates) (-9 to discard all updates AND not use 'rm -i'): -5 Replacing /etc/security/namespace.init with /etc/ security/._cfg0000_namespace.init Exiting: Nothing left to do; exiting. :) cezan ~ # If EU_AUTOMERGE is set (defaults to set) then files whose only difference is in comment lines (# Something) or white-space only lines are automerged...
-
-
text.html (text/html) 4.2 kB
text.html (text/html) 12.7 kB