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 am looking at a farm of RedHat Enterprise Linux (RHEL) 5.3 servers, which all have GNOME and Xorg installed, none of which need them. They were deployed by a 3rd party from a VM template, and I don't know all of their history. What I do know is none of them run an application that actually requires having a full GUI installed. However, it is possible, that some run an application that requires some X libraries (ImageMagick comes to mind).

According to yum grouplist, the 'X Window System' group is not installed, so I can't use yum groupremove here.

Is there a sufficiently low-in-the-dependency-chain package, or packages, that I can remove, which will pull out Gtk, GNOME and Xorg? Alternatively, if it generates a list of packages to remove before starting, we can reinstall the applications we need, which will pull back the X libraries, when we are done.

share|improve this question
add comment

4 Answers

up vote 0 down vote accepted

I haven't done this with real, live RHEL, but I have pried X out of CentOS 5.1 and 5.2. (I've been pulling X off of Redhat-derived distros for years... ever since the dependencies were made such that you, basically, had to install X, whether you wanted it or not.)

I don't recall the exact dependencies, but, as I recall, there are some annyoing dependencies that require a "--nodeps" argument to RPM in order to get the offending RPMs to remove. I just start ripping out packages I don't need, adding more and more packages to the "rpm -e" command-line, and finally adding "--nodeps" when necessary.

I don't know that I'd recommend doing this for production machines. I don't deploy any quantity of CentOS in production environments, so it's probably alright that I potentially screw up my installation. In a production environment, disk space is cheap. I don't like having unnecessary software installed, from a security perspective, but The Right Thing(tm) is probably to rebuild the packages with offending dependencies (without the offending dependencies, obviously) rather than just ripping out and potentially making a system unusable.

share|improve this answer
    
I agree with your "the right thing" assessment, but at this point, I'd like to investigate a smarter answer, at least for our dev/staging environments. If you were able to remember any dependency problems you had it would be great. –  crb Dec 7 '09 at 12:24
    
I'm not sure what you mean by "a smarter answer". Anything other than rebuilding packages w/o dependencies is going to leave you with broken dependencies as far as RPM is concerned. You'll need to test all your applications to insure that they function w/ the broken dependencies, since anything you install is going to assume the dependent packages are there. If it'll help, I can send you the output of an "rpm -qa" from one of my CentOS 5.2 boxes. I didn't really keep notes of what I've removed, since I don't deploy CentOS in production to my Customers. –  Evan Anderson Dec 7 '09 at 12:45
    
Sorry for not being clear; I meant "smarter" solely in terms of not taking as long to rebuild entire machines and remigrate. Ultimately, I want to be able to say "if I remove package A, packages W X Y and Z" will be removed, and if I know I don't need W-Z, I can go ahead and remove A safely. I suspect that using yum here would be safer than plain rpm. –  crb Dec 7 '09 at 13:49
add comment

You might also consider just not starting the X server / GDM at boot and leaving the packages there. I guess they will take up some space and add time to updates, but other than that I wouldn't think they will cause any issues.

For your situation you might really want them removed, or you might have already considered this, but I just though I would put it out there :-)

share|improve this answer
    
Thanks Kyle, that's where we are at, at the moment; I hoped that this lovely dependency-resolving system Red Hat has would make doing the tidy up trivial. –  crb Dec 8 '09 at 10:41
add comment

I am doing basically the same thing at the moment. My method is mainly manual, due to the lack of tools for this, but it might be of help.

First, deploy a new server with the correct list of packages you require, i.e. without X and Gnome. Then, diff the package list on the old and the new server. It is not wise to just try and remove the whole diff from the old server - you never know what'll break - but it can be a start. Take some big packages from the diff that you are sure will not break stuff (like nautilus) and start from there. Try a rpm -e --test on the compiled list, rinse, repeat. The final list can then be used on the other servers fairly painlessly, given that the servers are all similar.

I heartily agree this is not a nice, clean, standardized way of doing this, but I value removing the Gnome and X crud from my servers more highly than having some streamlined process to get there. Mind, btw, that I didn't install these servers, I am merely cleansing them. ;-)

We only remove the the packages during patching downtime, so we can test the app (Oracle, mostly) directly after removing them. In case of breakage, we yum install the list and try again with a smaller subset. Not that that ever happened, but you should be prepared for the worst. Like Evan said: this is risky business.

My main target is to remove the bigger X apps from the servers (like, again, nautilus, firefox, openoffice, etc.) mainly for the reason of decreasing the security footprint. The fact that some smallish apps will possibly remain installed is fine with me - for now - because we are 'catching the bigger fish', so to speak.

share|improve this answer
add comment

I made it work with Kickstart. If you create a kickstart config file you can exclude base from the packages definition and get a really minimal install. I think it was so minimal it didn't even have yum and a few others, and I had to add those packages back in.

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.