Set External IP Address

Making the Leap from Fedora Core 6 to CentOS 6 - Personal Experience

This article documents my journey upgrading my Fedora Core 6 machine to CentOS 6 and trying to recreate the functionality I used with my old system.

This is a first draft. I am just writing down "stuff".

Background

My main machine was a 1.1GHz Fedora Core 6 machine I had been using since FC 6 first came out. I use it for email, web, and interfacing with work. As Firefox and Thunderbird progressed, I would download the installs and manually install the new versions. Lately, this started getting harder as they required things I did not have. I was considering downloading source for these and building them.

A while ago, I walked into the computer room and the FC6 machine was off. I also smelled burnt electronics. The power supply had smoked....literally. I've lost power supplies before, but usually without the smell. Put in a new power supply and things came back. After another day, Thunderbird crashed and would not restart. I tried a reboot and the machine could no longer see the hard drive with the root file system. I have a copy of the partition (gpartd) so no problem. I put in a new drive and booted System Rescue CD. I could not see the drive I put in. Checked the connections, try again, no luck. Tried a few more drives, still not luck. All the spare drives cannot be bad. Tested them using SpinRite and the EZ-Connect (USB to IDE/SATA converter), and they were in fact good.

Maybe it's time to upgrade the machine. Fortunately, with the help of rsync, I have current backups of my stuff.


Initial Migration

Choose the Distribution

I had a nice machine that I had acquired some time ago that I chose to use for the new main machine. Dual Core 3.4 GHz Intel Processor, 4GB Main, SATA Raid on the Motherboard. Should do nicely. I chose CentOS 6 because I use RHEL and CentOS at work. Fedora has changed over the years to have really short life cycles. Maybe if they had an automated method of going to the next major release like Ubuntu, it would be workable. Loading and testing new releases of an OS is not my hobby. It may be in a few years after I retire. Ubuntu is looking more and more appealing, but I am not ready to move from a Red Hat based system to Debian based system. Too used to yum, to lazy to learn "apt" and the new locations of the /etc files. There are a bunch of interesting other distributions which come and go, but the go part is the problem. CentOS says 6 will be around till 2020 at least and I am willing to believe this.

CentOS 6 loaded like a champ, just like at work. Give it the name and IP of it's predecessor and verify the basic network connections. Apply maintenance. Update /etc files from the backups of the predecessor machine's files. Update the rsync commands to cover the files I wish I had backed up but missed.


First Things First, Restore Home Directories and Connect to Work

Copy the home directories back from the rsync backups and do a bit of cleanup. Set the accounts up to look the same.


Xorg, KVM, and the Display

Now the first part I dreaded. The newer versions of Xorg automatically detect your video card and monitor. If you are connected through a KVM, it may not detect the monitor. It does not for my 8 port KVM. It says the monitor is "unknown" and gives you a max resolution of 1024x768. It used to be worse with a max of 800x600. The Xorg documentation says you can go to run level 3 and run "Xorg :0 -configure" and it will create /root/xorg.conf.new. Sounds good, connect the monitor directly to the box, let it detect everything and run the command.

Not so fast:
What is generated is a generic xorg.conf file. If you copy it to /etc/X11/xorg.conf, it is indeed read, but does you no good.

After much searching and pain, I discovered an article on the "gtf" command which generates the "Modeline" commands that go in the monitor section of the Xorg.conf. Look at the samples below and you will see why you might not want to generate these by hand. The article was about doing something else, but it gave me the information I needed. The man page has no examples and is thus pretty useless. Connect the monitor directly and reboot. Xorg correctly works out the monitor information. Look under "System->Preferences->Display" and write down all the display settings you might want to use. I also went on line and looked up the specs on my monitor to get the horizontal sync frequency range. You want to keep the third parameter to gtf within this range. I believe you have to lower the frequency as the size goes up, but I do not have a good understanding of this. My monitor goes to 80Hz on the vertical, so I chose reasonably conservative values and they seem to work. Since the "gtf" command generates a horizontal rate, you probably want to make sure it is in the range allowed for your monitor. Wish I knew more about this, just a lot of guessing and luck.

Now I ran the "gtf" command with each of these values to generate the Modeline data. I pasted this into the monitor section of the /etc/X11/xorg.conf file. It will look something like what you see below. Restart X or reboot and you should see the new resolutions under "System->Preferences->Display".



Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "ViewSonic"
	ModelName    "VA2448m-LED"
	Option         "DPMS"

	# Generated with gtf 1920 1080 60
	# 1920x1080 @ 60.00 Hz (GTF) hsync: 67.08 kHz; pclk: 172.80 MHz
	Modeline "1920x1080_60.00"  172.80  1920 2040 2248 2576  1080 1081 1084 1118  -HSync +Vsync

	# Generated with gtf 1600 1200 65
	# 1600x1200 @ 65.00 Hz (GTF) hsync: 80.99 kHz; pclk: 176.23 MHz
	Modeline "1600x1200_65.00"  176.23  1600 1712 1888 2176  1200 1201 1204 1246  -HSync +Vsync

	# Generated with gtf 1680 1050 60
	# 1680x1050 @ 60.00 Hz (GTF) hsync: 65.22 kHz; pclk: 147.14 MHz
	Modeline "1680x1050_60.00"  147.14  1680 1784 1968 2256  1050 1051 1054 1087  -HSync +Vsync

	# Generated with gtf 1920 1080 60
	# 1920x1080 @ 60.00 Hz (GTF) hsync: 67.08 kHz; pclk: 172.80 MHz
	Modeline "1920x1080_60.00"  172.80  1920 2040 2248 2576  1080 1081 1084 1118  -HSync +Vsync

	# Generated with gtf 1440 900 60
	# 1440x900 @ 60.00 Hz (GTF) hsync: 55.92 kHz; pclk: 106.47 MHz
	Modeline "1440x900_60.00"  106.47  1440 1520 1672 1904  900 901 904 932  -HSync +Vsync

	# Generated with gtf 1280 1024 60
	# 1280x1024 @ 60.00 Hz (GTF) hsync: 63.60 kHz; pclk: 108.88 MHz
	Modeline "1280x1024_60.00"  108.88  1280 1360 1496 1712  1024 1025 1028 1060  -HSync +Vsync

	# Generated with gtf 1280 800 66
	# Generated with# 1280x800 @ 66.00 Hz (GTF) hsync: 54.85 kHz; pclk: 93.02 MHz
	Modeline "1280x800_66.00"  93.02  1280 1352 1488 1696  800 801 804 831  -HSync +Vsync

	# Generated with gtf 1024 768 66
	# Generated with# 1024x768 @ 66.00 Hz (GTF) hsync: 52.67 kHz; pclk: 71.63 MHz
	Modeline "1024x768_66.00"  71.63  1024 1080 1192 1360  768 769 772 798  -HSync +Vsync

	# Generated with gtf 800 600 66
	# 800x600 @ 66.00 Hz (GTF) hsync: 41.18 kHz; pclk: 42.83 MHz
	Modeline "800x600_66.00"  42.83  800 840 920 1040  600 601 604 624  -HSync +Vsync

	# Generated with gtf 640 480 66
	# 640x480 @ 66.00 Hz (GTF) hsync: 32.93 kHz; pclk: 26.87 MHz
	Modeline "640x480_66.00"  26.87  640 664 728 816  480 481 484 499  -HSync +Vsync

EndSection

-nolisten

By default, the X server loads with the -nolisten option on the Xorg command line. This ia a security feature. If you are exposed to the Internet or only access other machines via ssh and tunnel X traffic back through the ssh session, this is a very good thing. If you are in a firewalled environment and access some machines via telnet and then display back to your machine, you need to turn this off.

On older version of Linux gdmsetup program allows the setting of Xserver setting -nolisten to allow remote logins. It is under the security tab. In newer Linux there is no gdmsetup, use /etc/gdm/custom.conf instead. The correct parameter is DisallowTCP. Add DisallowTCP=false in the security section of /etc/gdm/custom.conf to make Xorg listen on port 6000 by not running -nolisten.
It should look like this (assuming no other special parameters):


# GDM configuration storage

[daemon]

[security]
DisallowTCP=False

[xdmcp]

[greeter]

[chooser]

[debug]


Music

For a long time I've listened to music with xmms which is a winamp look alike. On the old machine I had installed the xmms-mp3 package from some third party repo like rpmforge. On the new machine I was able to load xmms but could not find xmms-mp3. I kept adding repositories trying things and searching the web for clues. It does appear that xmms has been abandoned. This is sad. But this is important so I kept trying. I finally tried drastic things like using the CentOS 5 rpm for xmms-mp3 and hammering it in place with --nodeps. That made xmms go berserk and made the play list just keep jumping around. I then went and got the source rpm and tried to compile that. There were a series of errors trying to run the configure script and I kept adding pieces to try and resolve the missing dependencies.

At some point I got tired of this and decided to go looking for a new music player. After a bit of Google'ing and looking at reviews, I settled on "audacious". This was available from the atrpm's repo. The install page shows how to load the GPG key.


Digging Myself Into a Hole

In the process of trying to get the old xmms-mp3 kicked into life, I installed repos from adobe-linux-i386, epel, livna, remi, rpmforge, rpmfusion-free-updates, and rpmfusion-nonfree-updates. I had a handful of packages from some these different 3rd party repos. A knowledgeable person would say, "Yep, you dug yourself into a hole." When I tried a "yum update", I got a bunch of conflicts which messed with the upgrade process. I could still the --skip-broken option to get some stuff updated, but this is not good. If I disabled all the repo's except the CentOS base, I still had a bunch of conflicts. Starting over from scratch and reloading the machine, was way way down on my list of things I wanted to do.


Digging Out of the Hole

I posted to the CentOS users mailing list and got a nice response from a gentleman who had an overall low option of third party repo's. Much of his sentiments are a reflection of the CentOS Wiki. He had a really good suggestion to straighten things out. To resync back to a distro getting rid of 3rd party packages set the enable= values as desired in the .repo files in /etc/yum.repos.d. This means setting "enable=0" on the third party repositories.

Then run as root:
yum distro-sync

I had to "yum erase" a couple of pieces manually, but finally got to a state I was comfortable with.


Covering up the hole (so I don't fall back in)

"Doctor, it hurts when I do that."... you know the rest
Yum has a neat plugin called priorities which allows you to assign priorities to the different .repo files. An rpm from a repo with a larger numeric priority can not replace an rpm from a repo with a lower numeric priority. To load the priorities rpm, use yum install yum-plugin-priorities and make sure "plugins=1" is set in /etc/yum.conf which is the default. This plugin also works with CentOS 5, but is loaded with "yum install yum-priorities".

The wiki notes that a check should be made in /etc/yum/pluginconf.d/priorities.conf

Make sure the following is present:


[main]
enabled=1

The wiki also kind of recommends adding the line:

check_obsoletes=1

Then I edited each of the .repo files in /etc/yum.repos.d. In CentOS-Base.repo, I added the line priority=1 after each "gpgkey" line. For the 3rd party .repo files, I inserted "priority=10". The documentation says the default is 99 for unprioritized repositories. It appears that if priorities are equal, update is allowed.


Video

On the old Fedora 6 system, I used mplayer and gmplayer. Over time I had accumulated enough codecs to run most video files. On the new CentOS 6 system, this was the plan. The mplayer rpm can be retrieved from a number of repositories. Since I am using the audio player from ATRPMS, this seemed the way to go for mplayer. So that is the starting point.

mplayer

The mplayer program comes with quite a few codecs built in. The following two articles show how to get codecs to play most formats in mplayer:
http://wiki.centos.org/TipsAndTricks/MultimediaOnCentOS --- (local excerpt)
Using the above instructions, mplayer was running pretty good. gmplayer is another matter.

gmplayer

The atrpms gmplayer did not work. It would flag an error about some missing .so file which deals with Nvidia. I do not have Nvidia graphics. No picture, just sound and a repeating error in the terminal transcript pad. Not much good. At least for the version in early February 2014. The gnome-player worked if you ignored the error pop up about that missing "so" file. So I downloaded source. The source from "rpmfind.net" has a configure file that requires the older gcc3 compiler. The gcc4 compiler is delivered with CentOS 6 is rejected. You can turn off the check, but then the configure script bails out saying you don't have an X server. I downloaded current bleeding edge source from http://www.mplayerhq.hu and it compiled. I configured using "./configure --disable-vidix --enable-gui". The documentation says gmplayer is a soft link to mplayer.

I eventually gave up on gmplayer. However CentOS 6 has smplayer which does the same job and works and is in package smplayer.

You-Tube

The new hardware was fast enough to run You-Tube. However you need the flash-player plugin installed. I downloaded install_flash_player_11_linux.i386.tar.gz and ran "tar tzf install...gz" to see what it looked like. I unpacked it, and using the instructions on the web site, copied libflashplayer.so to /usr/lib/mozilla/plugins/libflashplayer.so

To get automatic updates to the adobe software, run the following commands:

## Adobe Repository 32-bit x86 ##
rpm -ivh http://linuxdownload.adobe.com/adobe-release/adobe-release-i386-1.0-1.noarch.rpm
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
 
## Adobe Repository 64-bit x86_64 ##
rpm -ivh http://linuxdownload.adobe.com/adobe-release/adobe-release-x86_64-1.0-1.noarch.rpm
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux


Games

I am not a gamer. I play a few quiet games to relax now and then. SOL.EXE (solitaire) run under wine from a W2K system. The game "Thirteen" from AisleRiot, Gweled, and Mahjongg. That's about it. The only copy of Gweled I could find was for CentOS 5 and it did not work. It took me a while to find gnome-games-extra which got the version of mahjongg I was used to running. The kde-games rpm has a different set of tile images. The Thirteen game works a bit differently than I was used to. I was able to copy the file from the old image and call it ThirteenA and then it worked the way I was used to.

I was able to get source for Gweled. I compiled and cleaned up the warnings. I discovered the the command:

yum search --noplugins --enablerepo='[aer]*' ddd
allows me to search all the repositories, enabled or not. This found ddd in the "epel' repository. I tried --enablerepo='*' but that enabled the CentOS-Media.repo which is used when you have an installation DVD/CD in the drive. I could have temporarily renamed CentOS-Media.repo to CentOS-Media.repo.no.

Update: Sept, 2014. Downloaded the source RPM gweled-0.9.1-2.fc15.src.rpm and installed locally. Use rpm -vv -Uvh gweled-0.9.1-2.fc15.src.rpm for sourced rpms. It configured and compiled clean on CentOS 6.5 and installed. I was able to build the binary RPM using rpmbuild. Retried this on a test CentOS 6 machine.
Had to install extra packages with: yum install libmikmod-devel librsvg2-devel gtk2-devel gcc and was then able to compile. There may be other packages needed that were on that were already on that machine that are not found on a vanilla machine. Look at the atrpms repository for some of this stuff.

To install the binary rpm on a vanilla machine, I had to enable to atrpms repo with and get the libmikmod-devel:
cd /root
wget http://dl.atrpms.net/all/atrpms-repo-6-7.el6.i686.rpm
rpm -i atrpms-repo-6-7.el6.i686.rpm
yum install libmikmod-devel
yum localinstall gweled-0.9.1-2.el6.i686.rpm

The yum localinstall could probably have been used to get the libmikmod-devel.
Afterwords, I disabled the atrpms repos on the vanilla machine.

Starting the gweled program after installing the binary rpm failed with the messages:
Audio driver choosen: ALSA
Write error: File descriptor in bad state

A bit of researsh turned up a Bugzilla report which showed a work around. After trying the program, edit ~/.config/gweled.conf and set the two lines:
music_on=false
sounds_on=false

so the values are "false" instead of "true". This turns off the music and the game comes up. I listen with to my own music anyway and don't want it running in the game.


My Personal RPM Cheat Sheet

You can do a lot with RPM if you can get the options right. This is my personal cheat sheet. I am not saying this is in any way complete or even the best way to do things (I do accept suggestions), but these are the commands I keep going back to after I forget how to do them.

# Query All Packages on System (pipe into grep)
rpm -qa 

# Find out what files an rpm file installs:
rpm -qlp xyz.rpm

# Find out what package owns a file
# Name has to be the real path - no soft links!
# cd to the directory first and use the relate path.
rpm -qf /bin/ls

# Find out the name of the package in an RPM file
rpm -qp xyz.rpm

# Find out the package details of a package (by name)
rpm -qi rpm

# Find out what files are installed by a given package
rpm -ql adduser
rpm -qdcfv rpm

#rebuild the RPM database
rpm -rebuilddb

# Show what gpg keys are loaded
rpm -qa gpg-pubkey* | xargs -i rpm -qi {} | grep Summary


Email

CentOS 6 came with postfix instead of sendmail. There is sufficient protection against spammers applied by my ISP to make hooking my mail to machine to their SMTP server a bother. The site http://blog.earth-works.com/2013/05/14/postfix-relay-using-gmail-on-centos/ (lc) has a nice article on forwarding email from CentOS through your Gmail account. This worked out real well. I as able to map local email addresses to my normal email accounts via /etc/aliases and the newaliases command.


FAX Send and Receive on CentOS 6

The HP Network All in One Printer's FAX function stopped working. It would go off hook all the time which of course causes your line to shut down till you hang up. I have a second phone number with distinctive ring for fax which was now useless. Since 90% of inbound faxes are advertisements, it would be nice not to waste paper and ink.

After a bit of poking around the Internet and the various RPM repositories, I settled on hylafax as the software which downloaded from rpmforge. I had an old US Robotics external fax modem and connected it to the serial port. The motherboard actually only had a serial header block and I had to get a cable that went from the header block to a DB9M that would fit in the expansion slots for the case. Fortunately the header block pins and the connector on the cable mapped pins 1-9 matching the DB9M serial connector. Even a blind squirrel finds and acorn once in a while.

Hylafax loaded just fine and has a setup tool which does a real nice job of detecting the modem and setting things up. It lets you send the faxes as email. The defaults worked fine, especially those I knew nothing about.

I eventually updated Hylafax from the RPM on the Hylafax web site. This was a significantly newer release than through RPMForge. The Hylafax web site also had a neat Windows installed called Winprint HylaFAX Reloaded. It creates a pseudo printer on the Windows box which sends the print output to the Hylafax server. Sending faxes worked great.

Receiving faxes did not prove to be so easy because of one little mistake. When the setup for Hylafax runs faxaddmodem there is a little note just before it is done telling you to make sure faxgetty is set up in /etc/inittab. Did not know what they meant, so I did nothing. The modem would answer, but not sync up to receive a fax.

After much frustration, I joined the Hylafax mailing list and asked the community. One responder asked if I was running faxgetty. I ran faxgetty from a command line and the fax connection got a lot farther. It had trouble setting up the modem because of the butchering I had done to /var/spool/hylafax/etc/config.modem. Note that I had created a soft link from /dev/modem to /dev/ttyS0 to make my system match some of the examples I found on the Internet. I renamed the /var/spool/hylafax/etc/config.modem file and reran faxaddmodem to rebuild a new config.modem file.

On CentOS 6, create /etc/init/faxgetty.conf with the following contents:

# This function supports answering the fax modem for hylafax
#
start on runlevel [2345]
stop on runlevel [S016]
respawn
exec /usr/sbin/faxgetty modem

Then run: initctl start faxgetty.
If I had not created the soft link the word "modem" on the "exec" line would have been ttyS0.

I was then able to send and receive faxes.

The next time I rebooted, the faxes stopped working. The /dev directory is rebuilt, and /dev/modem was gone. I had to change /etc/init/faxgetty.conf to:

# This function supports answering the fax modem for hylafax
#
start on runlevel [2345]
stop on runlevel [S016]
respawn
exec /usr/sbin/faxgetty ttyS0

Then run:
initctl stop faxgetty.
initctl start faxgetty.


Questions and comments are welcome.



Last Maintained: Thursday, 07-May-2020 09:47:18 CDT by R. E. Styma