3 ms·

We are currently facing a situation where our data center guys only allow us to use RHEL in production but since we standardized on PostgreSQL (moving off MSSQL

by eitally 12y ago

We are currently facing a situation where our data center guys only allow us to use RHEL in production but since we standardized on PostgreSQL (moving off MSSQL) we've been devving on 9.2/9.3. RHEL's officially supported version of PostgreSQL is still 8.3/8.4. The devs are up in arms about being "forced" to use a major version behind just because the DC team won't let them install and self-support the latest stable version. Ridiculous.

nanoscopic 12y ago
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.
p8952 12y ago
Surly the issue here is a complete lack of communication? Why did the development team start of 9.x without first consulting Ops about what versions are supported? Allowing developers to install and "self-support" a non-supported database version is an _awful_ idea. When shit hits the fan it will be Ops/DBAs who are left to pick up the pieces.
- nanoscopic 12y ago
  The authorization process for RHEL package approval is questionable. Additionally in house verification process of compatibility of software is questionable. It is hard to argue that using PostgreSQL 9.x is dangerous compared to using PostgreSQL 8.x.

by eitally 12y ago

nanoscopic 12y ago

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.

p8952 12y ago

Surly the issue here is a complete lack of communication? Why did the development team start of 9.x without first consulting Ops about what versions are supported? Allowing developers to install and "self-support" a non-supported database version is an _awful_ idea. When shit hits the fan it will be Ops/DBAs who are left to pick up the pieces.

nanoscopic 12y ago
The authorization process for RHEL package approval is questionable. Additionally in house verification process of compatibility of software is questionable. It is hard to argue that using PostgreSQL 9.x is dangerous compared to using PostgreSQL 8.x.