IT Outsourcing Is a Bad Move

The Long Road HomeThe whole idea of outsourcing is to cut cost while staying competitive.  This is especially true with offshore outsourcing, where labor is cheap.  I suppose there are a lot of reasons to blame the domestic American labor force, such as the worker’s union, high standard of living, or high medical and legal costs.  While this might be true for blue collar jobs,  outsourcing the ones that require more specialized skills (like Information Technology) doesn’t make sense.

American IT workers are specialized and skilled workers.  They’re smart and creative people.  They’re also hard working.  They are extremely loyal if the companies treat them right.

But is all that worth sacrificing for the sake of cutting expenses?

Let’s take an example an offshore IT worker being paid $20/hour.  He does a good job.  Problem is, he’s now a hot commodity, so he won’t work for less anymore.  He’ll move on to the highest bidder.

So, let’s hire another offshore IT worker being paid $20/hour.  Now, the company has to waste time while he’s learning the ropes (or “ramping up”).  It’ll cost additional money in delayed projects, missed deadlines, high stress, and low morale.  Does he even have the same quality as the first one?

If yes, then we’re back to the guy looking for greener pastures.

If no, then we’re in a sink hole.  A company then needs to hire another candidate (or two) to help complete  the project.

Offshore turnover rate for IT workers is bad.  It also applies to non-IT workers.

Some companies have thought about offshoring to other countries with “emerging” skilled workers, such as China and Vietnam.  But those places are not any better, since China and Vietnam lack in communication skills, mainly with English language.

They’re also not up-to-date with technology due to export controls and lack of relevant education.  They’re trying to catch up with educating recent graduates with emerging technologies.  But it might be too late.  The market is being flooded with new graduates in the same field.  Also, now the job market in a slump due to the worldwide recession.

So what’s the best move now?

Stay home. In-source.  On-shore.

Nowadays, a lot of people are out of work, and they include skilled IT workers.  This is a great time to hire them at a competitive rate — possibly even cut rate!  Local IT workers are willing to work, and ready for the long term commitment.   Companies just need to step up and keep America working again!

Photo Credit: Tobi 2008

Setting Up Apache Web Server With Secure HTTP

Incorporating the use of Secure Socket Layer (SSL) library is straight forward with Apache web server.  This is the library I always use for all of my Apache web servers installations.  From one robust open source software to another, they’re a perfect fit.  They make deployment quick and easy.  Here’s are the steps for Apache HTTP and OpenSSL:

Compilation

Assuming the OpenSSL installation in /usr/local/ssl, the Apache web server source code compilation will require the configure option:

–enable-ssl –with-ssl=/usr/local/ssl

I use the following:

./configure –prefix=/usr/local/apache2 -enable-ssl –with-ssl=/usr/local/ssl

Then just run:

make install

On Unix platforms like Solaris and Linux, the configure and compilation should work without a hitch.

Configuration

Go to the configuration directory and edit the httpd.conf file (in my example /usr/local/apache2/conf) and uncomment this line:

include conf/extra/httpd-ssl.conf

Then proceed to the /usr/local/apache2/conf/extra directory and edit the httpd-ssl.conf:

  1. Specify the machine’s IP address to “listen” on port 443.  Specifying an IP address is useful if the machine has multi-homed (multiple IPs configured).
  2. Ensure the Signed SSL Certificate is on this machine.  Store it in /usr/local/apache2/conf/www.website.com.cert pathname.  It can be anywhere that’s accessible from the web server level.
  3. The SSL key for the host needs to be available also, and stored in the same /usr/local/apache2/conf directory.
  4. For the <VirtualHost> tags, edit the _default_ with the IP address, and may look something like this:

<VirtualHost IPAddressNum:443>

ServerName www.website.com

SSLEngine On

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLCertificateFile “/usr/local/apache2/conf/www.website.com.cert”
SSLCertificateKeyFile “/usr/local/apache2/conf/www.website.com.key”

<FilesMatch “\.(cgi|shtml|phtml|php)$”>
SSLOptions +StdEnvVars
</FilesMatch>

<Directory “/usr/local/apache2/cgi-bin”>
SSLOptions +StdEnvVars
</Directory>

BrowserMatch “.*MSIE.*” \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

CustomLog “/usr/local/apache2/logs/ssl_request_log” “%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”

</VirtualHost>

References

Further options and settings for SSL are available from the Apache.org site:

Creating SSL Certificates for Secure HTTP

ssl_padlockThe use of Secure HTTP (or HTTPS) is essential to avoid getting my browser communication hijacked, or hacked.  For savvy web users, browsing a site with HTTPS is a must to protect login and other private information.  As a Web Application administrator, the way to accomplish this is to use the Secure Socket Layer (SSL) library in combination with an Apache web server.

The widely used SSL library is by OpenSSL.  It’s constantly updated, and it’s freely available.  I use it because it also compiles well on Linux and Solaris operating systems.   The source code is portable and has been tested in many flavors of Unix.  Windows install is available also.  Compiling the source code is as straight forward as running the “configure” script and run “make”.  The default install for OpenSSL is usually in /usr/local/ssl directory.

Once installed, the first step is to create a Key Pair:

/usr/local/ssl/bin/openssl genrsa -des3 -rand <anyfile1>:<anyfile2>:<anyfile3> -out www.website.com.key 1024

  • The anyfile1, anyfile2, or anyfile3 can be any file in the system.  There has to be at least one file specified.
  • Specifying a pass phrase is required in this case.  But for convenience, I might opt to do it without specifying a password.  To disable the password prompt, remove the “-des3” option.

Next create a Certificate Signing Request:

/usr/local/ssl/bin/openssl req -new -sha256 -key www.website.com.key -out www.website.com.csr

Fill in the requested information.  At the end of the questionnaire, a “challenge password” is usually not required.

Updated September 10, 2014: Due to SHA-1 weakness, it’s imperative to let the intermediate cert provider generate a cert without SHA-1 encryption.  Hence the -sha256 option when generating the CSR.

Submit the CSR to a CA such as Thawte or Verisign.  After payment is processed, they will send an email with directions how to get the certificate file.  It might require cut and paste of the cert code into a file, usually with  a .crt or .cert suffix (such as www.website.com.crt).

For development or QA environments, where a valid signed certificate is not required, I can create a self-signing one.  To create a “fake” (aka Snake Oil) certificate, use the following:

/usr/local/ssl/bin/openssl x509 -req -days 999 -in www.website.com.csr -signkey www.website.com.key -out www.website.com.cert

Both the cert and key files are required for the web server.  I’ll cover Apache web server installation in the next post.