(Originally published by MC Press Online in November 2015).

“Put on your big boy pants!”, they told me.  

“Dig deeper and figure stuff out for yourself!”, they said.

Based on the feedback I was getting from online forums I realized I needed to step up my game in my first open source ventures.  Those were some tough days for my RPG programmer brain, but I stuck with it.  Now I see the advantages of going through many mud puddles.  

Today, I’m striving to wear “big boy” pants.  Through this article, I’m actually hoping to give you some fabric, a pants pattern, some pins, as well as a sewing machine and teach you how to make pants. You can determine whether to put them on.  Ok, ok…enough with the metaphors!

As an aside, I grew up with five sisters.  My mom taught sewing lessons. So…I know how to sew and have even tried to make shoes out of fleece (I bet my mom never stopped me because she couldn’t stop laughing).  It was a good thing I learned early that sewing shouldn’t be an occupational pursuit.  Now my sister Ahmelie on the other hand did much better on the sewing front.  Check out www.ahmelie.com.

So what are these pants I talk of?  Well, I was going to write an article about how easy it was to install the popular Nginx web server on IBM i.  However, it turns out open source had something else in mind.  It wasn’t easy, but I figured it out.  I want to teach you the “how” of getting Nginx installed and working on IBM i in manual fashion.  It’s kind of like that “give a man a fish, teach a man to fish” saying.

Before I go on, it would be good to back up a bit and describe Nginx.  Nginx is an HTTP web server and is used in similar scenarios to Apache.  It has been rising in popularity over the past few years and is a common choice for fronting Ruby, Node.js, and other open source stacks.  Why Nginx when we have Apache on IBM i?  Well, DigitalOcean has a good Apache vs. Nginx comparison that you can read to learn more about the differences as I won’t be focusing on that here.  Instead, I will document the motions I went through to get it working on my machine.

In article Installing Git on IBM i, I showed how to use an open source shell script named wwwperzl.sh to install Git on IBM i.  My plan was to use the same process for installing Nginx but I hit a snag.  The snag was when it attempted to run line 304  wwwperzl.sh for the Nginx RPM, as shown below.

Side note: RPM (RPM Package Manager) is a popular utility for installing software on Unix-like systems.  Think of it as being similar to a *SAVF for moving software around from one machine to the next.  Although, it’s really much more.

When that line ran it only showed the following in my PASE shell with no indication of successful installation.

The first step I take in debugging something like this is to break it into small chunks.  In this case I put together the exact rpm command to run manually, as shown below.  Note I am running this from a PASE shell which you can get to via CALL QP2TERM or SSH into your machine.

Not remembering what each option does, I went to Google and searched for “rpm linux command” and came to the “man page” (manual/documentation) for the rpm command.  From there I see that -v can be added to create a more verbose output so I add that to the rpm command and ran it again.

The D: denotes debugging and gives us an idea of all the directories and files slated for creation.  After the command ran I looked in the IFS to see if program nginx existed using the following command.  I knew to look there based on the debug output declaring that was one of the locations for Nginx files.

Hmm… not found.  So the install is still unsuccessful and I have no idea why.  Although, I do see it hung on D: running preinstall script (if any).  I go back to the rpm documentation and see I can add a second “v” to get even more debugging information.  I run the following command again with more v’s.  At this point I also dug deeper into some of the rpm options and decided to remove –nodeps (no dependency check) to see what effect that might have.

Bingo.  I see some useful information; in particular the lines that say unsatisfied and error: failed dependencies at the bottom.  The first one, AIX-rpm >= is needed by nginx-1.9.4-1, I don’t expect to resolve because we aren’t on AIX, though PASE is essentially AIX.  The –ignoreos and –ignorearch are in the command for this reason.  Moving on I see sh and ksh are expected to exist.  These are programs for the Bourne Shell and Korn Shell, respectively.  I run the which command to determine whether they exist and their location.

As you can see they do in fact exist and are available to my current shell session (aka IBM i job) but are located in /QOpenSys instead of /bin.  Listing the contents of /bin I see it is in fact a symbolic link to /QOpenSys/usr/bin, as shown below.  Symbolic links are like alias or shortcut files in Windows – basically a way to link to a file or directory from a different directory.

At this point I chalk the sh and ksh problems up as a red herring and move to error libc.a(shr.o) is needed by nginx-1.9.4-1.  File libc.a is an “archive” file that is similar in nature to an RPG *SRVPGM – a way to hold many different modules in single file or object.  Files with names starting in lib… are often located in /QOpenSys/usr/lib.   Using the ls command we can see it does in fact exist.

Ok, so libc.a does exist and for some reason the rpm install process couldn’t find it.  The LIBPATH environment variable can be used to explicitly declare where libraries (of the C variety) can be searched for.  So, I set it to look in the directory where I found libc.a, as shown below.

I tried the rpm install again and received the same error.  At this point I am not convinced that libc.a is a red herring but need to keep trying things.  Going back to the original debugging info I remember the D: running preinstall script (if any) error. That leads me to look at the rpm command to determine if I can bypass the preinstall script.  Sure enough, a couple google searches lead me to add the –noscripts option to the rpm install, as shown below.

Victory!  This time I see what I expect with the nginx ####… output.  Now to check whether the nginx program is available at the location specified in earlier debugging output.

Victory again!

Next I use the which command to see if it finds the nginx program without me having to specify the fully qualified path of /opt/freeware/sbin.

Bummer.  Let’s see if the nginx program can display its version to confirm it works at a minimal level.

Back on the winning path!

My assumption at this point is some setup, like symbolic link creation, has been lost because I specified –noscripts.  I can deal with that later.  For now I am curious to know whether I can create an Nginx HTTP server with a simple configuration.  Below is my nginx.conf file that is as bare-bones as possible.  

/home/aaron/nginx.conf contents:

As you can see from the above nginx.conf we need to create an index.html file.  Below you can see my simple example.

/home/aaron/index.html contents:

Now we are ready to start the Nginx web server.  By default the nginx program will look for the nginx.conf file in /etc/nginx so we need to review the command line options to learn how to override the default.  The Nginx docs say to add the -c option along with the path to the config file.  Note the tilde (~) character signifies, and is a shortcut to, my home directory (i.e. /home/aaron).

Now launch a browser and point it at your machine and the port specified in nginx.conf, as shown below.


Back on the winning path!  

You’ll notice that when you run the nginx program it doesn’t tie up your session.  This is sometimes the case with other tooling.  Instead it starts itself as a daemon which is similar to submitting a job to batch.  At this point we could use the 5250 NETSTAT command to see that Nginx is listening on port 8080.

To end the web server we again visit the Nginx command line options and learn about the signal (-s) option and apply it as shown below.

At this point we’ve successfully installed, and have running, the Nginx web server on IBM i.  In the past on other machines I didn’t have these same issues.  This could be a configuration issue or maybe I’ve hosed something on my machine.  Regardless, you’ve now learned a little more on how to debug these types of problems – a necessary skill to have as your shop adopts open source.

I’m curious.

Do you (the reader) like these types of articles where I walk through more painful approaches to open source on IBM i?  Would you prefer the nicely wrapped and packaged “here are the two commands you need to install Nginx on IBM i”?  Or maybe both serve a purpose for you.

Comment and let me know or reach me directly at abartell@krengeltech.com.