What to do with *.pacnew config files

vfsoraki · 2020-10-06 12:54:23

Hello

Once in a while, updating packages gives this (just as an example):

warning: /etc/pulse/default.pa installed as /etc/pulse/default.pa.pacnew
warning: /etc/pulse/system.pa installed as /etc/pulse/system.pa.pacnew

I have never changed those config files. Is this the default behavior to not overwrite new config files if it is the original one?

What should I do? Replace them? Not to replace them? See diff and merge accordingly?

I don't know what would happen if I change those config files to the new ones (either by merging or replacing) as I probably don't know the impact of it on other packages.

So what is the de facto strategy here?

EDIT: I just remembered another question. Is there anyway to see past "pacnew" config files that pacman complained about? I remember seeing these warnings once in a while, but I didn't do anything ever. Is there a nice way (except "ls -R / | grep pacnew") to see warnings pacman generated?

Last edited by vfsoraki (2020-10-06 12:59:12)

graysky · 2020-10-06 13:00:45

Recommend you search before posting. We also have an excellent wiki. Hint: https://wiki.archlinux.org/index.php/Pa … nd_Pacsave

Wild Penguin · 2020-10-06 13:11:44

I, too, am interested on this. I think Arch does not have a good enough infrastructure to make dealing with these files streamlined. However I can understand the status quo, as it fits the goals of Arch as a distribution, as far as I've understood them...

Anyways, I believe the correct Wiki page to refer to is: pacman/Pacnew and Pacsave. I believe the "de facto strategy" would be to deal with them manually. I.e. use a diff utility of your choice and merge files manually - or at most, set up a pacman hook.

There is an option of a pacman hook, but the current example forces an interactive solution, which, as a lazy person using my computer for my personal gain, is exactly opposite to what I actually want.

I yearn for something similar to Gentoos configuration file update management contributions, but I haven't found anything as robust in the contrib section nor in AUR - but I haven't tried everything mentioned there. I'm curious to hear what other users are using.

My personal preferences / wishes would be for a configuration file update utility: update as much as possible automatically - even merge my existing changes! However, there should be some kind of backlog facility in place. Have a good, robust integration to my choice of diff/merging utilities to make those merges, which can not be handled automatically.

Last edited by Wild Penguin (2020-10-06 13:15:41)

vfsoraki · 2020-10-06 13:38:30

graysky wrote:

Recommend you search before posting. We also have an excellent wiki. Hint: https://wiki.archlinux.org/index.php/Pa … nd_Pacsave

Thanks, I see. Sorry, I don't know how I could have missed that wiki page.

For now, seems like I'm stuck manually merging files.

As a side note, I don't think I have ever changed those config files myself, yet pacman thinks I have manually changed them. This Arch installation is rather old (3 or 4 years old), so I am not sure, but I don't remember changing those files.

eschwartz · 2020-10-06 15:41:58

Wild Penguin wrote:

I, too, am interested on this. I think Arch does not have a good enough infrastructure to make dealing with these files streamlined. However I can understand the status quo, as it fits the goals of Arch as a distribution, as far as I've understood them...

What does this have to do with arch infrastructure? Per policy, Arch does not believe in automated debian-style maintenance scripts to patch your config files. There are, however, other options which center around interactively being prompted for it.

pacdiff from community/pacman-contrib, can launch pacnew files in vimdiff
pacdiffviewer from AUR/yaourt, backs up the old and new versions of the file, and tries to generate an automerge diff to be applied with `patch`, which will be shown to you and you may accept it or not as you please. If the package changes don't conflict with your local modifications, this works beautifully. If that fails, it uses the same logic as pacdiff.
AUR/etc-update from Gentoo

Wild Penguin wrote:

Anyways, I believe the correct Wiki page to refer to is: pacman/Pacnew and Pacsave. I believe the "de facto strategy" would be to deal with them manually. I.e. use a diff utility of your choice and merge files manually - or at most, set up a pacman hook.
There is an option of a pacman hook, but the current example forces an interactive solution, which, as a lazy person using my computer for my personal gain, is exactly opposite to what I actually want.
I yearn for something similar to Gentoos configuration file update management contributions, but I haven't found anything as robust in the contrib section nor in AUR - but I haven't tried everything mentioned there. I'm curious to hear what other users are using.
My personal preferences / wishes would be for a configuration file update utility: update as much as possible automatically - even merge my existing changes! However, there should be some kind of backlog facility in place. Have a good, robust integration to my choice of diff/merging utilities to make those merges, which can not be handled automatically.

Many changes simply cannot be made in an automated manner. But there are multiple tools which can try to do so where possible, and "force" an interactive solution where that's genuinely the best option.

In fact, you cannot have searched too hard if you yearn for "something similar to Gentoos configuration file update management contributions" but didn't notice one of those very Gentoo tools is literally an AUR package, due to the Gentoo tool containing upstream support for pacman and rpm.

Last edited by eschwartz (2020-10-06 16:59:30)

860lacov · 2020-10-06 16:43:14

Well
I opened this post out of curiosity.
Then I run pacdiff and chose O for every instance and... my root privileges diapered.
Thats the reason (I think):

==> pacnew file found for /etc/sudoers

I managed to chroot into my system and use timeshift so everything is ok now but I'll need a little help.
I decided to look into differences between files.
I have pacnew files for:

1. /etc/shadow
New files have got a lot of lines. In old one there is only one. Have no idea if this is important.

2. /etc/locale.gen
This one is easier for me. There are 2 differences.
a) No # sign in front of my language (my choice during installation).
b) in pacnew there is new line added: #ckb_IQ UTF-8
I'm not sure what would I do. I don't need #ckb_IQ UTF-8 but I don't know if it's important for system.

3. ssh_config
Changes are in version number and in X11 forwarding

4. pacman mirrorlist
I use reflector for mirrorlist, so I believe that It is safe to remove pacnew

5. /etc/sudoers
Two differences
members of wheel group - reasonable because I've removed comment in this line

But second change I don't understand
pacnew:

## Read drop-in files from /etc/sudoers.d
@includedir /etc/sudoers.d

current:

## Read drop-in files from /etc/sudoers.d
## (the '#' here does not indicate a commend)

I read wiki about those files but I'm not sure how to deal with them.

1. files from /etc can be shown if pacdiff is running as sudo. Is that safe?

2. How those files should be merged? Should I edit pacnew files and then run pacdiff and chose to overwrite with pacnew?

3. The biggest concern I have with shadow file and sudoers file. What to do with them?

Last edited by 860lacov (2020-10-06 16:44:17)

eschwartz · 2020-10-06 17:03:16

1) Don't let people read over your shoulder, I guess? You're root, of course you can choose to view secure files.

2) pacdiff "(V)iew" prompts you to edit both of them. Once you're happy with the new conf file version, get rid of the pacnew comparison using "(R)emove pacnew"

3)

Never ever accept shadow updates. It's a plaintext database and all changes are applied via "useradd", "userdel", "systemd-sysusers" or similar. The pacdiff file will revert your user accounts database to the "newly installed, no users created" state, which is... obviously bad if you ever want to login.

The sudoers change is because "#include" is old, confusing syntax, so upstream added "@include" to do the same thing, but less confusingly, and the default file ships with the new syntax. You may freely "sudo visudo" and change that, using visudo rather than pacdiff for the extra protection against accidentally breaking the config file.

cowlick · 2020-10-06 17:07:10

I find I do more damage bytrying to reconcile the pacnew files. I've never had a problem by simply deleting the pacnew files.

Scimmia · 2020-10-06 17:10:02

cowlick wrote:

I find I do more damage bytrying to reconcile the pacnew files. I've never had a problem by simply deleting the pacnew files.

And yet we had a bunch of people in here recently that made it impossible to log into their system because they ignored .pacnew files (same as deleting them). You may have been that lucky, but don't advise anyone else to do something so stupid.

Last edited by Scimmia (2020-10-06 17:10:19)

eschwartz · 2020-10-06 17:11:00

cowlick wrote:

I find I do more damage bytrying to reconcile the pacnew files. I've never had a problem by simply deleting the pacnew files.

Have you by any chance seen the recent pam_tally2 issues? Good luck with that. You can easily end up with an unbootable system.

cowlick · 2020-10-06 17:14:59

Scimmia wrote:

cowlick wrote:
I find I do more damage bytrying to reconcile the pacnew files. I've never had a problem by simply deleting the pacnew files.
And yet we had a bunch of people in here recently that made it impossible to log into their system because they ignored .pacnew files (same as deleting them). You may have been that lucky, but don't advise anyone else to do something so stupid.

Then fix pacman. You get nowhere calling me stupid.

Scimmia · 2020-10-06 17:22:56

There's nothing to fix in pacman. It's working as intended.

I did not call you stupid. I said what you're doing is stupid, and I stand by that.

860lacov · 2020-10-06 17:30:45

eschwartz wrote:

Never ever accept shadow updates. It's a plaintext database and all changes are applied via "useradd", "userdel", "systemd-sysusers" or similar. The pacdiff file will revert your user accounts database to the "newly installed, no users created" state, which is... obviously bad if you ever want to login.
The sudoers change is because "#include" is old, confusing syntax, so upstream added "@include" to do the same thing, but less confusingly, and the default file ships with the new syntax. You may freely "sudo visudo" and change that, using visudo rather than pacdiff for the extra protection against accidentally breaking the config file.

So just to be clear

1. shadow.pacnew can (and should be deleted)

2. I can make edits to sudoers file. Leave wheel group uncommented, and change line with different syntax, and then remove sudoers pacnew file?

2.1 Can I just remove # in sudoers pacnew file in the line where wheel group is (I have it in my current file) and then with pacdiff choose to overwrite with pacnew?

Last edited by 860lacov (2020-10-06 17:31:39)

eschwartz · 2020-10-06 17:34:13

860lacov wrote:

2.1 Can I just remove # in sudoers file in the line where wheel group is (I have it in my current file) and then with pacdiff choose to overwrite with pacnew?

There's no technical reason I can think of whyyou cannot edit the pacnew file, then use it to overwrite the original file. Though personally I'd find that a disorganized approach. But if it works for you, then go right ahead.

860lacov · 2020-10-06 17:39:56

eschwartz wrote:

860lacov wrote:
2.1 Can I just remove # in sudoers file in the line where wheel group is (I have it in my current file) and then with pacdiff choose to overwrite with pacnew?
There's no technical reason I can think of why you cannot edit the pacnew file, then use it to overwrite the original file. Though personally I'd find that a disorganized approach. But if it works for you, then go right ahead.

The reason is quite simple. I would call it logical reason.
In current sudoers file I have to copy and replace a whole line. In pacnew I just need to remove # from one line. About one key press more
And to be honest I don't remember how to copy and paste lines in vim or nano, so I would have to rewrite line

And one more.
If shadow should never be updated why pacman is creating pacnew file for it?

Last edited by 860lacov (2020-10-06 17:42:55)

eschwartz · 2020-10-06 17:43:06

vim has ":dp" and ":do" for diff put and diff obtain, for use in vimdiff mode to merge sections for you. But sure.

cowlick · 2020-10-06 18:07:24

Scimmia wrote:

There's nothing to fix in pacman. It's working as intended.
I did not call you stupid. I said what you're doing is stupid, and I stand by that.

From pacman(8):
"
Bugs

Bugs? You must be kidding; there are no bugs in this software. But if we happen to be wrong, submit a bug report with as much detail as possible at the Arch Linux Bug Tracker in the Pacman section."

I'm too stupid to find bugs.

Wild Penguin · 2020-10-06 19:46:03

eschwartz wrote:

Wild Penguin wrote:
I, too, am interested on this. I think Arch does not have a good enough infrastructure to make dealing with these files streamlined. However I can understand the status quo, as it fits the goals of Arch as a distribution, as far as I've understood them...
What does this have to do with arch infrastructure? Per policy, Arch does not believe in automated debian-style maintenance scripts to patch your config files. There are, however, other options which center around interactively being prompted for it.

I realize I have chosen the word "infrastructure" here, despite it is not the best word to convey what I mean. However, the point (more OOTB/configurable options to handle them) was mitigated by my own words (at that might not fit Arch goals of simplicity). So, considering that one badly chosen word on my part, I believe we are in agreement here.

eschwartz wrote:

In fact, you cannot have searched too hard if you yearn for "something similar to Gentoos configuration file update management contributions" but didn't notice one of those very Gentoo tools is literally an AUR package, due to the Gentoo tool containing upstream support for pacman and rpm.

One of them is in there, yes. I have tried it and used it quite a lot with Gentoo, too, way back when I used Gentoo.... until I found something more robust. Sadly, it was years ago and I don't actually remember what I used back then.

Also, as I said - I haven't tried everything available/listed on the said Wiki page. Hence, I already asked (though indirectly) for other users suggestions.

As such, I'd be happy to hear opinions, on what people have found best for their use case!

2ManyDogs · 2020-10-06 20:01:07

I think the OP's question has been adequately answered. We're done.

Closing.

Arch Linux

#1 2020-10-06 12:54:23

What to do with *.pacnew config files

#2 2020-10-06 13:00:45

Re: What to do with *.pacnew config files

#3 2020-10-06 13:11:44

Re: What to do with *.pacnew config files

#4 2020-10-06 13:38:30

Re: What to do with *.pacnew config files

#5 2020-10-06 15:41:58

Re: What to do with *.pacnew config files

#6 2020-10-06 16:43:14

Re: What to do with *.pacnew config files

#7 2020-10-06 17:03:16

Re: What to do with *.pacnew config files

#8 2020-10-06 17:07:10

Re: What to do with *.pacnew config files

#9 2020-10-06 17:10:02

Re: What to do with *.pacnew config files

#10 2020-10-06 17:11:00

Re: What to do with *.pacnew config files

#11 2020-10-06 17:14:59

Re: What to do with *.pacnew config files

#12 2020-10-06 17:22:56

Re: What to do with *.pacnew config files

#13 2020-10-06 17:30:45

Re: What to do with *.pacnew config files

#14 2020-10-06 17:34:13

Re: What to do with *.pacnew config files

#15 2020-10-06 17:39:56

Re: What to do with *.pacnew config files

#16 2020-10-06 17:43:06

Re: What to do with *.pacnew config files

#17 2020-10-06 18:07:24

Re: What to do with *.pacnew config files

#18 2020-10-06 19:46:03

Re: What to do with *.pacnew config files

#19 2020-10-06 20:01:07

Re: What to do with *.pacnew config files

Board footer