4 ms·

RHEL, CentOS, and Fedora are all basically the same thing. The difference is which package versions are approved for use. For the most part, you can add the y

RHEL, CentOS, and Fedora are all basically the same thing. The difference is which package versions are approved for use. For the most part, you can add the yum configuration for CentOS or Fedora to RHEL machines, and install newer packages without breaking it. Note that some packages will end up pulling in a ton of other dependent packages. By adding a Fedora repo to a RHEL machine, the following things will happen: 1. You will likely lose official support from RHEL. Anything that goes wrong is your fault. 2. Your OS install will start becoming Fedora; as you install more and more stuff. 3. Your setup could break entirely because RHEL packages are not tested to be compatible with Fedora ones. The core configuration is different in places, and generally you should not start updating the core components as this will break things. My recommendation is to setup the CentOS/Fedora yum repos on your RHEL box. Run yum install for new PostgreSQL and see what yum wants to install. Eyeball the results intelligently and take some guesses as to whether it will break things. Cross your fingers and approve it, then disable the CentOS/Fedora repos you added. Carry on with your life and don't tell IT what you did. If you can't connect your RHEL machine to outside network, repeat the process somewhere else to figure out what RPMs are needed. Download them elsewhere, and stick them on the RHEL machine and install manually. As an additional note; I have setup a Fedora repo on a RHEL machine and changed the flag in the system to change the distribution ( there is a core package everything depends on... ). We then updated all, and the resulting system still functioned. Very evil, but it didn't explode. Also; it took quite a while to install all the packages. It essentially is converting the whole system from RHEL to Fedora in place...

shanemhansen 12y ago
This isn't a good idea. Why? Because it takes IT from the position of being a roadblock, which is something you can push to get fixed and puts you in the wrong instead. IT has valid reasons using RHEL and older packages, you presumably have valid reasons for using newer packages. If newer packages are needed work with IT to get those newer packages. This also means that they are back in the position of being a roadblock if critical projects really can't go forward due to their policies. Sometimes the way to fix what is broken is to make your department stop being a crutch for failed IT policies. Also, randomly changing system packages in production is a dick move. That sort of shit is (rightfully) going to result in getting your access revoked at the minimum.
- nanoscopic 12y ago
  Multiple hour long meetings with all of the internal authorities were involved. They all refused to allow new packages to be installed. Additionally, they were not even providing the proper update packages from RHEL due to system misconfiguration. EPEL was additionally forbidden. Regardless, the powers that be essentially said "You are not allowed to use the software that your project specification states that it needs." It was either use other components or circumvent IT. The head of the department got fed up with the red tape and told us to circumvent. All proper discussion was done before that, and as a result nothing I did was a "dick move". The system was additionally not in production yet, so no changes in production were being done. Shame on you for making too many assumptions.

shanemhansen 12y ago

This isn't a good idea. Why? Because it takes IT from the position of being a roadblock, which is something you can push to get fixed and puts you in the wrong instead. IT has valid reasons using RHEL and older packages, you presumably have valid reasons for using newer packages. If newer packages are needed work with IT to get those newer packages. This also means that they are back in the position of being a roadblock if critical projects really can't go forward due to their policies. Sometimes the way to fix what is broken is to make your department stop being a crutch for failed IT policies. Also, randomly changing system packages in production is a dick move. That sort of shit is (rightfully) going to result in getting your access revoked at the minimum.

nanoscopic 12y ago
Multiple hour long meetings with all of the internal authorities were involved. They all refused to allow new packages to be installed. Additionally, they were not even providing the proper update packages from RHEL due to system misconfiguration. EPEL was additionally forbidden. Regardless, the powers that be essentially said "You are not allowed to use the software that your project specification states that it needs." It was either use other components or circumvent IT. The head of the department got fed up with the red tape and told us to circumvent. All proper discussion was done before that, and as a result nothing I did was a "dick move". The system was additionally not in production yet, so no changes in production were being done. Shame on you for making too many assumptions.