More dealing with .pacnew files

xtian · 2014-09-26 18:46:51

In the line of posts on pacnew files such as "Dealing with .pacnew files", what should I be careful about when replacing conf files throughout the system?

This page talks about diff'n files, and merging files. But some files are not typical conf files, right?
You're not supposed to mess with /etc/shadow in a text editor, but use the command line.
And mkinitcpio.conf would need to be reconfigured to make the RAM image.
And why is my laptop even let'n me log in when the dm-crypt hooks are not in the new conf?

Here's a partial list of /etc files

./passwd.pacnew
./shadow.pacnew
./mkinitcpio.conf.pacnew
./group.pacnew
./gshadow.pacnew

Any tales of caution I should hear before I slog through these confs?
Any fool-proof shortcuts?

Last edited by xtian (2014-09-26 23:11:48)

graysky · 2014-09-26 18:57:39

You can vimdiff shadow.pacnew against the live file, just do so using your brian.

jasonwryan · 2014-09-26 19:21:31

graysky wrote:

You can vimdiff shadow.pacnew against the live file, just do so using your brian.

And if Brian is not available?

Some of the files that you mention, like mkinitcpio.conf and your mirrorlist, are not special at all. The only file I won't use vimdiff on is sudoers.

xtian wrote:

And why is my laptop even let'n me log in when the dm-crypt hooks are not in the new conf?

Presumably because it is still a .pacnew or you haven't rebuilt your initrd...

xtian · 2014-09-26 23:25:06

I know Brian and he doesn't know a kernel from a corn.

My mistake with mkinitcpio.conf. I noticed pacman was generating a new image,

>>> Updating module dependencies. Please wait ...
>>> Generating initial ramdisk, using mkinitcpio.  Please wait...
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img

But on further inspection, it was performing the build with the correct hooks,

-> Running build hook: [encrypt]
  -> Running build hook: [lvm2]

Presumably, I need to fix this pacnew business before the next update, else the replacement conf without the necessary hooks would be the present default. Yes?

Making changes to a shadow text file is often mentioned with the same ominous tones as logging in as root. The only file I've edited with vim is groups. So, I assume using vimdiff to yank and put or merge commands between existing files is a whole other matter? In other words passwd & shadow commands aren't doing anything behind the scenes, but sudoers is?

Sorry if this seems tediously cautious, but, well it is the login secret code and ram image.

Last edited by xtian (2014-09-26 23:28:26)

fsckd · 2014-09-26 23:58:09

For shadow I use vimdiff to see the changes and update the file using the usual commandline tools. Though, it is fairly rare I have to make changes to shadow and usually end up discarding the pacnew after comparing the differences.

You don't have to use vimdiff. If you do, :e reloads the file from the disk.

Do whatever you are comfortable with. The wiki merely gives guidelines to the process. But don't neglect handling pacnews.

Edit: Clarification.

Last edited by fsckd (2014-09-27 00:08:28)

xtian · 2014-09-27 17:20:14

fsckd wrote:

Do whatever you are comfortable with..

The reason for my post is not the same as the linked post. His question was about managing the conf files. I hoped to collect some wisdom about what files need special handling. Certainly, I could then offer these as additional content on the Pacnew and Pacsave Files - Managing .pacnew files page. There is no list of files requiring special handling. In other words, files that, if altered incorrectly, might result in a user not being able to boot the machine or login. Besides Jason's comment about sudoers, I might conclude from these comments none of the files in /etc pose such a risk. But that's not true, is it?

I've been running Archlinux for just over a year now. I don't exactly recall what I did with .pacnew files before. Knowing myself, If the answer wasn't directly referred by name in the wiki (or here in forums), then I most likely just deleted the new conf and kept my older version using the rule, 'use the working config file". Only these files are updated for a reason and I can just as easily run into trouble ignoring the new file contents.

As a long time Linux user, but not a Linux programmer, I am also learned not to replace files in the system without knowing what they're doing. And to heed the general warnings of others. I appreciate the words of encouragement. In fact I appreciate all the comments here. But what I am really hoping to read are statements about files which require special handling, or statements declaring no such files exist. This would be a good subtopic for adding to the managing pacnew files section cited above. IMHO.

Last edited by xtian (2014-09-27 17:23:28)

bstaletic · 2014-09-27 18:25:04

You've listed passwd.pacnew and group.pacnew. If you ever created a non root user and set its password than both /etc/passwd and /etc/group is edited (it differs from the original). Since you are using shadow and gshadow those will also differ from the original.

The pacnew files contain the new defaults. They though do not contain your specific changes. For this reason you can't simply overwrite your files with pacnew. You also should not discard those as they may contain bug fixes from previous versions.

Just pay attention to what the changes mean. Look at news, related forum threads and search the mailing list. The mailing list is most likly to have some information about updated files. I recommend using vimdiff to see the changes more easily. You provided a link to the wiki, have you actually tried any of the mentioned packages for dealing with pacnew? If no try a few, and maybe stick to the one that suits you the most.

root · 2014-09-27 20:41:02

Adding some already existing forum info,

Correct handling of /etc/group.pacnew and /etc/passwd.pacnew

fsckd · 2014-09-28 12:09:13

xtian wrote:

As a long time Linux user, but not a Linux programmer, I am also learned not to replace files in the system without knowing what they're doing. And to heed the general warnings of others. I appreciate the words of encouragement. In fact I appreciate all the comments here. But what I am really hoping to read are statements about files which require special handling, or statements declaring no such files exist. This would be a good subtopic for adding to the managing pacnew files section cited above. IMHO.

It seems to me your instincts are on the money.

A rule of thumb is, if it is normally edited using a special tool, use that special tool to update it. Correct handling of a pacnew requires understanding the conf file in question. When you understand a file, you will know for yourself how safe it is for you to change the file using vimdiff.

colinkeenan · 2014-12-09 20:09:38

fsckd wrote:

xtian wrote:
As a long time Linux user, but not a Linux programmer, I am also learned not to replace files in the system without knowing what they're doing. And to heed the general warnings of others. I appreciate the words of encouragement. In fact I appreciate all the comments here. But what I am really hoping to read are statements about files which require special handling, or statements declaring no such files exist. This would be a good subtopic for adding to the managing pacnew files section cited above. IMHO.
It seems to me your instincts are on the money.
A rule of thumb is, if it is normally edited using a special tool, use that special tool to update it. Correct handling of a pacnew requires understanding the conf file in question. When you understand a file, you will know for yourself how safe it is for you to change the file using vimdiff.

I still think this subtopic should be added to the managing pacnew files section cited above. In particular, it is too easy from reading the wiki to get the idea that if you didn't personally touch a config file, then it's ok to just replace the old file with the pacnew one. That leads to disaster for some config files though because unknown to the newb, as pointed out in this thread, some config files are change without direct editing by the user. So, it needs to be emphasized in the wiki that 1) Some config files in your system are different from the default even though you didn't personally edit them, 2) so, it's not safe to just replace a config file with the pacnew just because you know you didn't edit it, 3) If the merging of pacnew files is not handled correctly, you may break your system even to the point that you cannot boot or login, 4) therefore, "correct handling of a pacnew requires understanding the conf file in question" in every case, even if you never previously directly touched said conf file. Then, it would also be helpful to list examples of touchy pacnew files.

xtian · 2014-12-09 21:54:52

colinkeenan wrote:

I still think this subtopic should be added to the managing pacnew files section cited above..

I would suggest the manual management of pacnew files be added to section 5 (from the table of contents).
It's a familiar Wiki pattern to receive detailed manual instruction first followed by automation shortcuts.
Also, see note below...

# Managing .pacnew files?
There are various tools to help resolve .pacnew and .pacsave file issues.
## Manually managing .pacnew files
Some config files in your system may be different from the newly installed default config files--even though you didn't personally edit them. Therefore, it's not safe to just replace a config file with the pacnew just because you know you didn't edit it.
"correct handling of a pacnew requires understanding the conf file in question"
/** NOTE:
Not sure how best to phrase this so the instruction has the form of an action and not a general warning. If we can't be more specific, how about a classic example of calamity or a gotcha
This would be the sort of place to say, Be sure to read the README file with every BLA BLA to know what certain changes mean to the proper functioning of this or that BLA. If there was such a thing...
**/
The standard (s)diff (from diffutils) provides an easy way to compare these files. See List of applications/Utilities#Comparison, diff, merge for other common comparison tools.
## Automating .pacnew file management
A few third-party utilities providing various levels of automation for these tasks are available from the AUR.
You can use one of the following tools:
[...]

Arch Linux

#1 2014-09-26 18:46:51

More dealing with .pacnew files

#2 2014-09-26 18:57:39

Re: More dealing with .pacnew files

#3 2014-09-26 19:21:31

Re: More dealing with .pacnew files

#4 2014-09-26 23:25:06

Re: More dealing with .pacnew files

#5 2014-09-26 23:58:09

Re: More dealing with .pacnew files

#6 2014-09-27 17:20:14

Re: More dealing with .pacnew files

#7 2014-09-27 18:25:04

Re: More dealing with .pacnew files

#8 2014-09-27 20:41:02

Re: More dealing with .pacnew files

#9 2014-09-28 12:09:13

Re: More dealing with .pacnew files

#10 2014-12-09 20:09:38

Re: More dealing with .pacnew files

#11 2014-12-09 21:54:52

Re: More dealing with .pacnew files

Board footer