Andrew Male

Recent Posts

In the process of writing my posts (#1 and #2) on .NET Core and RHEL, it was made clear to me by several friends that I had neglected to use the de facto standard for continuous integration on Linux, Jenkins. Always happy to try out new (to me) tools, I settled in for what I was assured would be a simple configuration to test out my previous work in this bastion of automation.

What is Jenkins?

The first order of business was to understand the difference between Jenkins and TeamCity, another popular CI platform. After 20 minutes of reading, I discovered the following crucial differences:

Jenkins has been around longer (though not always under the Jenkins moniker).

Jenkins is open source.

There are many plugins for Jenkins.

Other than these three things, any noteworthy differences I found seemed to ultimately boil down to personal preference. Even so, with my research out of the way, it was off to the races!

The sheer number of tasks involved in building out automation infrastructure for a new organization never ceases to amaze me. One of the most often overlooked groups of tasks, however, is security. Though I am in no way a security expert, I know there are some basic steps we should take to protect ourselves and our precious systems.

I also know that not everyone who administers RHEL systems has an extensive background working with Linux. If, like me, you’re normally a Windows admin, yet you find yourself having to secure a RHEL system, fret not. Here are some tips for adapting what you already know about Windows security best practices to RHEL environments.

(Some of) The Basics

For our purposes here, I’m going to run through three things that I would do quickly on Windows and discuss their equivalent on RHEL. We’re in no danger of this becoming a comprehensive guide. As far as starting points go, it should be fair enough.

Service Bus is, according to Microsoft, “…a generic, cloud-based messaging system for connecting just about anything.” Most commonly used as an Azure service, it can be an excellent tool for managing non-critical workloads within an application and offers the benefit of being AMQP compatible when compared to Amazon’s SQS. Connecting to Service Bus (SB) on Windows is simple, but will the new .NET Core (DNX) platform be capable of the task?

Library Adventures

As of the writing of this post, Microsoft hasn’t yet released an updated version of its Azure Service Bus tools that is compatible with DNX. Thankfully, the AMQP compatibility makes it easy for libraries to be built that don’t depend on Microsoft.

After a bit of searching, I was able to find just such a library, AzureSBLite, by Paolo Patierno (who unsurprisingly appears to be a member of the RedHat organization on GitHub). The library doesn’t explicitly state it is compatible with DNX, but I figured I’d give it a shot regardless.

In my first .NET core post, I set out on a journey to conquer the new world of .NET Core (formerly DNX) on Red Hat Enterprise Linux (RHEL). In my ignorance I believed I would do a short post on firing up RHEL, installing .NET Core, and then converting an application from .NET to .NET Core before adding it as a build job to a new TeamCity instance. The best laid plans seem to be the ones that get me closest to throwing my computer out the window, and Part 1 stands as a comedy of my errors. With all of that sorted, however, it is time to finish the job and start working with .NET Core on RHEL. (RHEL is now available at no cost for developer use! You can download it here.)

The Goals (A Review)

Just to go over our goals one more time…

Create a functioning VM on my local machine with RHEL 7.2 and Windows Hyper-V

Despite spending plenty of time in Red Hat Linux while I was young, I have become an unabashed Windows environment super-user/programmer. Still, it’s hard to discount the multitude of ways that the *nix community stands ahead and alone, so when Microsoft and Red Hat announced their partnership to bring .NET to Linux, I had no choice but to take notice. As an experiment, I am going to go through setting up Red Hat Enterprise Linux (RHEL) and .NET Core to see if I can’t have a little fun and test the technology before it’s even at its first release.