RHEL 6 for the Clueless: Sun Java

The bundled Open Java on RHEL is okay. It’s also painfully slow, particularly compared to the competition. Most people still call it Sun Java, though it’s now owned by Oracle. Because we have installed the development packages, we have the Open JDK (Java Development Kit) so we’ll have to replace it with Oracle’s JDK for Linux. This is so much faster, there simply is no comparison, at least on desktop applications. That would be things like Jedit (a java-based text editor), the Bible Desktop or “JSword” (java version of Crosswire’s Sword Project) and any number of java games.

Get the RPM for the Java Development Kit (JDK) from Oracle. On that page, scan downward from the big fancy icons and in the first box, you’ll see a button for “Download JDK” — click that. Use the drop-down list button to select “Linux.” Checkmark the box agreeing to the license, accept their cookies and click the red “Continue” button. From there is should be another page with two options. We are going to use the first one, which ends in “rpm.bin.” It’s a rather large package, so it may take awhile. Don’t try to install from your browser; it won’t work.

(Update: Please note there are significant problems with the latest version 1.7 from Oracle. It creates conflicts with almost every Java application currently in use, breaking Libre Office, for example. Stick with the latest update for 1.6 until the conflicts are fixed.)

Here we go with the commandline again — open Terminal and login as root. This is not a typical situation with RPM files. Once you are logged in as root, you’ll probably be in your user account Home, and the file is in Downloads, so go there:

cd Downloads

There is no reason you can’t install it from here, but you may eventually want to start moving stuff out of Downloads to reduce the clutter. You can create another folder inside your Home directory and name it whatever you like.

We’ll probably need to change the permissions on this file, but it almost never downloads as an executable binary, which it is. If you run ls -l and don’t see X’s in the file permissions, you’ll need to change them:

chmod u+x jdk-6u23-linux-i586-rpm.bin

Next, we install it:

sh jdk-6u23-linux-i586-rpm.bin

That sh command is simply an older and very standard terminal shell (environment), and the bin file has a wrapper around it written in a script which expects you to use that shell. You may or may not see a bunch of text about licensing, but if it comes up, simply hit the SPACE bar a few times until it runs out and type “yes” at the question prompt. It should install automatically from there. It will create a bunch of RPMs and other files, but the wrapper is supposed to run RPM for you.

Now let’s tell RHEL to start using this faster java. The command is rather obscure, and you’ll probably never see it again after we take care of this and the next item. It tells RHEL you want to switch among the alternative java environments on the system.

/usr/sbin/alternatives --install /usr/bin/java java /usr/java/default/bin/java 20000

Finally, we want Mozilla and any other browser in the system to use this new java. We use that “alternative” command one more time:

/usr/sbin/alternatives --install /usr/lib/mozilla/plugins/libjavaplugin.so libjavaplugin.so /usr/java/default/jre/lib/i386/libnpjp2.so 20000

That’s all one line. Restart Mozilla and it should now be using your new java. Maybe someday the Open Java project will catch up and provide something closer to Oracle’s product. This particular process continues to be overly complicated to make it work right, and it shouldn’t be necessary.

As a final item before we close out the desktop portion of this series, I need to mention I found one critical package missing which did not get installed by default. Chances are you haven’t missed it yet, but you will later. The default system spelling checker is something called “hunspell” and the default dictionary for English didn’t get installed on my system. So while your Terminal window is still open, you need to do this:

yum install hunspell-en

If English is not your preferred language, you can always ask Yum what else is available:

yum search hunspell

Among the items listed should be something there you can recognize and use.

Posted in Uncategorized | Tagged , , | 6 Comments

RHEL 6 for the Clueless: Generic Software Build

For our last desktop oriented article, I promised we would build one item using the generic Open Source scripted building process. For this project, I chose something only slightly complicated, and likely to be favored by most users: PySolFC, the Python Solitaire Fan Club Edition. It’s not just a collection of card games, but more card games than you’ve ever seen, along with a wide array of Mahjongg based games. It also comes with background music. (It also comes in a Windows package.)

Written in the Python scripting language, PySol has been around for a long time, then almost died. It was revived by a few fans, but they haven’t gotten around to putting the background music into the Linux/Unix version by default. The Windows and Mac versions do have the music, but for Linux you’ll have to work a bit.

On RHEL 6 (and clones) you’ll need to add a few packages, so open your Terminal and login as root, then:

yum install tkinter pysol-devel SDL

First, we need to build the sound player. The package is called smpeg, and it’s an SRPM from Fedora 11. Realize this part is still messing with RPM and we’ve covered that in previous lessons. You’ll need to install it manually and build it with RPMbuild. Once you’ve done that, install everything except the debug package.

Now we get PySolFC. Click on the link for PySolFC on that page. On the next page select the latest version 2.0; on the page after that, click PySolFC-2.0.tar.bz2. I’ve just shown you the basic layout of most Sourceforge projects, where a lot of generic build source packages are found. That next link will open a page with some advertising, then an auto-download process.This time root will build the package in another location. First, let’s navigate in the file system to the generic source building place:

cd /usr/local/src

Then move the package there:

mv /home/username/Downloads/PySolFC-2.0.tar.bz2 ./

That’s the move command (mv) pulling the package from where it downloaded to the current working directory (./). Now let’s open it:

tar -xvfj PySol [hit TAB]

This is a one step process for handling the standard Unix tar bundles, with switches to make it exract (x) with some visual feedback (v) on the file we name (f) and using the bzip2 compression (j) because that’s the package format (ending in bz2). You should now have in front of you a folder labeled PySolFC-2.0. Move inside that:

cd PysolFC-2.0

Go ahead and run ls to see what’s there. One of the first things you want to look for in building from source is README and INSTALL. In this case, we have at least the README, which is simply plain text. We use less to read that, and the SPACE bar to scroll down, along with the arrow keys, PGUP, PGDN all working as you might expect. The instructions are pretty sparse, and assume a level of experience our series assumes you don’t have.

Aside from the PySol-Sound-Server, which we get later, you already have all the basic requirements for this, so skip down to the installation section. This one is really quite simple, since it’s Python. I want you to notice farther down, where the last section lists places where you can get extra features. It includes the location for default music files. We’ll be getting those before we are finished.

Close the reader using the “q” command. Now, let’s build it:

python pysol.py

This is very well done, because it installs everything where it should be, and even creates a link in your GNOME menu system. That was the easy part. Let’s back out of this folder:

cd ../

We still need the sound server, which is still kept at the old PySol website. It’s another bz2 file, and you’ll need to move it and open it the same way as we did above. Now move down into the folder created. This time I will warn you the README is out of date. That is, it’s still valid for building, but the links are likely to have changed since it was written in 2004. Open Source projects come and go, and their websites, too. This is why I took the time to chase down the smpeg file above.

Let’s build this. Below are a stack of commands you need to execute one at a time, and wait for the prompt to return before you execute the next. It’s a common notation in Open Source instructions. If you read the README, you’ll notice I’ve trimmed off the standard prompt symbol ($) for the standard user account, or (#) for the root prompt. By the way, at the point of “make test” you can stop the music test by hitting CTRL-c. This kills most running processes which grab the commandline prompt.

cd src
./configure
make
make strip [optional]
make test
make install

We are almost done. Let’s get the music files. We don’t need root to do this, since the music goes in your user account files. Log out the root account (exit) and you’ll find yourself as the user in your Home directory. Move down into the Downloads folder — cd Downloads — and let’s open that package. Since it’s in the gzip format, we change the tar command just a bit:

tar -xvfz pysol-music-4.40.tar.gz

You’ll need to create your own user account music cache. PySol will be looking in your Home directory for a hidden folder — .PySolFC — and a music folder inside that. We get both with this single command:

mkdir ~/.PySolFC/music

Now we move the music files where they belong. These files are several layers deep in the subdirectory you just created from the gzip package.

cd pysol-music-4.40/data/music

Run the ls command and you’ll see a license file with each music file, and, while they are all various types of “mod” files, they have different format tags, either .mod or .it. Don’t get too confused about that; if you want to know about this offbeat music format, you can find thousands of of them all over the web, an art form in itself. Just search for “mod music.” We will move them one at a time so you get used to how it works:

mv Astral_Dreams.it ~/PySolFC/music/
mv Past_and_Future.it ~/PySolFC/music/
mv Subsequential.mod ~/PySolFC/music/

You can close your Terminal window. Check the Applications menu, and under Games you should now find PySol Fan Club Edition. If we got everything right, you should hear background music every time you play the games. The fellow who wrote this music, Carl Larsson (aka Nightbeat), is regarded among mod music fans as a master of the ambiance style. While you can chase down his work and others, you’ll find not all of them will play properly using the PySol music server. You’ll have to experiment and see what works and what you like.

Posted in Uncategorized | Tagged , , | 2 Comments

RHEL 6 and Trial Subscription: Keeping It Alive

This is just a side note on my series RHEL 6 for the Clueless.

I obtained my copy of RHEL 6 using the free trial offer from Red Hat. For a month, you could continue getting Yum updates for free. At the end of that period, Yum complains you have no access to the Red Hat Network (RHN) repository. I know, because mine ran out before I could allocate the money for the fee. I live on a tight budget and I hope to afford it soon.

It is possible to keep it alive without support. As part of Red Hat’s commitment to the Open Source principle, they continue to allow open access to their SRPMs. That’s the easiest way for them to fulfill their obligations to the GPL copyright system. Thus, I can download and build updates using the RPMbuild dependency chase outlined in my previous post. The only thing left is keeping track of the relevant update notices. You can subscribe for email notices, but I simply check the archives daily by clicking on the thread link for the latest month and year.

For example, a few days ago there was a notice of a kernel update. I downloaded the SRPM and started to build it. However, I noticed in the SPEC file the build would not create the necessary kernel-firmware package unless you edited the file to turn on that build feature. I’m not an RPM hacker, and I just barely understand the file format for SPEC. But I understand it just enough to make it work for me.

If you open that file in an editor, you can scan down until you see list of features with three columns of code about how the features are handled (the lines are not so tightly wrapped as you see here on my WordPress blog when you view the file itself):

# What parts do we want to build? We must build at least one kernel.
# These are the kernels that are built IF the architecture allows it.
# All should default to 1 (enabled) and be flipped to 0 (disabled)
# by later arch-specific checks.

What I did was change the line about firmware to read like this:

# kernel-firmware
%define with_firmware %{?_with_firmware: 0} %{?!_with_firmware: 1}

Frankly I didn’t really know if that would fix it, but when I ran the rpmbuild command, it did produce the firmware file, which I knew from experience would be missing by default if I didn’t do something. I’m sure I’ll stumble across other surprises as I try to keep up with my home-built updates, and I’ll share them if it seems pertinent. I’d much rather pay for the RHN membership, but I can’t promise it will happen. This does not happen with CentOS or Scientific Linux.

Posted in computers | Tagged , | 2 Comments

RHEL 6 for the Clueless: More RPM

With a little less hand-holding this time, I am going to outline for you building a bigger SRPM project which had lots of dependencies. When you run that rpmbuild command on a spec file, one of the first things to happen is checking to see if all the other stuff it needs is already in place. Quite often, you’ll get a message about unsatisfied dependencies, followed by a nice indented list of what’s missing.

Sometimes you can Yum the missing stuff. Often not. So you chase down the SRPM for that thing, try to build it, and it too spits out its own list of unsatisfied dependencies. It can quickly go four layers deep, and more. It happened when I decided to build Pidgin from the SRPM. That’s an older and still popular instant messaging client for the GNOME desktop. Most of the time, if you have any IM client installed at all, it’s going to be called Empathy. I prefer Pidgin.

Let’s recall some important pointers. You’ll need to check in this order for sources:

  1. yum
  2. RHEL SRPMs
  3. FC13 Update SRPMs
  4. FC13 Everything SRPMs

So you install the Pidgin SRPM and attempt to run rpmbuild on the SPEC file. You see a list something like this:

avahi-glib-devel
farsight2-devel
gtkspell-devel
meanwhile-devel
NetworkManager-glib-devel

Until you know better, you can try to Yum each one and see what happens (yum install package). When I checked, none were available. In some cases I had the base package, but not the development (“-devel”) version. That meant if I built the SRPM, I had to decide whether it was an upgrade and install both the base and devel, or if it was the same and install only the devel, or something else it might produce, such as libs or utils or something with a name which didn’t match the SRPM at all. By trial and error I got it done.

I’m going to outline the order and depth in which I proceeded. The number of asterisks increase as they go deeper. After each item is the repo where I found it. An indentation below something indicates what I found required before I could proceed, until I got the item(s) farthest indented, and worked my way back up. Then I moved to the next item on the same level. Remember, most of the time the SRPM will be named for the base file, but will include any number of libs, devel, and assorted other files.

pidgin (RHEL)

* gtkspell-devel (RHEL)

* NetworkManager-glib-devel (RHEL)
** wireless-tools-devel (RHEL Server)
** libnl-devel (yum)
** ppp-devel (RHEL)
*** libpcap-devel (RHEL)
**** bluez-libs-devel (RHEL)
***** gstreamer-plugins-base-devel (yum)
***** libsndfile-devel (FC13)
****** flac-devel (build broken, pulled from Beta Optional)
****** jack-audio-connection-kit-devel (yum)
***** libudev-devel (yum)
** libuuid-devel (yum)
** libgudev1-devel (yum)
** gnome-bluetooth-libs-devel (RHEL from gnome-bluetooth)
*** unique-devel (yum)

* avahi-glib-devel (RHEL)
** libdaemon-devel (RHEL)
*** libcap-devel (yum)

* meanwhile-devel (RHEL)

* farsight2-devel (with base & python, RHEL)
** gstreamer-python-devel (RHEL)
** libnice-devel (RHEL)
*** gupnp-igd-devel (RHEL)
**** gupnp-devel (RHEL)
***** gssdp-devel (RHEL)

You’ll notice one item in particular — flac-devel — which would not build properly for me. I took a chance and checked the RHEL 6 Beta repository and found the package was the right version and didn’t have to build from source. I simply installed that one as is. It may be the one and only time I can pull that stunt. You can find that repository here. Notice it is for the 32-bit version, so if you are running the 64-bit, you’ll need to work your way back up the URL a few levels until you find the x86_64 stuff.

The sources I used will probably look different if you are working from CentOS or Scientific Linux. The obvious would be to replace RHEL with the source for your distro.

I once did something similar on the RHEL 6-Beta in order to gather all the stuff needed for full multimedia players and such. On the Beta-2 it didn’t work so well. On the full release, it didn’t work at all. The issue is all the exotic codecs I could only find at RPMFusion, and some of their SRPMs didn’t match versions for dependencies. I’m not sure how they got out of sync, but it makes me uncomfortable using their repository any more.

For those of you running nVidia or Radeon video chipsets new enough that you don’t have built-in full 3D acceleration on the display, you can use the above method for building something available, but not provided, in the RHEL RPM system. It’s not necessary to go through the detailed and risky procedure for installing the special drivers provided by the chip manufacturers for Linux. When you use those drivers, some things don’t quite work right because those drivers aren’t properly integrated into the display server. Instead, you can install a package which is derived from the “mesa” SRPM.

Obtain the SRPM from the RHEL repositories, and go through the chase for dependencies for RPMbuild. One of the packages produced will be “mesa-dri-drivers-experimental,” which will boost the acceleration for most Radeon and nVidia displays without nearly as much hassle. Just install that one package from the build. You don’t have to kill Kernel Mode Setting (KMS) nor worry about minor display glitches showing up in some software. In the two beta releases for RHEL 6, this package was rickety and offered only a slight acceleration. In the full release, I got my Radeon HD 4350 to run plenty fast for everything I do on my system.

Posted in Uncategorized | Tagged , , , , , | 1 Comment

RHEL for the Clueless: RPM

You probably know everything on your computer is just zeroes and ones, grouped together in eights and sixteens, and so forth. You might know a bunch of folks type out lines of instructions (“code”) for computers which have to be converted into those ones and zeroes, in a process called compiling. You may have heard compiling stuff on Windows requires you to buy expensive software suites to do that sort of stuff. Maybe you know Open Source means the entire process from start to finish is wide open and free, and if you take a notion, you can compile your own software because it’s all part of the package. This is why I recommended you install the Developer Workstation package profile. You can take all those instructions people write and make it into zeroes and ones yourself.

On RHEL, you have the option of going out and finding that code from the sources and learning how to use the common build scripts. I do it all the time. But it’s a whole lot simpler chasing down all the extra piles of code you need if it comes pre-packaged. For RHEL, that means the RPM system. It’s not just a way to add packages someone else built for you, but you can build the packages, because the source is also neatly packaged. We call them source RPMs or SRPMs. Whenever you see a package which ends in the combination “.src.rpm” you have an SRPM.

Depending on what we are trying to build, we can get our SRPMs from several different places. For RHEL, the primary source is the official RHEL 6 workstation repository. Occasionally I also have to check the server repository. These two are updated regularly when something is fixed, so check to get the version with the highest number, which may mean the last in a long string of digits, dots, dashes and underscores. A much wider variety of packages come from the Fedora repositories. If you understand Fedora is the playground development system for the serious RHEL working systems, then it’s no surprise Fedora has more different kinds of stuff. You just have to be aware of which of the many versions of Fedora is closest to your version of RHEL. In this case, RHEL 6 is built largely from FC13, but parts of it appear to come from FC12. At any rate, if you don’t find what you need on the RHEL repositories, your second look should be “FC13 Updates” and “FC13 Everything” in that order. You can find a list of mirrors here simply select the one closest to you. For each one, it’s usually a matter of this layout on the servers:

..../fedora/linux/updates/13/SRPMS/
..../fedora/linux/releases/13/Everything/source/SRPMS/

In the case of CentOS and Scientific Linux, they will have their own mirrors and structure when 6.0 is finally released by each of them. They are built from RHEL 6 SRPMs, and the same FC13 SRPMs should work for things not included in the primary SRPM sets.

Today we are going to grab the package called “freetype,” which is a standard item from RHEL, so go to the Workstation SRPMs and download that package. We can’t install this from the browser, so prepare to do some commandline work. Just as a reminder, in Linux, all commands are case-sensitive. Most commands are in lower case, but there are switches (usually with a dash in front of them) which are both upper and lower case, so you need to pay attention to them.

Open your Terminal and su to root. Type cd so you are working from root’s Home. You can issue the command to install this SRPM from here, as long as you declare on the commandline the exact location of that RPM file (called the “full path”):

rpm -ivh /home/username/Downloads/freetype- [hit TAB]

In this case, we use the “i” switch for a straight install, and the “vh” allows you to watch it work. You can ignore the warnings about who owns the files. When it’s done, if you type ls you should see a folder named rpmbuild. This is where all SRPMs will be installed so we can work on them. There are several sub-folders underneath. We are primarily interested in the SPEC folder, so type:

cd rpmbuild/SPEC

If you ls here you’ll find a single file, freetype.spec. This is the building configuration file. The Freetype library is the run-time reference for the way fonts are rendered on your screen. We are going to change it by adding two features not enabled by default, called “bytecode hinting” and “subpixel rendering”. If you take a quick look at this SPEC file:

less freetype.spec

you’ll see some interesting instructions at the top. That “less” command is equivalent to the Windows file viewer command “more” — less is more. The second line of the file tells you how to add those features. You see we can add a couple of “switches” on the commandline of the build process to make it happen. But it’s not a simple swipe of the mouse because there is some extra verbiage and punctuation. So you can hit “q” to close this viewer and I’ll give it to you below.

The basic command is rpmbuild, with a switch  (-bb) telling it to build the software and create the RPM packages. We’ll stick in the additional switches from inside the SPEC file and finish with telling RPMbuild what it’s working on:

rpmbuild -bb --with bytecode_interpreter --with subpixel_rendering freetype.spec

Hit enter and it should take off and build it, displaying the details on the screen in your Terminal. When it’s finished, the prompt will come back and we have to go find those packages and install them. If you take a moment to look in your Terminal window, you’ll see up just a few lines where it says “Wrote /root/rpmbuild/RPM/i686/freetype….” Each of those packages comes from the same SRPM. That’s the common pattern, and it also tells you where to find the packages. The source is not just the library, but some other stuff, which includes the development libraries. We need the base package and the “devel” package. Now, let’s go there:

cd ../RPMS/i686

That double dot is simply shorthand for “the directory above this one.” We go up one layer, then down two into the place where RPMbuild drops the finished packages, in this case the i686 folder (x86_64 for 64-bit). We need to install them both at the same time. And because we already have a couple of RPMs by the same names installed right now, but crippled versions we want to replace, we’ll need to tell RPM to ignore that. Keep in mind, as you type this rather long command, you only have to type enough to distinguish between files and hit the TAB key for each file. What you see below were the ones I built for this tutorial:

rpm -Uvh --force freetype-2.3.11-6.el6.2.i686.rpm freetype-devel-2.3.11-6.el6.2.i686.rpm

That’s the “rpm” command, with the “U” upgrade switch, and as before, the “vh” switches so you can see what’s happening. Then we add the “force” switch because it won’t do it otherwise. Don’t abuse that option! You seldom have any need for it, but it’s there and it can really mess things up and make your system quit running if you don’t know what you are doing. The command is completed by listing all the packages, each separated by a space. Hit ENTER.

In order to see the effects of this altered font rendering package, we have to restart the display server. That means log out, then log back in, because logging out typically restarts the display server. It should make at least some noticeable difference in how fonts are rendered, mostly by tightening up and sharpening the characters so they aren’t so fat, fuzzy and dark.

Welcome to RPM Land. More extensive instructions can be found starting here.

Posted in Uncategorized | Tagged , , | 1 Comment

No Longer Recommending SOTT

Change is change; it’s not always good.

Recently the Signs of the Times (SOTT) site shifted the focus of their editorial policy. It’s not as if I suspect they’ve been bought off or something. They have the same original editorial biases as before, but the presentation has changed. Previously you could read most of the current postings and find the important but off-beat and spiked stories not available from the mainstream media and avoid their New Age baloney. Not any more. Now you have to wade through it.

I’m quite used to having no single source which serves my weirdo interests. It’s okay. I’m willing to work for it by having to scan down a longer list for things which interest me. I find it no longer worth the effort at SOTT. The whole point of news aggregation is saving your readers time. Now it takes more time than it saves. This is not a matter of hostility, but noting it offers not enough of what I want, and too much of what I must oppose.

End of the line, SOTT; dropping you from my bookmarks. Go your way without me.

Posted in globalism | Tagged , , | Comments Off on No Longer Recommending SOTT

RHEL for the Clueless: Fonts

Linux is capable of superior font display handling. On my hardware, it’s better than any version of Windows, but it’s not turned on in RHEL by default. There are several issues involved.

First, let’s get some better fonts. If you have access to a Windows machine, copy off the font files for your favorites. I’m going to warn you only the older ones work properly, such as Arial, Courier New, Comic Sans, Palatino, Tahoma, Trubuchet, Verdana, etc. You can try, say Consolas, on your machine when we are through fixing, but you may not like it. At any rate, copy the actual font files to a thumb drive and plug it into your Linux computer.

For the sake of simplicity we will copy them to your user account font storage: ~/.fonts — that’s a folder in your Home directory. If it’s not there already, simply create it using the file manager from your Home icon on the desktop. You can use the menus or try the right-click menu. This folder not normally visible unless you go out of your way to find it. That leading period in the folder name tells Linux “hide” it so it won’t get in your way, and the system expects to find it so. The system knows to look in that particular folder when offering you font choices.

Next, in your System menu, select “Appearance” and click the “Fonts” tab. You’ll see some drop-down list buttons where you can change the default fonts in the GNOME interface. The fonts you just copied should be immediately available. Next, notice the “Rendering” section at the bottom. If you have some sort of LCD screen, select that. Otherwise, experiment until you like what you see. Now hit the button marked “Details…”

Most of the time the resolution is correctly set by the display system. Don’t mess with this until you know a lot more about it. Instead, test the various settings below that. Make it look as good as you can, knowing we are only getting started. I use LCD smoothing, full hinting and RGB color balancing. It should get even better in a bit. You’ll notice changes in the entire interface take effect immediately. So far so good for stuff controlled directly by GNOME. But some applications, like Firefox, are not controlled by GNOME. The fonts will still be ugly. It requires a separate fix.

The same system which knows to look for fonts in your “hidden” fonts folder also knows to check for a certain configuration file named .fonts.conf — there’s that leading dot again. If you told your file browser to show hidden files, then you could see if it was there. You aren’t likely to have one yet. The fix is highly involved, and you are several lessons from understanding that if you’ve never used Linux. This is part of the same fix which works on just about every kind of Linux available, and I’m going to hand it to you on a silver platter. Just click this link (see below) and your browser should offer to save the file. If it simply displays it, that’s okay, just use the browser menu to save it with the name I gave it on that website. If you download it, save it that way.

Now, go to your Home file window and click on the Downloads folder. You should find a “fonts.conf” without the leading dot. Chances are what is in there will work just fine for most computers, and will certainly do no harm. It’s nothing more then encoded instructions telling the system to display Firefox and other non-GNOME stuff pretty much the same as GNOME stuff. Simply move it up one level into your Home folder, then change the name to add the leading dot. It should take effect immediately when you do. In case you don’t know already, look at the window pane on the left for an icon with your username. It’s drag-n-drop; drag the file from the list window and drop it onto the icon on the left side. It should move. Then click the up arrow in the icon bar at the top of the window. Find the file again, and right-click, selecting “Rename.” Type the leading dot in front of the name. Hit ENTER and you’re done with this part.

Now, to really get things looking sharp, we have to actually change something in the system by rebuilding the font rendering library. Once again, it’s that issue of Red Hat protecting themselves via an abundance of caution from vague copyright liabilities never tested in court. The threat recedes to near zero for us mere users, so we are going to fix it. That will be our next lesson, because it will serve as the introduction on using the RPMbuild system, which you will certainly need to know if you intend to use RHEL more than few days, or for anything more than the most basic tasks. So even if you think the fonts look fine as they are, you should follow along and learn how to build your own software packages.

fonts.conf (copy and paste what’s in this box)

<?xml version="1.0"?><!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
 <match target="font" >
  <edit mode="assign" name="antialias" >
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit name="autohint" mode="assign">
   <bool>false</bool>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hinting" >
   <bool>true</bool>
  </edit>
 </match>
 <match target="font" >
  <edit mode="assign" name="hintstyle" >
   <const>hintfull</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="lcdfilter">
   <const>lcdlegacy</const>
  </edit>
 </match>
<match target="font">
  <edit name="rgba" mode="assign">
   <const>rgb</const>
  </edit>
 </match>
</fontconfig>
Posted in Uncategorized | Tagged , , , | 1 Comment

RHEL Series Note: Samba

Once we finish the desktop tutorial series here, we will jump right into the low level server stuff. This evening I got Samba working and my wife’s computer can now browse shared folders and open the files. Also, in order to share my printer with her, it has to go through Samba, and that appears to work, as well. This is the first time I got Samba working on a home network, so we are on our way.

Posted in Uncategorized | Tagged , , , | Comments Off on RHEL Series Note: Samba

RHEL for the Clueless: File Management

There is a world of difference between Windows and Linux in file handling. Your immediate need is to understand the business of permissions. One of the fundamental security advantages in Linux is every file is owned by someone, and the owner gets to decide what happens to those files. Ownership, of course, is limited to those who have an identity on the computer in question.

First, let’s open that Terminal again. When first opened, by default your relative location in the system is your Home directory. So important is this, anytime you issue the command cd without saying specifically where you want to go, you’ll be sent here to the same place, Home. On the Linux commandline, we love our abbreviations. When you are typing things on the commandline, the symbolic reference to your Home is ~/ — that’s a tilde and a forward slash together in that order.

Let’s see what’s there. Type ls (lower-case LS). You get a column list of item names, in different colors. Blue is what marks a directory, which may or may not have anything inside it. You should have at least Desktop and Downloads, and mostly likely some other standard folders such as Documents, Music, Pictures and Videos. Not so different from Windows in that sense. You may not see any files, which show up as black. That is, unless you’ve been playing with the color scheme in the Terminal menu system. But there isn’t much information about the folders and files. Who owns them?

Type “ls” again, but with an added switch, which asks for the full length version of information about each item: ls -l. You should see something like:

drwxr-xr-x. 2 ed ed 4096 Jan 5 08:42 Desktop
drwxr-xr-x. 2 ed ed 4096 Jan 7 14:33 Documents
drwxr-xr-x. 3 ed ed 4096 Jan 9 17:40 Downloads

That first column is all about permissions. I’m not going to duplicate the good work of others who write better than I. Allow me to refer you to this tutorial on Linux Permissions. You’ll need to read it if you don’t understand what we’ve done so far. Go ahead, we’ll be here when you get back. You might want to bookmark the home page of that website if you find yourself lost already in Linux. The author covers a lot of basics in very simple explanations.

For now, I want you to learn how to do this in the GUI. If you click the “Home” icon on your desktop, you get a window reminiscent of the ancient Windows 95 default. If you like that, fine, but it won’t help you learn much about maintaining your own file collection. So in the open window, go to the Edit menu, and select Preferences, the last item. You should see a configuration dialog with many tabs at the top. In the first tab, hit the drop-down box where it says “Icon view” and change it to “List view.” I recommend you checkmark “Show hidden and backup files.” On the Behavior tab, checkmark “Always open in browser windows.” My personal preference is also to select the radio button for single-click, because I like my file browser to act like a web browser; everything is a link which requires only one click. Finally, go to the “List columns” tab and add a checkmark to the box at “Permissions.”

Hit the “Close” button; the choices are automatically saved. Now close the file manager window. Open it again, and the changes should have been applied. Of the far right side of each line you see those permissions again. Right click on any item, folder or file, and click “Properties” at the bottom. Click on the “Permissions” tab and you get a detailed management page for the item in question. You’ll see the labels explaining all that stuff you saw in your Terminal window. Change those permissions and it changes what shows up in the file browser window in that permissions column on the far right. Note: All folders must be marked with the “execute” bit for you, or you can’t see what’s inside.

You’ll discover if you transfer any files from a FAT file system (like thumb drives or memory sticks), NTFS (the current Windows default), or most backup CDs, every file has all the execute bits set. That’s how Linux interprets Windows default file settings. It’s not a big problem in every case, but it does conflict with the Linux defaults. When copying files from those other media into your Home folder or anywhere else on your Linux machine, be aware of this. If the file is not supposed to be an executable script or binary, change those permissions to take away the execute bit (but not on folders). It’s laborious if you have a lot of files, but it’s just one of those things.

Now, about ownership: You’ll notice the files belong to you as your username, listed twice. That’s because there is the user as a person, and you belong to a group by the same name. You may have picked up on that from the tutorial I linked above. The root account can change ownership of any file, but you get to set group membership for any group your user account belongs to.

Linux and Unix folks will gravely warn you about messing around too much while logged in as root. On your system, root owns everything, and can delete the entire system with just a few keystrokes. So we protect our root access with hard passwords and don’t use the root login except when necessary. Never connect to the outside Net as root unless absolutely necessary, as this exposes your machine to someone else using some unknown security hole to masquerade as root on your machine.

In the last lesson, we copied a bunch of codec files into the library file system. Those files are still owned by your user account. It’s a low-level security threat to leave them that way, among other things. You could accidentally delete them from your user account. Suppose you were online and someone managed to use one of those as-yet undiscovered security holes, and grabs control of your system using your user account. They will have only your user account’s permissions to do things. Those files are not protected. As a standard practice, anything which is used by the system should belong to root. Let’s fix that situation.

Open the Terminal and login as root. Then execute this command:

chown -R root:root /usr/lib/codecs/

That’s change ownership, using the -R switch for recursively (diving down into the folder and everything inside it), to make root the owner of all those codec files we moved there.

One final note. We got those files from a standard source in the Linux world. Unless someone packages them for your particular Linux version, that’s the way to get them. Right now, no one makes an RPM for RHEL 6 containing those codecs. If they did, we might be able to download and use that RPM file, and all would be well. But you should avoid adding multiple third-party repositories. ATrpms does things one way, and the others do things differently. If you add other repos which cover the same kind of packages, there will surely be conflicts, and Yum won’t be able to resolve them. Most of those third-party repos don’t work together, at least not very well, because the people who run them won’t, for whatever reason. If you use ATrpms, you might be able to take individual packages from other places, but even that could be dicey. It’s the nature of the beast.

Posted in Uncategorized | Tagged , , | Comments Off on RHEL for the Clueless: File Management

RHEL for the Clueless: Multimedia Capability (Updated)

RHEL (and clones) does not come with very much multimedia capability. It has to do with politics, copyrights, and philosophical debates. Even if we tried to outline all the issues here, chances are quite good you don’t care a whit. You want to play your music and videos, and there is no good reason you shouldn’t. There are plenty of Linux developers willing to join you in seeking to play what Windows can play, and a lot more besides, but Red Hat is being careful and sticking to their commitment to the corporate client base.

About the only thing which already works well is the audio CD player, Rhythmbox. So it’s up to you to connect your RHEL box with all the other Open Source multimedia capability. Some of those Linux developers have made it quite easy. There are several projects to provide all those goodies specifically in a form which hides from you the gory details, and there’s no reason we can’t take advantage of their work.

In the previous lesson we installed a package, software bundled into a format which could be installed as a single item. Specifically, it was an RPM, an abbreviation for “RedHat Package Management.” Other Linux distributions have begun using it over the years since Redhat developers came up with it, so we have to make sure we get the right RPMs. Then we have to make sure they were compiled specifically for the version of Red Hat operating system we are using, because critical parts of the underlying system progress like everything else.

These third party projects do just that, creating their packages to match your specific version of RHEL. Some of them even automate the whole system so you don’t even have to worry about matching the packages with all the various dependency libraries. We call this a “repository” or “repo.” We do have to be careful, though, because the repos vary in quality, and from one release to the next. In my series on RHEL 5, I promoted RPMForge. As long as you are running RHEL (or CentOS or SL) 5.x, it is still one of the best choices. However, for RHEL 6, it seems some of the same old versions of the software from RHEL 5 are being used for 6, and in many cases, that makes a big difference. That is, you may get something stable and reliable, but with reduced functionality. Either way, as of this writing, RPMForge had not quite gotten all their RHEL 6 packages ready.

There are several others. For example, EPEL, which is also not yet up to date on RHEL 6. Honestly, I’ve had some trouble with a few of their packages on RHEL 5. I don’t trust them quite yet. There’s RPMFusion, but they don’t have any RHEL 6 packages yet. And there are more I don’t know about, but the one which seems ready and reliable right now is ATrpms. If you need a full range of media player capability right now, that’s where I would start.

First, you have to learn something about that commandline business. In your Application menu, go down to System Tools and select “Terminal”. It should open a window, probably with a white background and flashing cursor with a commandline prompt. You need to turn this into a root terminal, with administrator credentials. So type in the following command:

su root

and hit ENTER. It should come back waiting for you to enter the root password. Type it blindly, because it won’t show. That’s a standard security measure you should recognize already. You really should learn how to type the root password blindly. Once you have it, hit ENTER and wait for it to change the prompt to something different, indicating you have taken on the identity of root.

Then type this command… wait. It would be a whole lot simpler if you learned to use the Unix mouse paste method (Linux is a type of Unix). Drag your mouse across the text of the following command. You don’t have to do anything else, just drag your mouse across it until the text of the command by itself is highlighted. Don’t worry about the line breaks, your browser will tell the mouse it’s all one line:

rpm --import http://packages.atrpms.net/RPM-GPG-KEY.atrpms

Then move your mouse to the Terminal window where root is logged in. Place the mouse pointer inside the background space of this window, and press the middle mouse button. If you have some ancient two-button mouse, then try to push those two simultaneously (works with trackpads, too). Either way, it should simply paste that text onto the commandline. Hit the enter key and watch it work. Okay, it usually comes back without saying anything. In typical Unix fashion, no news is good news — it executed the command with no errors.

Now, in your browser, I want you go to this page. It’s a list of packages available for RHEL 6, but you need to scan down the alphabetical list for the one labeled “atrpms-repo”. Click the link and download the package. As with BleachBit yesterday, install that package from the download list in Firefox by double-clicking. You’ll need to use your root credentials as always.

Next, go back to your Terminal window and type or copy-n-paste the following command:

yum update

That package installed some instructions for Yum. That’s a cutesy name for yet another part of the package management system. You may recall I mentioned in a previous lesson how, if you didn’t get an update reminder shortly after installing RHEL, we need to wake it up. It’s rare you’ll need to do that, but that command you just entered should do that — scan for updated packages — as well as tell Yum to scan the packages listed at ATrpms, too. If it comes back with a long list of stuff it wants to install, his “y” and wait until it’s finished. If all is working as it should, you’ll see it come back with no error reports, though it may offer a bit of information indicating what it did above that. If you see anything about a warning you need to reboot, do that and come back here to finish this.

Now we need to add that multimedia capability. We need a media player, and some software which allows us to play DVDs and other media formats. We could discuss all day which one is best, but I’m going to tell you, right now the one which works best from ATrpms is called Xine. I tried the famous MPlayer, and it has a bug which won’t let it open properly the GUI controls on some systems. It works, but you can only do it from the commandline. You probably aren’t ready for that yet. (Update: This had been fixed, and Mplayer is probably easier to use, so go with that.) Here is what I want you to run as your next command to get Xine and some other goodies we will learn how to use later, so mouse paste this as one command:

yum install ffmpeg libdvdcss libdvdread libdvdnav libdvdplay lsdvd mplayer xine-ui

Almost certainly Yum will analyze this command and wind up installing a bunch of other stuff, but that’s part of Yum’s job — taking care of dependencies. It will ask you if you are sure, and you’ll need to hit “y” and ENTER. Watch Yum do it’s work, and eventually it should come back without complaint, announcing enthusiastically the job is done. At least, you should try to imagine what you see as enthusiasm, insofar as you can get it on the commandline.

In a few moments, you’ll have some changes in your Applications menu, with Xine showing up under “Sound and Video” (Mplayer shows up as “Movie Player” with the Mplayer icon). I admit it not as slick as Windows Media Player, but it works on more stuff and there is no digital rights management to get in your way. But not yet. We need one more package from yet another source: codecs.

Go here. The good folks at MPlayer HQ in Hungary have developed a collection of codecs designed to handle just about anything Windows can handle, since Xine already handles stuff WMP can’t. On that page, listed near the top, is a selection of links to packages named “all-xxxxxx” with some numbers indicating the date they were bundled together; the format is yyyymmdd. That’s four digits for the year, two for the month, and two for the day of that month. Get the latest date you can find, with the file name ending in “bz2”.

You can’t install this the way you did before, because it’s not an RPM. Rather, when you double-click, you’ll get the Archive Manager, which acts like a lot of zip managers. You’ll see a window open showing the name of what is inside the zipped file, in this case a folder with the name all-xxxxxxx. Click the “Extract” button and it will ask you where you want it, by default right where it is inside another folder. It will show you a view of your “Downloads” directory in your user account Home file system. Just click the “Extract” button on the lower right side. It will work on this for a moment, then give you back the first window. No news is good news. Now you have this big folder of stuff in your Downloads, and only root can put it where it belongs.

This is the toughest part of the whole thing. There are no easy tools for using root credentials with your graphical file manager window. The only way I know to do this in your current situation is using that Terminal window. First, we create the folder for where the codecs go:

mkdir /usr/lib/codecs

(Unix uses forward slashes, the original standard before there was DOS. Microsoft just had to change to backward slashes.)

Then we need to move root down into that collection of codecs you just unzipped. Chances are, root has been working from your user account Home directory. Just to make sure, type the command pwd — an abbreviation for “print working directory.” It should come back with something like: /home/username, though I doubt your use account is named “username”. Just substitute your username. From here on out, just remember to do that. And if you don’t see anything like that, try cd /home/username.

Also, you don’t have to type out every last letter in the name of something in your file system, any more than you would in Windows when using the Command Prompt window. Just type the first few characters, enough to distinguish from everything else there, and hit the TAB key. The system can guess it from there. So type this:

cd Downloads/all-

and hit the TAB key. It should finish it out so you can hit the ENTER key. Now, type the command ls (same as “dir” in DOS) and see a list in several columns, which starts with this:

acelpdec.ax
alf2cd.acm
aslcodec_dshow.dll

You are in the right place. We need to move all these to their proper location, so do this:

mv ./* /usr/lib/codecs/

If you type ls again, you should see nothing listed. If you type ls /usr/lib/codecs you should see that long list of files again. Tada! You now have codecs in the right place. Purists will tell us we left out a few details, but I’m betting for now it will be okay, and Xine will play your stuff. We can fix the nitpicking later. Just open Xine from the menu. If you have a video CD or DVD in the tray, just select what’s appropriate from the control module; you’ll find it in the context menu by right-clicking. If it’s a file on one of your drives you wish to play, it’s in the same context menu. (Mplayer handles all this from the right-click context menu.)

But we aren’t done. You still want Flashplayer? There is an Open Source version and it still stinks. Maybe some day… But right now you will have to get it from the owners, Adobe. Not long ago, Adobe realized how nice it would be if they got competitive before that Open Source flashplayer got useful, so they have created a repo for RHEL. In your browser, go here and select from the drop-down “yum for Linux”. Install this from your download window as before. Then run that “yum update” again and you should see an indicator of adding Adobe. Then run this:

yum search flash

That’s to show you how to ask Yum if it knows about a certain kind of package, either by name or by something in the basic description, such as what the package does or provides. If you had typed the longer “flashplayer” it might not find anything useful. Yum is limited. In this case, you should see a listing which includes this:

flash-plugin.i386 : Adobe Flash Player 10.1

That’s the one you want. But it won’t work to give Yum all that information. Just use this:

yum install flash-plugin

Notice what part of the package title I used. It should install without any hitch. And if you really must have the official Adobe Acrobat Reader, you can get that, too. Ask Yum to search for “pdf” — the file format used by Acrobat — and you’ll get a long list of software names. In fact, you should already have a PDF viewer, called Evince. It’s a lot faster, and doesn’t phone home like Adobe’s Reader. It is also lacking a few fancy features. I don’t like Acrobat, but if you like it and need it, you now have some idea how to get it.

Whatever you choose, you’ll need to restart Firefox for it register the presence of Flashplayer and/or Adobe Reader. Also, remember to log out of your root session in the Terminal, using the simple command exit.

Update: March, 2012 — Recent issue with updating ffmpeg from ATrpms. When you try to update via Yum, or via the Update Manager (that bright orange icon in the notification area), you’ll get an error something like this:

Error: Package: libavcodec53-0.10-54.el6.i686 (atrpms)
Requires: libvpx.so.1()
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

Here is the simplest and quickest solution; just copy and paste as a single line into any terminal window:

yum update libvpx - --enablerepo=atrpms-testing --disableplugin=*

Yes, this will change one of the core libraries from the upstream provider (RHEL). It shouldn’t break anything, but it could. You be the judge; it’s part of the risk of using any external Yum repo.

Posted in Uncategorized | Tagged , , , | Comments Off on RHEL for the Clueless: Multimedia Capability (Updated)