On CentOS 6, the GNOME Dictionary is broken.
Apparently, I’m not the only one who has noticed this. Unfortunately, I’ve not seen where anyone posted a proper fix. It worked fine in both RHEL 6 and SL 6 on this same machine.
On the other hand, I never did like it that well. The good news is the best fix is to ignore GNOME Dictionary and replace it. That replacement would be Artha. You can get the SRPM here. Just scan down for it in alphabetical order, or use the “Find” function in your browser.
When building the RPM, you’ll need to add a couple of tools not likely already installed on your system, but they are all available from the standard Yum repositories for CentOS.
Once built, on the initial start, you’ll be informed of the default keyboard shortcut. Then it will simply load and run in your notification area. Double-click any word in any application, hit the shortcut (defaults to CTRL-ALT-W) and the dictionary window opens with the appropriate information. It takes very little of your computer resources, so I recommend leaving it running.
This is a great tool, and is what GNOME Dictionary should have been.
We all know Red Hat Enterprise Linux (RHEL) is the basis for both CentOS and Scientific Linux (SL). The differences are largely cosmetic from the user’s point of view, in which the clones are legally required to change only the artwork and remove the Red Hat logos. There are differences in how each clone project goes about building the product from common sources, but I doubt you’ll find any difference in how they behave. Everything I’ve written about RHEL and SL applies to CentOS. All I’m doing here is summing up the combined notes of how we get from putting in that install DVD to a usable system.
This is what I did installing CentOS 6.2 on a Dell Inspiron 1525.
1. Install options: I chose the minimal graphics driver, because this system has Intel graphics. The Linux kernel used by Red Hat has a bug with some Intel graphics framebuffer hardware (intelfb). It’s easy to work around and fix it later. Most of the other options should be obvious. When in doubt, I typically take the defaults offered.
2. However, I don’t like dual booting two or more OSes, so I chose to “Use all space” for the disk options. When it came up, I chose the standard “Desktop” profile without trying to adjust the package selection.
3. When the installation is finished, it will kick out the DVD and wait for you to press “Reboot.” In the post-install configuration, you should simply pay attention to the options and choose what fits your needs. For example, I chose to use NTP for the system clock, and made sure to un-check the UTC box in the lower left corner.
4. After logging in, I immediately click on the Networking icon on the upper right toolbar and set up the option to connect automatically. Then I open the Terminal under Applications > System Tools, and “su” to root. This is the time to fix the Intel driver issue. I also run:
yum groupinstall "Development tools"
Almost every time I update post-install, I receive a kernel update, so this is where I reboot.
5. Upon logging in again, I add a few select packages. You can do this through the System > Administration > Add/Remove Software application or from the commandline as root:
yum install xterm bitmap-fixed-fonts aspell alacarte gnome-games gnome-games-extra gimp units vim-X11 elinks dos2unix unix2dos
The first two items after “install” go together. In particular, you might want
alacarte, which allows the user to edit the GNOME menu system. GNOME Games comes in two packages. I use GIMP from time to time, and whomever packages Elinks has recently begun tracking the original project itself; good text browser but requires a bit of work getting the options as you might like them. Units is a CLI conversion calculator between various types of measures, with a long list of metric, English, etc., units. Remember to hit CTRL-C when you are done to kill it. The rest you can figure out for yourself if you need them. Also, be aware you’ll need to chase down Aspell’s English language package on your own. I have no idea why it’s not in RHEL’s package repositories, but I built it from SRPM, pulled from Fedora 13′s repositories.
6. This is the time to do the first half of font fixing. After adding my favorite TTFs to my
~/.fonts folder (you’ll likely have to create it), then as root, fix the fonts by changing the settings for the whole system. Finally, I rebuild the Freetype libraries. That means chasing down the SRPM, and both SL and CentOS simply point you to the upstream RHEL ones. However, I’ve changed a few details from my previous tutorial: I use Yum –
yum localinstall nogpgcheck freetype-2.3.11-6.el6.8.i686 freetype-devel-2.3.11-6.el6.8.i686
Logout, hit CTRL-BKSP and restart the X server with the new Freetype libs. Fonts will look much, much better. Now’s the time to adjust the appearance of your desktop and set your preferred default fonts. I’ve always imported the Dirty-Ice GTK2 look in the process. You can probably find a copy using your favorite search engine.
7. Next comes the JDK replacement with Oracle’s latest 1.6 series (1.7 fails with OpenOffice and LibreOffice), because it’s much faster than the bundled OpenJDK package. I also grab the latest
fuse-ntfs-3g from RepoForge. That would be the one for “el6″ in this case.
8. After testing one more time to be sure, I cannot recommend Dag Wieers’ RepoForge because too many of the packages are way out of date, and they still exclude Mikmod, which I use. So if you want full multimedia and other advanced third party goodies, the best remains ATrpms. However, compared to my original tutorial, I typically leave off the Mplayer and extra codecs until I run into something which simply won’t work after adding all the extra goodies for Gstreamer. However, nothing in Linux land compares to using FFmpeg for converting audio and video files.
9. However, for Broadcom wifi, I don’t trust ATrpms to keep up when the kernel gets upgraded. It’s best to simply grab the zipped driver package direct from Broadcom. The instructions bundled in the driver are pretty good, but the point is whenever the kernel is upgraded, you simply rebuild at your convenience and re-install the module. Check the link periodically to see if they have updated to a later version; the latest is from October last year.
10. I prefer the latest versions of Joe’s editor and Lynx web browser. You can chase them down from the latest Fedora SRPMs; they’ve always built fine with RPMbuild. As of this writing, they can be found here. As time goes on, you can go there, jump up the “Parent Directory” links a couple of layers and back down into later releases of Fedora SRPMs. I also do the same with Alpine because I really prefer doing email from the commandline. You can learn how to configure Alpine here.
10. The last two items is adding Bleachbit and whatever browsers you might like. I seldom use Firefox for anything these days, but prefer Chrome and Opera. You can find them if you like them.
11. I also fix Vim. For some strange reason, on CentOS Vim also does not honor my
textwidth setting unless I put that on its own
set line in my
12. The last thing I do is turn off a few services I know I won’t use on my laptop:
You’ll find this in the menu under System > Administration > Services. Make sure the items you don’t need have a red dot to the left of them. Be very careful! You could easily cripple your system by accident by turning off something basic and essential, such as the keyboard driver.
At some point you may be requested to put in some password for GNOME Keyring. It’s just your login password, so don’t panic.
Update: 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)
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.
The Latitude will not be available. I’ll be testing CentOS on my Inspiron 1525. I am downloading via Bittorrent as I type this (and sampling the experience of dialup speeds for my browser in the process). Opera’s built-in torrent handler is pretty cool.
Review of procedures, etc., in a few days.
It’s not that I didn’t like running Debian Squeeze on my laptop, it’s that there was no reason to ever use the laptop since my desktop was identical. I noticed Scientific Linux (SL) was close to releasing their 6.0 and decided to try the latest release candidate. Unlike CentOS, SL runs a beta test program and it is now quite usable.
You can review the series on RHEL 6 for the Clueless (now in a static archive linked here) for most of the details. I’m sure most of that will also apply when CentOS 6.0 comes out later.
There are several other differences between CentOS and SL. It appears CentOS has a much larger user base, and the mailing list archives indicate a rather different kind of user. SL draws the Fermilab-CERN crowd, naturally, as that’s where it’s produced. The users of CentOS include a much larger group of rowdies, so to speak. I sensed the developers were being hounded by impatient folks, whereas the SL lists are much more calm about these things. On the other hand, CentOS developers keep more of their discussions in private, and don’t take time to post detailed descriptions of their progress toward each release. SL has their very public whiteboard, which is a copy of the project leader’s literal whiteboard kept in his office. There is also a nice listing of problem RPMs and how they went about getting past the build failures. Thus, perhaps it’s simply sane for the CentOS devs to avoid wasting time responding to every passing anxious user, whereas the SL folks don’t seem the face much of that.
You’ll be happy to know the ATrpm repository covers SL, as well. However, you’ll have to edit your YUM repo file once you install the ATrpm repo. Here is what I had to make mine look like:
This will get you all those nice tweaked codecs and packages for multimedia playback. Please note, Adobe now has it’s own YUM repo for the Flashplayer plugin. When you go to Adobe’s download page, you’ll get the option to select the YUM package. This allows updating the Flashplayer directly and automatically.
On the issue of fixing the bytecode hinting in the Freetype library, I noticed the SL repo is out of date compared to what is installed from the DVD. I had to get my SRPM directly from the RHEL respository. It still works out fine.
Overall I’m very pleased with how well it works like RHEL, but free and tweaked just a bit to make it easier to use. I heartily recommend Scientific Linux as a good clone of RHEL. The DVD required I select the minimal video driver, but it all worked nicely and I didn’t have to do anything to make suspend and hibernate work. SL has added a few more options for the touchpad to the standard GNOME mouse config dialog. This is typical of the enhancements you’ll find.
Today Red Hat issued a security update for Open Office on all three versions which had it (4, 5, & 6). If you don’t have access to RHN, you would be crazy to try building it from the SRPM. Frankly, you’d be crazy for not updating to the latest version now supplied by Libre Office.
(Update: Please note the advice offered below in the comments, and avoid using the latest version of Java 1.7. The latest updated version of 1.6 is still available and is preferred.)
Get it here. You’ll need both the main package and the help files. Open a Terminal window and login as root. Place them in a convenient directory. I generally use
/home/bkup for stuff like this. When you install RHEL with the default configuration, it gives most of the disk space to a partition for
home, where all the user directories are kept. Unless you have a half-terabyte or more, the other primary partition isn’t big enough for too much storage. Remove your old version of Open Office if you have it:
yum remove openoffice*
You’ll be shown a list of files being deleted. Do it. So you get it in that directory where you moved those two files, and you’ll need to open them up:
tar -xvfz LibO_3.3.0_Linux_x86_install-rpm_en-US.tar.gz
tar -xvfz LibO_3.3.0_Linux_x86_helppack-rpm_en-US.tar.gz
This will create two folders with matching long names on them. Start with the installer. Move down into the folder and you’ll see:
readmes RPMS update
You can drop down into the
readmes and take a look at the file there, but I’ll save you some time. Drop down into the
RPMS folder. The “update” is a script we won’t be using. Inside the RPMS folder is a whole bunch of oddly named RPMs. We’ll keep this simple. In order to install these packages, which did not come from Red Hat, we’ll need to tell Yum to skip the signature checks, because we already know we can trust the good folks at Libre Office.
yum install --nogpgcheck *.rpm
On the the Linux command line, that asterisk is a symbol which means “match all” and we qualify that with the “.rpm” so it matches all the RPMs in the current folder. Yum will run through all the RPMs and check that they match up, then ask you to make sure you want to do it. You do, so hit “y”. Now move into the folder which holds the menu integration RPMs:
Here, we need the package which integrates with the Red Hat menu system for your desktop, and we’ll tell Yum the same thing about that package, not checking the signature:
yum install --nogpgcheck libreoffice3.3-redhat-menus-3.3-6.noarch.rpm
Move up three layers, then down into the other folder with the RPMs:
We need a similar incantation for this single RPM as we did the others:
yum install --nogpgcheck *.rpm
You’re almost done. I’m not sure where it came from, but there is an odd glitch in how this actually configures the menu. In mine, at least, I got duplicate entries, with one set for the new Libre Office 3.3, and another for the old Open Office 3.2. This stuff happens from time to time, and it’s why I advised adding the Alacarte menu editor in my installation tutorial.
Right-click on your “Applications” menu and select “Edit Menus”. In the window which opens, on the left pane select “Office” and you’ll see the list on the right pane. For all the items labeled “OpenOffice.org” simply click to remove the check marks. They are the ones missing the icons. This will hide them as menu entries. All that’s left is the newly installed LibreOffice stuff. You’re done. Enjoy.
Because RHEL is essentialy an industrial grade commercial product, you’d have to expect it can run more types of server than most people would ever need.
We covered the Samba server in a previous lesson as the most common need for small or home operations. As long as you have to accommodate Windows clients, Samba is the simplest way to go, since even Linux clients can use it. However, if all you need to worry about is sharing files with other Linux/Unix clients, the NFS (network file system) is really better. It’s not covered in the Deployment Guide, and the only simplified guide I’ve seen is this one. There really isn’t that much to it. Windows can use NFS, and Microsoft offers the software to use it, but they assume you are migrating away from Unix, and will demand some information from you. At that, it only works on the Pro versions of their OS. You could also search for some third party software packages, but it I don’t know whom I would trust for that.
The majority of my computer ministry clients have no use for an FTP server. On top of that, the RHEL Deployment Guide hardly mentions it. However there are already some good, short tutorials on how to get it working. This one is fairly generic, but rather complete. And here’s one which covers the SELinux aspects of configuring your FTP server. RHEL uses the Vsftp (Very Secure FTP) server. The CentOS HOWTO Wiki on Vsftp actually hands it to you with scripts to set it all up. It centers on using a feature called “chroot” — a sort of controlled sandbox which makes it exceedingly difficult for those using your FTP server having any chance of cracking the machine itself. I recommend the TSL script for setup.
Much more popular is the Apache webserver. The Deployment Guide covers it, but in a good bit more detail than you might find useful. Again, some enterprising writers have already given us a head start. This one is short and sweet, covering the bare essentials. Then there is this one which addresses the details of SELinux protections, how to configure for a server which hosts multiple sites, and much more. If you need to enable the secure protocol (https) I really like this one from CentOS Wiki.
But if you are going to go that far, you should consider using the well known LAMP stack (Linux, Apache, MySQL and PHP). It’s almost trivial adding the MySQL server and PHP. What isn’t trivial is the knowledge necessary to use them. Here is a good generic setup tutorial, but be aware a few of the package names may have changed for RHEL 6. However, cnce you get Webmin installed, you are limited only by what you know about webmaster and system administrator tasks in general. It’s the easiest way to go for the clueless, with some documentation, and for more than just the LAMP server itself. However, I recommend you download the Webmin Manual (PDF). It can make a wide range of system administration tasks much simpler, and people are running entire ISPs this way.
Of course, the big thing with RHEL 6 is the kernel-base virtual machine (KVM), the computer within a computer. It requires some rather powerful hardware. Frankly, I can’t imagine needing it for my clients or myself. Still, the Techtopia series starting with section 33, gives you the shortest path, I think, using Windows 7 as the client OS. You can always plow through the Deployment Guide, of course, but it’s harder to follow. It’s written for well-trained technicians with some experience in that sort of heavy duty server work.
One of the most useful things RHEL can do in an organization is serve as the firewalled gateway. This can be easily combined with other tasks on the same machine. Naturally, it requires your RHEL box to have at least two hardware ports, since one becomes the internal trusted interface, and the other an untrusted interface. Then a standard multi-port LAN switch can feed into the RHEL box if you have a significant number of computers. This is well covered in the Deployment Guide, but you probably would find this page a lot simpler. To do anything special requires you understand firewalls and policies. There simply is no shortcut there, however, the defaults configurable from the RHEL GUI firewall manager are pretty good for most uses.
As with the mail server, most of this is pretty hard to test from a home LAN with a broadband connection. If your ISP permits running a server, but can’t offer a static IP address, you should consider connecting through an external DNS service such as OpenDNS, DynDNS, and number of other free services. They keep track of resolving your domain name to whatever IP address you have at the time. It’s pretty rare when you’ll need to run your own DNS service internally, except perhaps a simple name caching. However, even that is becoming almost pointless, as these external free services are quite reliable compared to even the larger broadband ISPs.
The possibilities of RHEL 6 will quickly outrun all but the most obscure server needs.
In trying to keep RHEL 6 up to date without support, I am sometimes both amazed and disappointed at the way Red Hat keeps some of the SRPMs out of reach.
The RHSA notice presents a minor security warning about the Hplip libraries. But if you attempt to build from the SRPM, you’ll find a dependency almost impossible to fulfill. In order to build Hplip, you need
sane-backends-devel. But that one is not normally installed, and if you lose your access to RHN, you’ll have to build it from source. That, in turn has a dependency on
There is no source for that. I scoured the freely accessible repositories in both RHEL (including the Beta sources) and Fedora, and there is nothing close. Remember, a partial requirement is keeping the versions consistent. The version for
gphoto2 is 2.4.7-4. The closest you’ll get is the FC12 package, which is 2.4.7-1. Even if you cheat and edit the SPEC file in the SRPM to call itself “-4″ it won’t built the devel package. I have no idea why it’s excluded, but it won’t produce. Thus, you end up with something totally orphaned here. Then you end up wondering how the Red Hat developers built it themselves in the first place, except they simply aren’t being honest in releasing all the applicable SRPMs.
The CentOS developers noted this often enough in their developers mailing list. There are times you simply can’t replicate Red Hat’s work because they hold stuff back. I lack their expertise in recreating the missing SRPMs from sources, chasing down the peculiar collection of patches, etc. At any rate, the work-around is simply installing the
sane-backends-devel RPM from the Beta repositories, because it’s the same version. But I’m still left without any source for
gphoto2. I can get the dependency for it (
libgphoto2) but not the item itself.
If you are running RHEL, you are already running a mail server. It’s installed by default and setup to run. Of course, it only delivers mail locally, and only from sources within your own machine. Right now, there are no sources, so there is no mail. But the server is running.
The original Unix way of things was to use the mail server as the primary internal message system. RHEL is old fashioned in this respect, though by default, nothing is turned on which sends any messages to the root account. If you want to learn more about what’s going on in your system, install the logwatch package with Yum and you’ll start getting daily email messages to your root account with standard notifications of newly installed packages, who logged in when, and other significant events most system administrators track. You can adjust what sorts of things logwatch tells you about, but the defaults are pretty good.
The problem is, you’d have to figure out how to read that mail. By default the simplest way to do that is to install something called Mutt — as you might expect, the package name is in lower case. Yum will take care of it easily. Then, you could login as root every day and fire up Mutt, and read the logwatch messages. Or, you could tell the mail server to give root’s mail to someone else, such as your own user account. All you have to do is login as root, and:
At the very bottom of the file, simply add a line which says:
The file itself explains the format; use a TAB between the colon and your username. Then close Gedit and run the command
newaliases. Then you only have to open a Terminal window every day and run Mutt yourself. Mutt is not user friendly, particularly for folks moving from Windows. I don’t like it either; I use something called Alpine. I’ll give you a hint that any email client you use, including the default Evolution on RHEL, can be set up to read mail directly from the internal mail server.
My habit is to use the commandline environment (AKA the console) for as much as possible — all my email accounts, a lot of Internet surfing, most of my editing, and so forth. If you get tired of Gedit, try
nano from the commandline for editing. It’s included in RHEL by default. Most of the keystrokes you learned in Windows tend to work the same, plus the window displays several important commands at the bottom.
Unless you are setting up a commercial grade operation, you really don’t have much chance to play with mail server administration. There was a time when most ISPs and such would tolerate a Linux user running their own mail server from home. That is, you could have your machine fetch mail from your accounts and pass it internally to your mail server. Then you could send mail from your server through the official servers where your accounts resided. Those days are gone. Very few mail servers out there will accept server connections from you because you, typically because your IP address is listed as non-server territory. They will only talk to your email client, not your server.
If you do have a genuine server connection to the Net, and you need to run a mail server operation, it’s hard for me to rewrite the instructions provided by Red Hat in their Deployment Guide. If you know what a mail server is supposed to do, it’s not that hard to plug in the values for the configuration files.
What I do want to explain is how RHEL lays out this operation. There are three programs you’ll be running in most contexts: Postfix, Dovecot and Procmail. Dovecot is the POP and IMAP server, what allows your users and clients to get their mail from your machine. Incoming mail is caught by Postfix, which passes it to Procmail for sorting. Procmail decides who gets what. You can also have Procmail filter for spam, by plugging in SpamAssassin. You’ll need to tell your mail system the various domains for which mail is accepted and handled, and where it goes. Postfix also handles your outgoing mail. As the system administrator, you would set up all the accounts for your users. Again, the RHEL Deployment Guide is not that hard to follow.
While the current crop of CentOS HOWTOs are somewhat dated, most of the details are still accurate. If you are serious about running a mail server, it’s a good place to start. You may want to consider using their Postfix and Dovecot with SASL for running the now standard secure login features for an organizational mail server.
There are some good tutorials from other sources, though some of them a little dated. One of the simplest, and missing instructions for Procmail, is at the CentOS website. Each of the three programs have their own website with more information than you can absorb: Postfix, Dovecot has a wiki, and Procmail has links at the bottom of their page to various tutorials.
If you intend using your RHEL machine as a server among Windows machines, one of the first things you should consider is using Samba. This is the Open Source implementation of Windows’ SMB. Samba allows your RHEL box to provide a compatibility layer so a Windows computer on the same network, such as your home LAN, can read portions of the Linux file system natively. It is also the only way I know you can have Linux operate as a print server for Windows sharing. That is, if you have a printer connected to your RHEL box and working, Samba allows you to provide a Windows computer access, provided that Windows box has its own driver for it.
There seems to be no documentation from Red Hat, and Samba itself offers a huge documentation library because there are too many options for any sane person to examine. There are some items you’ll need to prepare before starting: username (so the Windows user can login from their machine), password, and the network IP address on your LAN for the other computer(s), and a shared directory with world write permissions. If a printer is involved, make sure it’s setup to share.
RHEL provides a GUI tool for printer setup. If your printer is connected via USB, it should be recognized immediately if RHEL knows what it is. This is the place to check. There isn’t space here to chase down all the various problems you might encounter, so if it doesn’t pretty much work, and you can’t get it recognized and configured through the Administration menu, you’ll need to engage your favorite search engine using your printer model with the keyword “linux”, or terms “RHEL” and “Fedora” and make the most of it. In the menu system for the printer configuration tool is a place to checkmark some boxes to share the printer.
I’ve found a couple of tutorials on Samba, but neither one had all the right information. After fighting with it a bit, this is what I did to get it working.
Install Samba by logging into a Terminal as root:
yum install samba
Create shared directory; I used
chmod a+w /home/shared
chcon -t samba_share_t /home/shared
That last line insures the SELinux security system knows to allow outside systems to poke around in that folder. Now anyone using this computer can move files in and out of the folder, as well as the Samba users.
Add a Samba user. This is a different task than simply adding a user account. There is a GUI tool for adding Linux user accounts to the machine for them to use the computer itself. However, Samba users must be handled differently, so that the system forces them to use the Samba server.
useradd -c "Real Name" -d /home/samba-username -s /sbin/nologin samba-username
That’s all one line. As usual, substitute the actual Real Name and samba-username in the command above. Then create the Samba password. Remember what we said about coming up with good passwords:
smbpasswd -a samba-username
It will prompt for the password, which you type in blindly:
New SMB password:
Retype new SMB password:
Added user username.
This will open the default text editor. Scan down the file until you see something like this:
root = administrator admin
nobody = guest pcguest smbguest
Immediately below this, add a line with this format:
username = samba-username
so RHEL recognizes the person logging in from the Winbox by their samba-username. Close this file by saving it, then open a file in the same place:
/etc/samba/lmhosts. The first line should show:
127.0.0.1 localhost. Add another line below that:
That is, the IP address on your network of the Windows box, and it’s hostname in lower case. If you don’t know how to find the IP address on Windows, use these instructions. To get the hostname, try this page from the same site. Save that file.
/etc/samba/smb.conf. Find the section headed
[global]. Change the workgroup name to whatever your Windows computer will be seeking. Default is
workgroup in lower case letters. You’ll need to remove the semicolon in front of the next line and provide a proper hostname for the
netbios name, which would be the name you gave your RHEL computer during installation, again in lower case. Remove the semicolon from the next line and the IP address numbers from the sample; all we need are the two interfaces
lo eth0. Below that is a line with
hostsallow as a model. Below that, start a new line with the same indentation:
hosts allow = 127. 192.168.1.
The “127.” is the IP address for everything on your own machine. The other (192.168.1.) is the private LAN network I use for my home router; by leaving off the last section after the dot, it automatically includes every computer with that prefix, which is reserved for LANs.
Go all the way to the bottom of the file and add some lines. I named my shared directory “shared”. Thus, the section heading should be named the same:
path = /home/shared
writeable = yes
browseable = yes
read only = No
guest ok = Yes
public = Yes
valid users = username1 username2
create mask = 0666
directory mask = 0777
Now change the firewall to allow Samba to get through. You can use the tool in System > Administration > Firewall. Simply scan down the list to Samba and checkmark the box. Optionally checkmark IPP printer sharing. Then hit “Apply”. Now we start the service manually; it’s actually two services:
/sbin/service smb start
/sbin/service nmb start
Test whether your Windows box can find the server. In Win7 and Vista, that’s via your file manager window. On the left hand side look for the Network icon. Double click to open and the computer should search for other machines. Your RHEL box should eventually show up by it’s hostname. Double click and see if you can login from there. If successful, your shared folder and any printer you’ve permitted will also show.
For XP and Win2K, it’s a similar idea using the file manager. The simplest way is to right-click on “My Computer” and select “Explore” so that the left pane shows the various drives, and should display a network connection to the RHEL server.
If it works and you don’t have to cry for help, you’ll want to make it a normal service always running. System > Administration > Services — find “nmb” and “smb” and click the “Enable” button. From now on, upon boot the system will start the two services automatically.
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:
- RHEL SRPMs
- FC13 Update SRPMs
- 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:
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.
* 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.