Chattanooga
Unix
Gnu
Android
Linux
Users
Group

 

Hot Topics:

Sponsoring:

Redhat Yum can still be RPM-Hell(tm)

From: Mike Harrison 
------------------------------------------------------

I built a Centos server two weeks ago.. No real issues besides my learning 
curve.

But an upcoming install requires licensed support OS and Database servers.
This means, for this project and some others: Redhat 6.4 Server.

On first boot, after joining the Redhat subscription network and such OK.

I can't get past, and would like to find a work-around:
(yes, I've been searching redhat's support site.. seems a lot of problem 
with this kind of thing, but no solutions for this specific one):

[root@footest1 ~]# yum update
Loaded plugins: product-id, security, subscription-manager
This system is receiving updates from Red Hat Subscription Management.
rhel-6-server-cf-tools-1-rpms 
| 2.8 kB     00:00
rhel-6-server-rhev-agent-rpms 
| 3.1 kB     00:00
rhel-6-server-rpms 
| 3.7 kB     00:00
rhel-ha-for-rhel-6-server-rpms 
| 3.7 kB     00:00
rhel-lb-for-rhel-6-server-rpms 
| 3.7 kB     00:00
rhel-rs-for-rhel-6-server-rpms 
| 3.7 kB     00:00
rhel-scalefs-for-rhel-6-server-rpms 
| 3.7 kB     00:00
rhel-server-dts-6-rpms 
| 3.1 kB     00:00
https://cdn.redhat.com/content/dist/rhel/server/6/6Server/x86

=============================================================== From: John Aldrich ------------------------------------------------------ Quoting Mike Harrison :

=============================================================== From: Lynn Dixon ------------------------------------------------------ Mike, The reason your getting that error is because the *dts repos are the "Red Hat Developer Tool Set" which (I think) will require a subscription to the Developer Tool Set channel. Red Hat recently annouced this prodcut at Summit this year. I sit in one of the sessions that discussed it, and its actually a really awesome step that Red Hat is doing for developers. Here is the powerpoints they did: http://www.redhat.com/developerexchange/Red

=============================================================== From: Mike Harrison ------------------------------------------------------ The question is: Why in hades would this extra repo be required on a default virgin installation? As I get into Redhat again, I am reminded that for all of it's awesome support of Linux, it is in many ways the Microsoft mentality applied to Linux. I installed a CLI only system, and I'm blown away that so many tools for bare server system config are GUI. For example: "system-config-services" requires X and GTK when the other system-config-* tools are CLI. Luckily I know how to do it the hard way, linking /delinking files.. but I appreciate and use nice tools because I like to be able to help people to use them when supporting someone over long distances. I've almost spent more time configuring access/subscriptions/licenses than I have getting the server online. For the record, because a few people know me: I installed gcc installed and compiled "joe" the editor from source, very quickly. :) Question: If it's basicly just a LAMP server, is there anything in that "Developer Tool Set Channel" worth subscribing to and worrying about?

=============================================================== From: Lynn Dixon ------------------------------------------------------ If you don't plan on running a GUI, then you don't need system-config-services to be installed. Its just a GUI wrapper for the chkconfig for Upstart and sysvinit. You also don't need to manage services in RHEL by linking and unlinking files in the respective /etc/init.d and such. You should really be using chkconfig to control which services start at boot (should handle xinetd as well). If you need to stop/start/restsart/whatever a service, you should use the "service" command. An example would be: service network restart Typcially anything that has system-config-* is just going to be a GUI wrapper for the pre-existing CLI tool for those that prefer to do things in a gui. One exception is the system-config-firewall-tui, which is a really good iptables CLI management tool. RHEL has and will always be primarily designed for run level 3. Redhat's main focus is to make the entire OS manageable from CLI, but to also provide GUI wrappers for those same tools for people that do choose to run runlevel 5. At Mohawk, we have a policy that all production servers run in runlevel 3, with no GUI tools installed. QA and Dev boxes only get GUI tools on a case-by-case basis. Once you learn the tools Red Hat builds into their OS for CLI management, you will be amazed at how easily it can be managed. I just downloaed the most recent ISO for RHEL6.4 earlier this week, as I had to deploy a physical machine on Monday. I did not have the DTS channel or repo enabled on the default install, so I am not sure how it became enabled on your instance. Did you modify the repos during the install? As far as DTS, you shouldn't need anything in that repo for any production box. The packages in DTS are going to be very upstream from the current RHEL packages, and are meant for developers whom need extremely current toolsets so they can develop future packages for RHEL without being as "bleeding" edge as Fedora. A good way to describe it would be that DTS has packages that are "in-between" the current Fedora release, and the current RHEL revision.

=============================================================== From: Mike Harrison ------------------------------------------------------ yea, the MS-Way.. not "/etc/init.d/httpd start" they aren't "services" they are daemons ;) I'd love commands like: daemon apache2 live daemon tomcat die Thanks for 'chkconfig' that's a new one. on me. I went the Debian then the Ubuntu way at Redhat 9.. It's similar to "update-rc.d", but I don't use it either, been doing it the hard way too long. Laughing.. But I'm trying to make an install document/procedure for others. Trying to find the best ways and that will work.

=============================================================== From: Lynn Dixon ------------------------------------------------------ I don't know that I would call it the MS Way, seeing as the service command uses /etc/init.d/someservice I would much rather type the shorter command service httpd start as compared to the longer /etc/init.d/httpd start Whether we call it a "service" or a "daemon" is purely a matter of semantics. :-P Im happy to help wherever I can, I have a few Red Hat certifications, and rarely get to use them at work since we have a realtively small *NIX footprint at work.

=============================================================== From: Mike Harrison ------------------------------------------------------ I'm just used to systems with much less helpers, and remember when even the /etc/rc.x/ init.d way was the "new" way.. or at least, I seem to remember there was a way that was different so long ago. The "service" word is just more acceptable to the MS-community and those who don't believe in Daemons.

=============================================================== From: Lynn Dixon ------------------------------------------------------ Just wait till you see systemd. Talk about monolithic piece of complicated mess. Its coming in RHEL7 since its been pushed so heavily in the Fedora world for a while now by the Gnome people.

=============================================================== From: "Dr.D " ------------------------------------------------------ But you can look into /etc/init.d and see what you can start . :-) Yum on CentOs is very stable, suppressed RedHat is giving you issues... Don