Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #193979 > unrolled thread

how to view config file changes without running an upgrade?

Back to article view | Back to linux.debian.user

Contents

  how to view config file changes without running an upgrade? Harald Dunkel <harald.dunkel@aixigo.de> - 2018-03-21 09:20 +0100
    Re: how to view config file changes without running an upgrade? The Wanderer <wanderer@fastmail.fm> - 2018-03-21 12:50 +0100
      Re: how to view config file changes without running an upgrade? rhkramer@gmail.com - 2018-03-21 13:30 +0100
        Re: how to view config file changes without running an upgrade? Hans <hans.ullrich@loop.de> - 2018-03-21 14:30 +0100
      Re: how to view config file changes without running an upgrade? Curt <curty@free.fr> - 2018-03-21 14:50 +0100
        Re: how to view config file changes without running an upgrade? Curt <curty@free.fr> - 2018-03-21 15:20 +0100
          Re: how to view config file changes without running an upgrade? Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-03-21 16:40 +0100
            Re: how to view config file changes without running an upgrade? deloptes <deloptes@gmail.com> - 2018-03-21 22:00 +0100
              Re: how to view config file changes without running an upgrade? Richard Hector <richard@walnut.gen.nz> - 2018-03-21 22:40 +0100
                Re: how to view config file changes without running an upgrade? deloptes <deloptes@gmail.com> - 2018-03-21 22:50 +0100
                  Re: how to view config file changes without running an upgrade? Curt <curty@free.fr> - 2018-03-22 11:20 +0100
                    Re: how to view config file changes without running an upgrade? felmon davis <moelmoel2714@gmail.com> - 2018-03-27 09:00 +0200
                      Re: how to view config file changes without running an upgrade? Curt <curty@free.fr> - 2018-03-27 09:30 +0200
              Re: how to view config file changes without running an upgrade? Jason <electron@emypeople.net> - 2018-03-22 03:30 +0100
      Re: how to view config file changes without running an upgrade? Harald Dunkel <harald.dunkel@aixigo.de> - 2018-03-21 16:50 +0100
        Re: how to view config file changes without running an upgrade? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-03-21 17:20 +0100
          Re: how to view config file changes without running an upgrade? deloptes <deloptes@gmail.com> - 2018-03-21 22:00 +0100
          Re: how to view config file changes without running an upgrade? Harald Dunkel <harald.dunkel@aixigo.de> - 2018-03-22 11:20 +0100
            Re: how to view config file changes without running an upgrade? Tomaž Šolc <tomaz.solc@tablix.org> - 2018-03-23 10:20 +0100
    Re: how to view config file changes without running an upgrade? David Wright <deblis@lionunicorn.co.uk> - 2018-03-21 16:00 +0100
      Re: how to view config file changes without running an upgrade? Greg Wooledge <wooledg@eeg.ccf.org> - 2018-03-21 16:20 +0100
        Re: how to view config file changes without running an upgrade? David Wright <deblis@lionunicorn.co.uk> - 2018-03-21 18:20 +0100
      Re: how to view config file changes without running an upgrade? <tomas@tuxteam.de> - 2018-03-21 16:20 +0100
    Re: how to view config file changes without running an upgrade? Harald Dunkel <harald.dunkel@aixigo.de> - 2018-03-21 17:00 +0100

Page 1 of 2  [1] 2  Next page →

#193979 — how to view config file changes without running an upgrade?

Hi folks,

How can I view the diffs between my local modified config file
(maybe modified 2 years ago) and the maintainer's config file
included in the currently installed package or in a pending
package upgrade? I would like to review my diffs, before running
"apt upgrade".

I am a big fan of etckeeper, but it cannot help in this case:
It looses track of the unmodified config files included with new
package versions.


Regards
Harri

[toc] | [next] | [standalone]

#193981

[Multipart message — attachments visible in raw view] — view raw

On 2018-03-21 at 04:13, Harald Dunkel wrote:

> Hi folks,
> 
> How can I view the diffs between my local modified config file (maybe
> modified 2 years ago) and the maintainer's config file included in
> the currently installed package or in a pending package upgrade? I
> would like to review my diffs, before running "apt upgrade".

In my experience, when (what I think Debian officially calls) a conffile
has been locally modified, the upgrade process (by default) halts and
presents a prompt asking the user what to do; the options include "show
a diff of the contents", "background the install so other actions can be
taken", "keep the locally-modified version", and "replace the local
version with the package's version". I think there's an apt config
option to affect this, but I don't know what it is or exactly where to
find out.

So... are you entirely sure that you even need to check it *before*
initiating the upgrade? The mid-upgrade prompt might be enough.

If so, the only way of doing so that I can think of would be to get the
source of the relevant version of the relevant package ('apt-get source
packagename') and look at the copy of the relevant file from under that
source tree. (And possibly check for the presence of scripts that might
automatically modify that during the package build, or even during the
preinst, but I would expect that such a situation would be rare.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#193982

On Wednesday, March 21, 2018 07:44:35 AM The Wanderer wrote:
> In my experience, when (what I think Debian officially calls) a conffile
> has been locally modified, the upgrade process (by default) halts and
> presents a prompt asking the user what to do; the options include "show
> a diff of the contents", "background the install so other actions can be
> taken", "keep the locally-modified version", and "replace the local
> version with the package's version". I think there's an apt config
> option to affect this, but I don't know what it is or exactly where to
> find out.

To the OP (and all), it is probably obvious to all concerned, but, just as 
reminder, being uncertain about whether the upgrade process proceeds as 
described above ("halts and presents a prompt ..."), I would make a backup of 
the modified conf file and store it somewhere safe (rename and or move to a 
directory).

[toc] | [prev] | [next] | [standalone]

#193983

Yes, that is how I do it, too. 

First of all, all edited config files by me are copied to *.orig .
Doing so, I know, that these are the one of the package).

After I edited them, I copy the edited file to *.backup
Doing so, I know, these are the last edited files.


It happens, that I test some configs. After edited to testing needs, 
I copy these to *.backup1 or *.testing1
Doing so, I know, they are only used for a short time and the application have 
to be watched.

A good way (IMO) is also to copy a config file to *.date, like  i.e.
*.21032018, so I know, these are changed at 21st March 2018. 

For me, this bahaviour is working well, as I can always return to every point 
I want.

Happy hacking and good luck!

Hans 
> To the OP (and all), it is probably obvious to all concerned, but, just as
> reminder, being uncertain about whether the upgrade process proceeds as
> described above ("halts and presents a prompt ..."), I would make a backup
> of the modified conf file and store it somewhere safe (rename and or move
> to a directory).

[toc] | [prev] | [next] | [standalone]

#193984

On 2018-03-21, The Wanderer <wanderer@fastmail.fm> wrote:
>
>> Hi folks,
>>=20
>> How can I view the diffs between my local modified config file (maybe
>> modified 2 years ago) and the maintainer's config file included in
>> the currently installed package or in a pending package upgrade? I
>> would like to review my diffs, before running "apt upgrade".
>
> In my experience, when (what I think Debian officially calls) a conffile
> has been locally modified, the upgrade process (by default) halts and
> presents a prompt asking the user what to do; the options include "show
> a diff of the contents", "background the install so other actions can be
> taken", "keep the locally-modified version", and "replace the local
> version with the package's version". I think there's an apt config
> option to affect this, but I don't know what it is or exactly where to
> find out.
>

It looks like this:

Configuration file `/etc/dhcp/dhclient.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** dhclient.conf (Y/I/N/O/D/Z) [default=N] ?

man dpkg (confmiss, confnew, confold, confdef, confask). 
      
So with apt you can presumably do something like:

 apt-get -o Dpkg::Options::="--force-confold" -dist-upgrade

(Which would preserve the user-modified conffile with prompting.)

-- 
Bah, the latest news, the latest news is not the last.
Samuel Beckett

[toc] | [prev] | [next] | [standalone]

#193986

On 2018-03-21, Curt <curty@free.fr> wrote:
>       
> So with apt you can presumably do something like:
>
>  apt-get -o Dpkg::Options::="--force-confold" -dist-upgrade
>
> (Which would preserve the user-modified conffile with prompting.)
                                                   ****
						   without! Jesus.


-- 
Bah, the latest news, the latest news is not the last.
Samuel Beckett

[toc] | [prev] | [next] | [standalone]

#193990

On 3/21/18, Curt <curty@free.fr> wrote:
> On 2018-03-21, Curt <curty@free.fr> wrote:
>>
>> So with apt you can presumably do something like:
>>
>>  apt-get -o Dpkg::Options::="--force-confold" -dist-upgrade
>>
>> (Which would preserve the user-modified conffile with prompting.)
>                                                    ****
> 						   without! Jesus.


I fully empathize. Constantly and getting worse over time. I just
tried to write a three or four paragraph email to a raptor
rehabilitation list. One last proofread before sending found at least
four completely missing words. :D

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with a few less words spewing off the keyboard these days (not
as good as it sounds) *

[toc] | [prev] | [next] | [standalone]

#194011

Cindy-Sue Causey wrote:

> I fully empathize. Constantly and getting worse over time. I just
> tried to write a three or four paragraph email to a raptor
> rehabilitation list. One last proofread before sending found at least
> four completely missing words. :D

The rule "check, double check and then proceed" - always payed off for me.
Luckily most of simple typos are caught by the spell checked, so reading
before sending is mostly meant to catch the semantic mistakes.

regards

[toc] | [prev] | [next] | [standalone]

#194021

[Multipart message — attachments visible in raw view] — view raw

On 22/03/18 09:53, deloptes wrote:
> The rule "check, double check and then proceed" - always payed off for me.
> Luckily most of simple typos are caught by the spell checked, so reading
> before sending is mostly meant to catch the semantic mistakes.

Where 'checked' was presumably the debilitate one :-)

Richard

[toc] | [prev] | [next] | [standalone]

#194023

Richard Hector wrote:

> Where 'checked' was presumably the debilitate one :-)

true, sorry - even double checking fails sometime :D

[toc] | [prev] | [next] | [standalone]

#194048

On 2018-03-21, deloptes <deloptes@gmail.com> wrote:
> Richard Hector wrote:
>
>> Where 'checked' was presumably the debilitate one :-)
>
> true, sorry - even double checking fails sometime :D
>
>

When Norman Mailer's Harlot's Ghost was published it contained a
grammatical error in the first sentence (and one can only imagine how
many human minds proof-read the thing before it went to press): 

Here it is:

 "On a late-winter evening in 1983, while driving through the fog along
 the Maine coast, recollections of old campfires began to drift into the
 March mist, and I thought of the Abnaki Indians of the Algonquin tribe
 who dwelt near Bangor a thousand years ago."

The error was subsequently corrected.

So take heart.



-- 
Bah, the latest news, the latest news is not the last.
Samuel Beckett

[toc] | [prev] | [next] | [standalone]

#194197

[Multipart message — attachments visible in raw view] — view raw

On Thu, Mar 22, 2018 at 6:07 AM, Curt <curty@free.fr> wrote:

> On 2018-03-21, deloptes <deloptes@gmail.com> wrote:
> > Richard Hector wrote:
> >
> >> Where 'checked' was presumably the debilitate one :-)
> >
> > true, sorry - even double checking fails sometime :D
> >
> >
>
> When Norman Mailer's Harlot's Ghost was published it contained a
> grammatical error in the first sentence (and one can only imagine how
> many human minds proof-read the thing before it went to press):
>
> Here it is:
>
>  "On a late-winter evening in 1983, while driving through the fog along
>  the Maine coast, recollections of old campfires began to drift into the
>  March mist, and I thought of the Abnaki Indians of the Algonquin tribe
>  who dwelt near Bangor a thousand years ago."
>
> The error was subsequently corrected.
>
> So take heart.
>

a lot of the old grammatical categories have died out; the "dangling
modifier" error has gone the way of the "split infinitive".

f.


>
>
>
> --
> Bah, the latest news, the latest news is not the last.
> Samuel Beckett
>
>

[toc] | [prev] | [next] | [standalone]

#194198

On 2018-03-27, felmon davis <moelmoel2714@gmail.com> wrote:
>
> a lot of the old grammatical categories have died out; the "dangling
> modifier" error has gone the way of the "split infinitive".
>
> f.

Yeah old Norman himself died out too I'm afraid, few years back.

-- 
Bah, the latest news, the latest news is not the last.
Samuel Beckett

[toc] | [prev] | [next] | [standalone]

#194036

On Wed, Mar 21, 2018 at 09:53:13PM +0100, deloptes wrote:
> Cindy-Sue Causey wrote:
> 
> > I fully empathize. Constantly and getting worse over time. I just
> > tried to write a three or four paragraph email to a raptor
> > rehabilitation list. One last proofread before sending found at least
> > four completely missing words. :D
> 
> The rule "check, double check and then proceed" - always payed off for me.
                                                           ^paid^
> Luckily most of simple typos are caught by the spell checked, so reading
               ^the^                                  ^checker^
> before sending is mostly meant to catch the semantic mistakes.
> 
> regards
> 

Have a good night.

Best regards,
-- 
Jason

[toc] | [prev] | [next] | [standalone]

#193992

On 03/21/18 12:44, The Wanderer wrote:
> On 2018-03-21 at 04:13, Harald Dunkel wrote:
> 
> 
> So... are you entirely sure that you even need to check it *before*
> initiating the upgrade? The mid-upgrade prompt might be enough.
> 

Yes, I am sure.

Its pretty painful to resolve config file conflicts in (lets say)
dovecot at upgrade time, putting EMail access for +200 users at risk.
I have to check in advance. Resolving config file conflicts during
the upgrade is too late.

> If so, the only way of doing so that I can think of would be to get the
> source of the relevant version of the relevant package ('apt-get source
> packagename') and look at the copy of the relevant file from under that
> source tree. (And possibly check for the presence of scripts that might
> automatically modify that during the package build, or even during the
> preinst, but I would expect that such a situation would be rare.)
> 

Now your assumption is that I know in advance, which packages produce a
conflict. I cannot tell.

To check I would like to run something like

	checkconfig xyz.deb

after download, but before upgrade of package xyz.

Of course I could open the deb file, grab all config files and diff them
with the installed version. But it would be very nice to get an "official"
tool for this.


Regards
Harri

[toc] | [prev] | [next] | [standalone]

#193996

On Wed, Mar 21, 2018 at 04:46:16PM +0100, Harald Dunkel wrote:
> Its pretty painful to resolve config file conflicts in (lets say)
> dovecot at upgrade time, putting EMail access for +200 users at risk.
> I have to check in advance. Resolving config file conflicts during
> the upgrade is too late.

Then you need a second system, to test the upgrades on.  If you don't
keep one around at all times, then you could create one on the fly
with debootstrap, rsync your current configs into it, and test the
upgrade in there.

[toc] | [prev] | [next] | [standalone]

#194012

Greg Wooledge wrote:

> Then you need a second system, to test the upgrades on.  If you don't
> keep one around at all times, then you could create one on the fly
> with debootstrap, rsync your current configs into it, and test the
> upgrade in there.

+1

I would never keep my mails on a system administrated by such admin.

There is clear ITIL process and you need at least two systems to comply.

Everything else you can do at home for fun.

[toc] | [prev] | [next] | [standalone]

#194049

On 03/21/18 17:18, Greg Wooledge wrote:
> On Wed, Mar 21, 2018 at 04:46:16PM +0100, Harald Dunkel wrote:
>> Its pretty painful to resolve config file conflicts in (lets say)
>> dovecot at upgrade time, putting EMail access for +200 users at risk.
>> I have to check in advance. Resolving config file conflicts during
>> the upgrade is too late.
> 
> Then you need a second system, to test the upgrades on.  If you don't
> keep one around at all times, then you could create one on the fly
> with debootstrap, rsync your current configs into it, and test the
> upgrade in there.
> 

We have tons of stage systems. EMail stage systems are especially painful.
They are constantly out of sync to the production host, making it even
more necessary to review the diffs between the config files in the most
recent packages and the installed files *before* running an upgrade.

Dovecot was just an example, anyway.

Regards
Harri

[toc] | [prev] | [next] | [standalone]

#194073

[Multipart message — attachments visible in raw view] — view raw

On 22. 03. 2018 11:14, Harald Dunkel wrote:
> On 03/21/18 17:18, Greg Wooledge wrote:
>> Then you need a second system, to test the upgrades on.  If you don't
>> keep one around at all times, then you could create one on the fly
>> with debootstrap, rsync your current configs into it, and test the
>> upgrade in there.
>>
> 
> We have tons of stage systems. EMail stage systems are especially painful.
> They are constantly out of sync to the production host, making it even
> more necessary to review the diffs between the config files in the most
> recent packages and the installed files *before* running an upgrade.
> 
> Dovecot was just an example, anyway.

How I've done it in the past for Dovecot and Exim is to copy the root
filesystem from the server to another machine, chroot into it and then
upgrade the dovecot- and exim-related packages.

Review any config file changes in the chroot, test the config as far as
it can be done offline, and then run the upgrade on the server (with
everything backed up first, of course)

Best regards
Tomaž

[toc] | [prev] | [next] | [standalone]

#193987

On Wed 21 Mar 2018 at 09:13:43 (+0100), Harald Dunkel wrote:
> How can I view the diffs between my local modified config file
> (maybe modified 2 years ago) and the maintainer's config file
> included in the currently installed package or in a pending
> package upgrade? I would like to review my diffs, before running
> "apt upgrade".

If you unpack the package somewhere, either using ar etc or,
more easily, by selecting it in mc and copying CONTENTS into,
say, /tmp

$ for j in $(dpkg -L packagename) ; do [ -f $j ] && diff -u $j /tmp/CONTENTS/$j ; done

will list any changes. For example:

$ for j in $(dpkg -L initramfs-tools) ; do [ -f $j ] && diff -u $j /tmp/CONTENTS/$j ; done
--- /etc/initramfs-tools/update-initramfs.conf  2018-01-22 15:19:07.666686422 -0600
+++ /tmp/CONTENTS//etc/initramfs-tools/update-initramfs.conf 2014-10-27 00:00:00.000000000 -0500
@@ -17,4 +17,4 @@
 # Default is no
 # If set to no leaves no .bak backup files.
 
-backup_initramfs=yes
+backup_initramfs=no
$ 

Add quotes "" to taste. And you may need to   chmod u+w /tmp/CONTENTS
to clear it out when finished.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web