Home / server / Questions / 91632
Accepted
crb
Asked: 2009-12-08 03:43:10 +0800 CST

How can I remove the GUI bits from a Red Hat Enterprise Linux install?

  • 772

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.

linux

4 Answers

  1. 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 :-)

    • 1
  2. Best Answer

    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.

    • 0

  3. 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.

    • 0

  4. 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.

    • 0