On Sun, Oct 13, 2024 at 12:07 AM home user via users <[email protected]> wrote: > > On 10/12/24 7:31 PM, Samuel Sieb wrote: > > On 10/12/24 6:13 PM, Jeffrey Walton wrote: > >> I would definitely consider some post-upgrade clean-ups as detailed in > >> <https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/#sect-optional-post-upgrade-tasks>. > >> > >> At minimum, there are some old packages and a lot of dangling symlinks > >> that should be cleaned up. > > > > I have never done any of that on any systems I manage... > > I sometimes need to add "--allowerasing" when I do upgrades because of > > packages that I've installed a long time ago, but that doesn't concern me. > > I've never had any issues caused by dangling symlinks. > > > > With past upgrades, I've done some of the post-upgrade tasks. > - I had trouble early on with updating configuration files. Ed suggested I > could skip it, I've skipped that step ever since. > - This upgrade was the first in which I had trouble with the clean-up retired > packages step. It crashed, and I remain suspicious it caused the trouble > addressed by this thread. I'm doubtful about doing this step in the future. > - I've been skipping the clean-up old kernels step. > - This is the first I've seen the clean-up old keys trusted for RPM package > signing step. Has anyone had trouble with this? How risky is it? > - I've had no trouble with clean-up old symlinks, but I vaguely recall > someone in this list in some past thread warning about this step being a > little risky. > - For space reasons, I no longer have a rescue kernel. > - Curious: I have not yet for this upgrade relabelled files with the latest > SELinux policy, yet I'm seeing no problems relating to SELinux. > > I hope to try some of the post-upgrade tasks Monday. But I'll skip some > altogether.
Regarding "... updating configuration files. Ed suggested I could skip it, I've skipped that step ever since" : you might consider switching to the new(ish) pattern of putting your configuration changes in the <package>.d/ directory so you don't have to mess with the package's conf file. Then you don't have problems when it comes time to take the package maintainer's version of a conf file. As an example, here are my three for SSH. The big thing to notice is, they are no longer added/modified in sshd_config, so there's never a conflict when it comes time to upgrade the package. # cat /etc/ssh/sshd_config.d/10-no_password.conf # Disable passwords PasswordAuthentication no ChallengeResponseAuthentication no KerberosAuthentication no KerberosOrLocalPasswd no GSSAPIAuthentication no UsePAM no # cat /etc/ssh/sshd_config.d/15-pubkey_auth.conf # Enable public key PubkeyAuthentication yes # cat /etc/ssh/sshd_config.d/20-no_root_login.conf PermitRootLogin no Jeff -- _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
