Issues with Red Hat Enterprise Linux and ODBC

I've been recently interning at a major corporation. My intern project required me redesign an internal site which stores thousands of departmental documents. I obviously thought "store them in a database" because they weren't already and create the front end in HTML/PHP. This required me to contact the I.T. department and get a web server and a database setup . This corporation strictly uses SQL Server because of licensing. Even though I have more experience with MySQL, SQL statements only vary slightly. I.T. then informed me I had the choice of a virtual Linux (Red Hat Enterprise) server with Apache, or a virtual Windows server with IIS. I'm more familiar on how to configure Apache, so I went the Red Hat route. What a mistake.

The Problem(s)

  1. Repository bypass: Corporations like Red Hat Enterprise Linux due to the easy subscriptions manager. Essentially Red Hat handles all the packages and makes sure they are stable with the version associated with the package. This is sort of a hybrid of how updates are done on all major operating systems and how Linux typically handles things as it still checks for dependencies.

    The issue is I.T. removes this subscription information when the server goes live leaving it unable to install packages such as Apache (httpd), PHP (php55w-common), and PDO (php-pdo) all of which are needed to run a web server. To bypass this you need to install and/or enable another repository. To do this you run something like: # sudo rpm -Uvh

After this you can bypass the RHEL Subscription Manager and install the necessary packages:
# sudo yum install httpd

  1. ODBC Driver: There is currently no native SQL Server driver for unix, so instead ODBC drivers are used. Not only is this a hassle to install it also presents some technical issues and fundamental changes from my MySQL background. The PDO MySQL driver will handle multiple DB connections, called MARS (Multiple Active Result Sets), sort of like how Java handles memory; a kind of automatic management, it'll close unused connections. ODBC doesn't do this, each connection must be closed before another query can be executed using that connection. If this isn't done the query will fail with a cursor position error. Normally this is okay, it's just a matter of changing the programming logic or opening more connections. Simple enough except when you're using complicated nested while and foreach loops.

    Another issue is you're unable to use "=" after a "WHERE" in a query. You must use "LIKE" instead.

    For instance this will not work with the current Unix ODBC driver:

    SELECT * FROM table_name WHERE column1 = some_value;

    This will work:

    SELECT * FROM table_name WHERE column1 LIKE some_value;

    This will work also:

    UPDATE table_name SET column1 = value1 WHERE column2 LIKE some_value;

    Weird eh? Yeah I thought so too. I still don't understand why the change, but it's simple enough.

  2. SELinux: This is used to help secure the Linux server from malicious attacks, however, it also prevents the server from connecting to a database outside the server. To the uninitiated developer this is a hassle and will waste a lot of time trying to troubleshoot code thinking they did something wrong.

    To change this and make it persistent across system reboots you need to run this command: # sudo setsebool -P httpd_can_network_connect_db 1

I'm not a network security admin so I couldn't tell you why this is disabled by default, I just hope this will help others if they find themselves stuck in a similar situation.

These are just a few issues I've come across during my brief stint with RHEL and ODBC so far. I have no doubt there are more to come.