3 ms·

To chime in with contrasting experiences at other companies: Where I used to work RHEL was used on all of the servers. I was part of a team developing some new

To chime in with contrasting experiences at other companies: Where I used to work RHEL was used on all of the servers. I was part of a team developing some new software using Mongrel2, MongoDB, ZeroMQ, Perl, and Imagemagick ( among a whole collection of other esoteric small pieces ). The plan for the project was approved and development underway. We encountered problems getting everything to work properly with modern versions of the various parts in the distribution of RHEL provided. The company was mirroring RHEL, but only the core. They were not mirroring the updates, nor were they mirroring the latest released version of RHEL. Outside access was forbidden on the servers, so we could not fix the problem ourselves without going around network policy. We requested virtual machines; specifically to use Virtualbox on our desktops to do development until the policy people could figure out how to give us a server with the software needed. We were denied and told we had to requisition a server to run VMs, that VMs on desktop were forbidden. A $13k server was purchased for this purpose, and root access was denied to it. We couldn't configure it as needed, and IT refused to help. It was basically useless. The main department head approved going ahead with VMs regardless of the network admin and head of software development saying we couldn't. In the end the project flopped; ultimately due to inability for any of IT to get along or provide what was needed.

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.
serve_yay 12y ago
Incredible. They locked down everything so hard that they forgot the part where they allow people to do their jobs!
- nanoscopic 12y ago
  Yes; months of development time were wasted fighting with IT instead of being able to do our jobs. We weren't even allowed to use Git for several months, because it wasn't yet "approved." Even supposing we continued to use SVN, they were using an older version of SVN that was much slower and more inefficient. The software requisition process was also terrible. It took 4 months from when I started the job just to get basic software that that is typical for software development. Before that I was directed by my coworkers and superiors to use portable versions of the software I needed secretly.

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.

serve_yay 12y ago

Incredible. They locked down everything so hard that they forgot the part where they allow people to do their jobs!

nanoscopic 12y ago
Yes; months of development time were wasted fighting with IT instead of being able to do our jobs. We weren't even allowed to use Git for several months, because it wasn't yet "approved." Even supposing we continued to use SVN, they were using an older version of SVN that was much slower and more inefficient. The software requisition process was also terrible. It took 4 months from when I started the job just to get basic software that that is typical for software development. Before that I was directed by my coworkers and superiors to use portable versions of the software I needed secretly.