spot, looking suspect.

July 30, 2008

spot, looking suspect.

Originally uploaded by kernelslacker

This fellow appears to be tampering with something in a subbasement of a large building. If you happen to see him immediately call your local comic bookstore and warn them.

it’s like a cartoon

July 30, 2008

Remember Captain Planet on saturday morning cartoons? He and his weird gang of children stopped evil corporations from intentionally and with malice polluting and despoiling the planet. I always thought it was a bit hokey b/c I didn’t think people were that willfully malicious about polluting. I figured they were trying to make money and just being willfully ignorant of the problems they were causing. Not intentionally malicious.

And then you read something like this. And you think. Well, maybe they are being willfully malicious.

“… the suit accuses Chevron of responsibility for the dumping (allegedly conducted by Texaco, which Chevron bought in 2001) of billions of gallons of toxic oil wastes into the region’s rivers and streams.”

Yes, they dumped toxic oil wastes into the amazon. Apparently later they went out and roasted and ate a whole bushel of kittens to celebrate.

moblin moves to fedora

July 25, 2008

So, I’ve noticed a bunch of posts saying that they couldn’t believe that moblin’s reason for moving from ubuntu to fedora was the use of rpm vs deb. I’m a little surprised at that. Anyone who has built a deb package recently vs building an rpm package should see the obvious advantages. The learning curve for putting an rpm together is not nearly as steep as it is for debs. Not to mention the patching mechanism.

So, don’t be so surprised at the choice of  distros due to the packaging format.

Having said that, I think the ‘always upstream’ mantra that we’ve been chanting in fedora for a while is a pretty good draw. Moblin as a downstream consumer of fedora knows that if they pitch things back to us they’ll likely go up the tree to the right people.

Hi folks,

$ email aliases now work. The aliases map to anyone on the notify list for a package.

Yay for new/more spam! 🙂

belated yum anniversary

July 23, 2008

Worthy of note. A little over a month ago marked the 6 year anniversary of yum having code checked into an scm (at that time cvs).

That’s a long time to take abuse. 🙂

I blame jeremy.

Let’s say I have a bunch of admins working on a bunch of systems. I know they try hard to make sure that anything they change on a machine to fix a problem is also put into our config mgmt system but I also know that at 3am you can’t always remember to do that. So, I want to be able to make sure we know if things have changed. Something like this:

import yum
my = yum.YumBase()
for pkg in my.rpmdb:
    ver_results = pkg.verify()
    for file_that_does_not_match in ver_results.keys():
        if not check_against_config_mgmt(thishost, file_that_does_not_match):
            notify_admin_about_modification(thishost, file_that_does_not_match, pkg)

The functions that don’t exist are the check_against_config_mgmt() and notify_admin_about_modification() functions. The parts preceding those all exist in current yum versions.

Anyone think they can take that up and find a way of checking if puppet knows about the changes that have been made? If you do, yell at me and I’ll help.


July 21, 2008

Saturday morning – midnight – watched the ending to dr. horrible. The ending, while a bit sad and dark was still fantastic. Consistent with what Whedon has done on many other occasions and as one commenter on wrote: “This is an origin story” which gives it more sense. Thoroughly enjoyed the musical and while I’d be happy to see more of them, b/c they’re fantastically funny, I’m fine with the ending we got out of it.

Saturday afternoon it was hot and kinda miserable outside so I went to one of the coffeeshops nearby and I wrote some more on some docs I’ve been working on. They’re shaping up reasonably nicely. Mostly they’re docs to fill in the spaces on some of the things yum/createrepo/yum-utils can do and to help explain things about how and why to manager repos and systems in certain ways. If you want to see more you can look in the yum-docs git repo.

Saturday evening went out in the torrentially pouring rain for the habitat for humanity full moon ride. The last time I did this ride it was wet and spitting rain and completely covered in clouds. This time it was raining like piss from a boot when I started out and visibility was, umm, poor. It would have been better if I hadn’t forgotten my bag when I left and had to turn around on my way there come back and get it. But the thing to remember is this: Once you decide you’re okay being soaked all the way through on every layer, it really does get easier. It was just an enormous amount of water, after all. 🙂

It ended up drying off and clearing away which was good, we actually got to see the moon, which was nice for a change. I kinda wish they hadn’t made us stop every 3 miles or so, that got a bit old.

Sunday was slow day. Coffee shop, crosswords, made pancakes with the girl, sat and read things, talked about cellphones for a while, then later we made completely kickass food for dinner. Seriously, good stuff. These are some of our Sunday dinners. It’s nice to have the kitchen back and sane.

That was most of my weekend.

Dr. Horrible

Act II – 7:18s

’nuff said.

dear rhythmbox

July 18, 2008

I realize that random can mean ‘random’. I also realize that in some people’s books listening to Billy Joel makes me a type of criminal. However, I think ‘Uptown Girl’ 3 times in a row is just kinda wrong. huh?

I’ve been pointed to this paper a number of times in the last week and I wanted to comment on it briefly.

Specifically this page as a concern. Here’s where I’m confused. If your pkg manager finds unsigned or invalidly-signed repository metadata then what? Does it bail out and throw up an alert? Does it just continue using the last validly-signed metadata it has?

In either of those cases unless the user is noting/monitoring for errors/alerts and/or doing the update manually then they’ll never know that they didn’t get their updates. Heck, we’ve found that despite outputting a message like ‘OH MY GOD THIS DIDN’T WORK, YOU SHOULD CHECK IT’ that users don’t understand what they mean and/or don’t see them.

The only actual way to avoid being vulnerable to any/all of these problems is to verify that what you want to have updated/installed on your systems is what IS on your systems.

It’s like saving a file in a text editor. Sure, you’re confident that your save command saved the file but anyone who has ever worked on something important has pressed ‘save’ then taken the file it saved it to, opened it in another window or on another machine to verify that it did, in fact, save, before you close the window you were working in.

Securing a system should be approached with the same behavior. If you’re worried that your system is not updating, then verify that it is. Better yet, setup monitoring to verify this for you and occasionally check your monitoring out.