One of the odd perks of working here involve occasional classes I can take for the price of what I charge an hour for my work.
I had an opportunity to take one of these classes today, titled "OS Vulnerabilities and Defenses". He simply asked for feedback after the class.
It went into a fair amount of detail, but structured in a way that a layman could grasp (point of fact: one of the people at the class was a salesperson who has no background in OS security or programming, and she had no trouble understanding the course). Considering the complexity of the subject (and its history), I found that impressive.
It also seemed more focused on Windows than anything else. Which, I guess, makes sense, all things considered.
This is different.
I'm packaging for debian. I never expected to find myself doing something quite like that in my professional career.
Doesn't seem that difficult, though, aside from the usual subtlties that arise in shell scripting.
yea, its rather easy.
getting the compile done properly... which one should be able to anyways... specifying sane dependencies...
the only thing a little bit complicated is the debconf stuff, if you want to ask setup questions to get the system configured.
Citadel has some of them, plus its a bit more complicated due to setup.
Well, fortunately, for what I'm doing, it's relatively easy.
Now bearing down on redhat. This doesn't seem too awful, either, but it has some weirdness because we have dependency problems related to our redhat builds.
Aaand... that's done.
Clean installs and uninstalls. Just like my days with WinINSTALL, 'cept on Linux. I can't seem to get away from installation.
Well hold on a second there, dothebart. You're thinking "packaging for Debian" as in pushing stuff into the official repositories. When you do that, you have the full force of the Debian ecosystem working in your favor, because you get all of the builds updated for every architecture automatically, and you don't have to worry about maintaining compatibility with several different versions of the system libraries.
I'm guessing that fleeb is now responsible for building .deb and .rpm packages that have to cleanly install on a variety of different target environments, and will be distributed by his organization rather than pushed into the main repos as source.
That's a tricky thing to do. It's doable but it's got a lot of challenges.
Fortunately, I don't have to package this for the known universe, just for our virtual machines. We deliver a series of virtual machines and their virtual network. The packages I deliver (internally) need to be capable of installing and uninstalling cleanly, though, so we can upgrade when we've added features or fixed problems.
If I had to account for different target environments, it would be much more awkward, assuredly, but probably no worse than Windows if we did the code correctly.
This said, the virtual machines to which I need to install our software do vary a bit in some ways. We have two different versions of RedHat and an Ubuntu install to consider, as well as a couple of different versions of Windows XP. All of this stuff is fairly old, because we are using old hacking tools to show the student how to exploit old versions of machines that responsible people have long since patched.
The point of the course is to teach people how hackers do what they do, to help give you the tools you need to avoid getting hacked yourself (or research what might be going on with your environment if you do get hacked). Not to teach people how to break into a competitor's environment and wreak havok.
no, I was aware that this is for internal use only.
but if you do it half baked you could also roll out tarballs - theres no advantage in using packages then (well maybe for apt-servers...)
We've been waiting on a Redhat license for a while, so we could distribute Redhat binaries instead of sources when we go to install this stuff on the customer's VMs. Unfortunately, we didn't get them in time, so it looks like I'll be installing them from compiled sources and deleting the sources when done. Not ideal, but better than not having the software at all.
I'm still rather new to this packaging stuff, but it looks like Linux is far less homogenized than Windows for that kind of thing. Which makes perfect sense, since there are different distributions of the OS.
I should have known this nice room at this job wouldn't last.
I'm being moved to a cubicle. I've never worked in a cubicle before. I anticipate getting less done.
Yeah, it's a tad noisier. I haven't used headphones for that purpose in the past, as I generally find them uncomfortable, but maybe I need to adjust.
I have something at home I could use here, I guess.
Or, maybe, I can get into a super-focused state and naturally ignore everyone around me. We'll see.
It wou, d really be nice if every once in a little while, one of my bosses would show a little gratitude.
We have 5 road going vehicles, and a couple of "shunters" which never leave the yard, but which need to be road worthy, and some how, during the last 3 years, the responsibility for the daily checks has devolved to me.
During this time there have been only minor issues with the vehicles, which have been duly reported, and dealt with. Until today
Today we had a breakdown, the cause is not something that the daily check would have found, in any event, but I ended up feeling like I'd let the team down.
I don't get any extra in my wage for the effort I've been putting in, and, to be fair, that is a non issue, I take a pride in keeping the vehicles healthy, but to have a conversation like that, about a vehicle that I wasn't even driving is a bit much.
I should just leave it to the drivers, after all, the real responsability for a vehicle belongs with the person driving it. My rig ain't broke, because I care about it. Do your own dailies. Idiots
Ugh... that's irritating, Lynda.
It also sounds like a failure of management, in general, to property maintain the vehicles.
Heh, well, sorta...