Archive for November, 2013

Updating Legacy Fedora Linux Distributions to Use Archive Repositories

Fedora LinuxI run a VMware ESXi server here that hosts ~500 separate VMs, clones, templates and test builds of operating systems for testing, development, personal playground and other roles.

Some of these VMs are older Fedora, Ubuntu, Debian and various other Linux distributions. Since those distributions are no longer active, maintained by the community, the update URLs to install packages have gone away, or been moved to new locations.

Here’s how to update and fix those older versions of Fedora Linux so you can continue to install packages on them, past their “community expiration” date. I’ll post another entry for the same work for Ubuntu and Debian as well.

In your /etc/yum.repos.d/ directory are a number of configuration files specific to yum and repositories. It’s contents may look something like this:

[root@fedora-fc4 / yum.repos.d]# ls -lart
total 72
drwxr-xr-x  116 root root 12288 Nov 23 22:57 ..
-rw-r--r--    1 root root   344 Nov 24 14:42 fedora-updates-testing.repo
-rw-r--r--    1 root root   336 Nov 24 14:42 fedora-updates.repo
-rw-r--r--    1 root root   305 Nov 24 14:42 fedora-extras.repo
-rw-r--r--    1 root root   319 Nov 24 14:42 fedora-extras-devel.repo
-rw-r--r--    1 root root  1130 Nov 24 14:42 fedora-devel.repo
-rw-r--r--    1 root root   300 Nov 24 14:43 fedora.repo
drwxr-xr-x    2 root root  4096 Nov 24 14:43 .

In the case of Fedora Linux, you’ll want to change each of these so they reflect the new archive site, vs. the original download site, which no longer resolves and does not exist.

The original URL looks like this:


You’ll want to edit that to point to the following new URL (highlighted in red below):


Once you make these edits to all of the repository files, you can run ‘yum update’ again and fetch all of the legacy update packages, install, remove and keep them as current as those distributions were at that time.

$ sudo yum install git-core
Setting up Install Process
Setting up repositories
updates-released          100% |=========================|  951 B    00:00
extras                    100% |=========================| 1.1 kB    00:00
base                      100% |=========================| 1.1 kB    00:00
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Downloading header for git-core to pack into transaction set.
git-core- 100% |=========================|  67 kB    00:00
---> Package git-core.x86_64 0: set to be updated
--> Running transaction check

Dependencies Resolved

 Package                 Arch       Version          Repository        Size
 git-core                x86_64    extras            2.9 M

Transaction Summary
Install      1 Package(s)
Update       0 Package(s)
Remove       0 Package(s)
Total download size: 2.9 M
Is this ok [y/N]: y
Downloading Packages:
(1/1): git-core- 100% |=========================| 2.9 MB    00:05
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 1ac70ce6
public key not available for git-core-
Retrieving GPG key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-extras
Importing GPG key 0x1AC70CE6 "Fedora Pre Extras Release "
Is this ok [y/N]: y
Key imported successfully
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing: git-core                     ######################### [1/1]

Installed: git-core.x86_64 0:

Now it works. Good luck!

SOLVED: Fixing Perl Plug-ins for XChat Azure in OS X Mavericks 10.9

I’m a heavy user of IRC and have been since the late 90’s. I use X-Chat for IRC on almost all machines, including Mac and Windows, not just the Linux environment that it was created upon.

When I recently upgraded my OS X Lion (10.7.5) machine to OS X Mavericks (10.9), I started seeing a significant amount of core OS bugs. One of them affected how I use XChat to get to Freenode and other networks via SASL, SSL and Tor.

If you’re using XChat Azure 1.16.0 or the latest preview of 1.16.1, you’ll see the following errors when trying to load Perl plugins from Window -> Plugins and Scripts inside XChat:

Invalid Mac OS X bundle or required Mac OS X version is not satisfied

You’ll see this when you try to select the version of Perl showing in the Plugins window. The Python plugin works fine, just not Perl.

Here’s the quick-and-dirty fix, until the XChat Azure team can come out with a Mavericks-compatible release that uses the latest Perl:

Change to the XChat Azure PlugIns directory:

cd /Applications/XChat

Duplicate the contents of the perl-lion Perl bundle into one for Mavericks

sudo rsync -avP perl-lion.bundle/. perl-mavericks.bundle

Update the Info.plist file to match the versioning:

sudo defaults write ./perl-mavericks.bundle/Contents/Info XChatAquaMacOSVersionBranch 10.9

There’s one last step I found when I ran that last command to update Info.plist, and that is that you have to hand-modify the version in the .plist file to match OS X Mavericks 10.9 versioning:

sudo vi perl-mavericks.bundle/Contents/Info.plist

Down near the bottom of the file, change the string value of XChatAquaMacOSVersionBranch from 10.6 to 10.9, like this:


Now if you go quit and restart XChat Azure, go to Window -> Plugins and select your Perl interpreter (the one with 10.9), it will work, and you’ll see your plugins loaded as expected:

[16:27]   Python interface loaded
[16:27]   Perl interface loaded
[16:27]   SASL: auth loaded from /Users/$USER/Library/Containers/org.3rddev.xchatazure/Data/Library/Application Support/XChat Azure/sasl.auth

I wrote some HOWTO documents describing how to configure Tor + SASL + SSL to connect to IRC, you can find them here:

That’s it! Good luck and happy IRC’ing!

Bad Behavior has blocked 102 access attempts in the last 7 days.