Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have been managing Debian, and now Ubuntu, desktop systems for a small shop for several years now. I am very comfortable with apt for package management and distribution upgrades. The Ubuntu installer has worked for every system I have needed to add. I have not touched Red Hat for many years and have never really managed any RHEL systems.

I have an opportunity to take over a RHEL and CentOS shop. I am looking for a list of issues / management concerns specific to rolling out RHEL and CentOS as desktop environments for multiple users who have a mix of Dell desktop and laptop systems.

What issues should I watch for when rolling out CentOS as a desktop environment?

share|improve this question
add comment

2 Answers

up vote 1 down vote accepted

First, yum is the new apt, at least when it comes to using RPMs instead of DEBs. The intent of the tool is the same, but the functionality is slightly different (for instance, Debian/Ubuntu uses a separate CLI tool to query packages for contents, while yum is more of an "all in one" approach).

Coming from Debian/Ubuntu, I can easily say that you will miss the "completeness" of the available packages for download. There are several odds'n'ends that are handy to have but are not stock in a CentOS/RHEL environment. You can easily add extra repositories (the equivalent of a Debian/Ubuntu apt site) to yum, but keep in mind that you're trusting the source you're adding, before doing so. Nothing is more irritating than to find that you need tool X to do task Y, but tool X does not have an RPM available in the official repos (or worse: it depends on secondary package Z that has no RPM). Bummer.

At some point, you will be tempted to

  • pull in an RPM that is not a part of your distro, or
  • pull in some other package format that is not in RPM format

While this (usually) works, try to avoid it. RPM installs try hard to be distro-neutral, but I have seen malformed packages that made assumptions about certain directories being "there", where "there" is a directory path on some other distro. Generally speaking, you're better off just downloading the source RPMs and rebuilding the package; the resulting packages will be built for your environment and will not have some of the crazy pathing issues that you can occasionally see.

From your end-user's perspectives, a lot of the Ubuntu eye-candy will be gone; instead, you get a rather vanilla-looking Gnome setup, nothing wrong with that mind you, just a bit staid, that's all. The OOB software tends to also follow this "conservative" approach to a desktop as well, although adding the repo (as mentioned above) will remedy that if you need to.

share|improve this answer
add comment

I'd add that adding a variety of yum repositories would be helpful. The "official" ones are very sparse in certain areas.

You should also look at setting-up your own yum repository so that you're syncing to that, and then installing locally, if at all possible.

The repos I have:

epel-testing.repo
epel.repo
google.repo
jpackage17.repo
kbsingh-CentOS-Extras.repo
kbsingh-CentOS-Misc.repo
other.repo
remi.repo
rpmforge.repo

sample contents:

> cat jpackage17.repo
# Be sure to enable the distro specific repository for your distro below:
# - jpackage-fc for Fedora Core
# - jpackage-rhel for Red Hat Enterprise Linux and derivatives

[jpackage-generic]
name=JPackage (free), generic
baseurl=ftp://jpackage.hmdc.harvard.edu/JPackage/1.7/generic/free
#mirrorlist=http://www.jpackage.org/mirrorlist.php?dist=generic&type=free&release=1.7
failovermethod=priority
gpgcheck=1
gpgkey=http://www.jpackage.org/jpackage.asc
enabled=1

[jpackage-rhel]
name=JPackage (free) for Red Hat Enterprise Linux $releasever
baseurl=http://mirrors.dotsrc.org/jpackage/1.7/redhat-el-4.0/free
#mirrorlist=http://www.jpackage.org/mirrorlist.php?dist=redhat-el-$releasever&type=free&release=1.7
failovermethod=priority
gpgcheck=1
gpgkey=http://www.jpackage.org/jpackage.asc
enabled=1

[jpackage-generic-nonfree]
name=JPackage (non-free), generic
baseurl=http://mirrors.dotsrc.org/jpackage/1.7/redhat-el-4.0/non-free
#mirrorlist=http://www.jpackage.org/jpackage_generic_nonfree_1.7.txt
failovermethod=priority
gpgcheck=1
gpgkey=http://www.jpackage.org/jpackage.asc
enabled=1

Just Google "yum repository " for specific directions on importing the GPG keys :)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.