Fedora

Comparing RPM packages between two systems

I needed to sync two different Fedora boxes, such that they have similar (but not identical) packages installed. This turns out to be fairly straight forward with some basic command line utilities. First, create a list of all packages on each machine, with something like

$ rpm -qa --queryformat='%{NAME}\n' | sort > machine-1.txt
$ rpm -qa --queryformat='%{NAME}\n' | sort > machine-2.txt

​Then, using the -f option to grep, you can see what's missing from each system. E.g.

$ grep -v -f machine-1.txt machine-2.txt

Hacking: 

Fedora 24 issues on VirtualBox

As of some recent upgrades to my F24 VM (running under VirtualBox), my system would not boot properly any more, getting errors like

NMI watchdog: BUG: soft lockup - CPU#0 stuck

 

I couldn't find any details as to why this was, other than someone having similar issues with a bad GPU card (not under a VM). I checked my display settings for the VM, which had the minimum recommended setting of 21MB. This ought to have been plenty, since I run my Linux system in a head-less mode (no display etc.). However, Linux must have changed something, cause this no longer worked, but bumping the GPU memory to 32MB seems to have fixed it. Bizarre.

Hacking: 

firewalld and network interfaces

I have to say, firewalld and firewalld-cmd really sucks. But, since it's the default on a bunch of installations I use, and I try to "drink the koolaid", I've had the misfortune to try to set it up. Now, it mostly works, except when it doesn't, and then it really fails hard. Case in point, I wanted to reassign some network interfaces to a different zone, and naïvely thought that e.g. this would work:

$ sudo firewall-cmd --permanent --zone=public --remove-interface=eth2
$ sudo firewall-cmd --permanent --zone=internal --add-interface=eth2

 

Yeah, not so much ... What does instead work is adding lines like this to /etc/sysconfig/network-scripts/ifcfg-eth2:

ZONE=internal

WTF?

Hacking: 

Seting up sudo access with PAM and ssh-agent

For Fedora, first install the following package:

$ sudo yum install pam_ssh_agent_auth

Then edit /ets/sudoers, and add the following line:

Defaults    env_keep += "SSH_AUTH_SOCK"
Defaults    timestamp_timeout  = 0  # Not necessary, but turns off caching

Finally, edit /etc/pam.d/sudo, and add something like this (this should be adjusted to your preferences):

auth       sufficient   pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

Hacking: 

Clamav installation failing on Fedora Core 18

Someone majorly botched the clamav packages in Fedora 18, where the packages fail to create the appropriate user ID and group ID. The output from the yum install looks like

Running Transaction
  Installing : clamav-data-empty-0.97.8-1.fc18.noarch                       1/5 
  Installing : clamav-lib-0.97.8-1.fc18.x86_64                              2/5 
Usage: groupadd [options] GROUP

Options:
  -f, --force                   exit successfully if the group already exists,
                                and cancel -g if the GID is already used
  -g, --gid GID                 use GID for the new group
  -h, --help                    display this help message and exit
  -K, --key KEY=VALUE           override /etc/login.defs defaults
  -o, --non-unique              allow to create groups with duplicate
                                (non-unique) GID
  -p, --password PASSWORD       use this encrypted password for the new group
  -r, --system                  create a system account
  -R, --root CHROOT_DIR         directory to chroot into

useradd: group 'clamupdate' does not exist
  Installing : clamav-filesystem-0.97.8-1.fc18.noarch                       3/5 

This is reported in RedHat bug 963920. As commented on this bug, the work around is to assure these users are created before installing the clamav packages. E.g.

$ sudo yum remove clamav\*  # Be careful with this, make sure you are not losing anything you wish to keep
$ sudo groupadd -r clamupdate
$ sudo useradd -r -g clamupdate -d /var/lib/clamav -s /sbin/nologin -c "Clamav database update user" clamupdate
$ sudo yum install clamav-data clamav clamav-update clamav-milter

Hacking: 

Missing emacs symlink on Fedora Core

I just finished installing Fedora Core 16 on a new router I'm planinng on installing up in our little cabin. Things went mostly well, except the symlink to Emacs was missing. The horror! The RPM was most certainly install, but no emacs in my path was to be found. Well, it turns out, for some reason (who knows why ...), the installer did not finish creating the Emacs symlink. It's quite possible it missed other links too, but Emacs was obviously the number one priority. Poking around a little, it was easy to restore life as we know it:

sudo alternatives --install /usr/bin/emacs emacs /usr/bin/emacs-23.3 10

Hacking: 

yum failures with missing $releasever

During an upgrade (yum update) on a Fedora VM, something went horribly wrong, and it crashed in the middle of the update. After rebooting, and cleaning up the mess, yum still was very unhappy. Running an update would give me errors like

Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=x86_64 error was 
No repomd file
Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again

Very odd. It turns out, $releasever was not properly set, and I could not figure out why. Poking around, I realized that $reelasever is supposed to come from examining the version number of a particular RPM package, in my case fedora-release. Well, lo and behold, this package was no longer installed on my box, yum must have uninstalled it, but crashed before installing the new update (or something...). I mounted the Fedora Core DVD, and simple reinstalled the missing package, and things are happy joy joy again. Here's the command:

$ sudo rpm -i ./Packages/fedora-release-13-1.noarch.rpm

 

Hacking: 

Pages

Subscribe to RSS - Fedora