All posts by Jamie Duncan

Red Hatter and chronic tinkerer

SELinux talk at RVaLUG – 20140419

This morning I gave what was a pretty well-received talk about SELinux. We got into the important definitions and pretty down deep into how type enforcement works. Lots of practical examples and fun stuff.

Of course why spend hours coming up with a new slide deck when you can borrow from amazing work done by co-workers. :)

The slide deck I used was a slightly modified deck used (last I know of) for a Red Hat TAM Webinar last April.  It also came with a set of lab questions that we didn’t have time to go through today.

And of course, there is the SELinux Coloring Book.

The talk was long for a LUG meeting (right around 90 minutes plus a little follow-up), but the interaction was great and I think we had some good communication going.

20140419-jduncan-selinux_workshop-lab_redux

20140419-jduncan-selinux_workshop_redux

getting crafty with my hospital stay

Healthcare and Insurance – My Snapshot

Last May I got sick. Like for real sick; for the first time in my life. I had what was apparently a massive blood clot that was impeding the functioning of both of my lungs. The official term is a ‘bi-cameral (sp?) pulmonary embolism’. In reality it meant that if I walked 50 feet I would pass out, have what looked like a seizure and start throwing up all over myself in the emergency room while my wife is screaming. I still owe that security guard a firm handshake and a bottle of his drink of choice. I liken it to getting hit by lightning. It came out of nowhere and laid me completely low in the span of 2 hours. There was no discernible warning and a root cause was never determined.

getting crafty with my hospital stay
getting crafty with my hospital stay

Last October I was tapped by my company to help work on healthcare.gov. You might have heard of it. The initial launch didn’t go so well. But it made a pretty strong comeback here recently. It even managed to make some of the major news outlets.

BizJournal.com
Slashdot
ZDNet
Business Insider
CBS News
Yahoo
Bloomberg
CNN

Today I logged into my insurance company’s website to get some information, and I started looking at the claims filed for me in the past year year out of morbid curiosity. This would cover the time I was actually in the hospital, the 6 months of follow ups, and the maintenance for a condition I’d known about for a while but didn’t start addressing until I got sick (sleep apnea).

In the past 365 days, my insurance has been billed $47,752.13.
In the past 365 days, I have owed $768.09 for those billings.

My insurance has covered 98.4% of my medical bills in the past year.

The lessons I’ve learned today:

  1. If I didn’t have health insurance I would be bankrupt.
  2. I’ve never felt more contempt for people fighting insurance and healthcare reform in the United States
  3. If you don’t have health insurance, I am truly fearful for you on multiple levels
  4. I’ve never been more proud to have contributed professionally to something than the work I did during the last quarter of 2013 with the people working on healthcare.gov

kpatch – my kneejerk reaction

Oracle gobbled up a company called KSplice 50 ITYA (IT Years Ago – or July 2011). They then shoe-horned it into their downstream clone of RHEL so people could slip in kernel upgrades without rebooting systems sort of like how magicians yank table cloths out from under dishes on a table. It’s scary on any number of levels.

Now there is a new-ish project called kpatch that has the backing of Red Hat (full disclosure – I work for Shadowman). I’ve only had a little time to look at the incomplete documentation on how it works. That said, it looks to be a huge step forward over ksplice. From it’s Red Hat Blog announcement:

With respect to granularity, kpatch works at the function level; put simply, old functions are replaced with new ones.  It has four main components:

  • kpatch-build: a collection of tools which convert a source diff patch to a hot patch module. They work by compiling the kernel both with and without the source patch, comparing the binaries, and generating a hot patch module which includes new binary versions of the functions to be replaced.
  • hot patch module: a kernel module (.ko file) which includes the replacement functions and metadata about the original functions.
  • kpatch core module: a kernel module (.ko file) which provides an interface for the hot patch modules to register new functions for replacement.  It uses the kernel ftrace subsystem to hook into the original function’s mcount call instruction, so that a call to the original function is redirected to the replacement function.
  • kpatch utility: a command-line tool which allows a user to manage a collection of hot patch modules.  One or more hot patch modules may be configured to load at boot time, so that a system can remain patched even after a reboot into the same version of the kernel.

That’s way cooler than just doing some fancy RAM voodoo and slipping new kernels in like ksplice.

But I still don’t see where it has a place on a company’s production server or in their security plans.

I believe that if a system cannot sustain the reboot of a single instance of Linux (physical or virtual) then there is a serious flaw in its architecture. To further that I think something like kpatch could end up being a strong crutch to bad architects out there; allowing them to  keep working in this flawed manner.

I know that my crazy idealism doesn’t represent the current reality everywhere (or almost anywhere). But if this is the only justification for its existence then I think we could have and should be using our cycles better somewhere else.

More details as I discover them.