Wednesday, June 18, 2014

Setting up Windows 2012 Jenkins slave : Part 2

This is the second update on my experiences setting up a Windows 2012 Jenkins slave, where other Jenkins instances have been Unix based.

Let me just say that Jenkins isn't as easy to setup on Windows. You probably already knew that.

As an overview, this is the high-level way we write and build code and what is needed for continuous integration:

1) Java 7 and 8
2) Eclipse or IntelliJ for writing code and running tests outside the command line or Jenkins
3) Maven 3x
4) GIT 1.8.4 on Mac, GIT (msysgit 1.9.2) on Windows
5) Jenkins master running on Linux.
6) Jenkins slave agent running as a slave app on Windows
7) Cygwin for windows

Further problems encountered setting up Jenkins on Windows 2012, besides what I detailed in prior post.

1) SH scripts for running tests need to run on Windows
2) Access denied issues when running certain files (e.g BAT)
3) CreateProcess from Jenkins cannot find files to run

The first issue above is that we use SH scripts (in Bash) to setup testing and run our tests after all other packages are built. Windows won't recognize SH scripts as runnable. I decided that since I had Cygwin installed with Bash I could launch these SH scripts from within a BAT file.

The BAT file is basically one line:

C:\cygwin64\bin\bash.exe --login "C:\jenkins\workspace\...\"

I originally had it start with bash, but the process couldn't be found when done through Jenkins, since it was launched through CreateProcess. I solved my 3rd issue above by fully qualifying what process I wanted to kick off under cygwin with the full path of where bash lived, and I was done with my BAT script.

The 2nd issue above was seen in build failures inside of Jenkins runs where I would see access denied. I thought I could change permissions in the POM files where these scripts were launched but that didn't work.

Ultimately, I found that access denied with my scripts was caused by Eclipse. Eclipse wouldn't make some of the new files I created executable. I clicked on properties and updated the scripts to make them fully executable, and had no further issues.

Thursday, June 12, 2014

Reverse SSH tunneling to get around corporate intranet port blocking

Have a port that is blocked between two servers you use? Let's say you use ports above 1024, for example, in the 8000-9000 range for web applications or some other proprietary application you write.

Let's also say you have a Linux instance you SSH to that needs to connect back to you own laptop or another Linux machine, but the port on your local machine cannot be accessed from the remote Linux box unless you have IT open that port, which means bugging them with a ticket.

Here's something I learned the other day.

In my scenario I needed to connect to a web application, running on my local Mac Book Pro, using port 9999 when I was connected via VPN, from a Linux Openstack instance.

Unfortunately, I couldn't connect to the port with a simple program like curl since the port was blocked.

Here are the steps so I could allow SSH to serve up that port from the remote Linux instance back to my Mac.

Detailed Steps:

You need two terminal windows on the machine you need to connect back to. I had two tabs open in the Terminal window on my Mac.

1st terminal window:

     Change this string to what port you need to open >

     ssh -R 9999:localhost:9999 -l [root or whoever you connect as]@[the virtual server you connect to]

     If you don't want to use localhost, replace with server name you want to connect back to.

     You will now be on the remote linux box

2nd terminal window:

     ssh [root or whoever you connect as]@[the virtual server you connect to]

     You will now be on the remote linux box in the 2nd terminal window.

     Try using curl to test the port that you want to connect back to >

     curl https://localhost:9999//index.html --insecure

          Again, replace localhost with whatever server name you'd like to use to connect back to.