Kohsuke Kawaguchi

I’m at San Francisco airport now to start my first around-the-world tour!

My first stop will be Tokyo, my home town. There’ll be a Jenkins user meet-up, whose 88 seats are booked solid. This time the topic is about various scripting languages, and I’ll be presenting about the recent Ruby/Jenkins work in the core with cowboyd. On Tuesday, I’ll be doing one of the keynotes in Japan Java User Group Cross-Community Conference. This is actually a full day event with 3 concurrent tracks, showing the degree of high interest in Java in Tokyo.

I have to make sure I won’t forget to attend the Jenkins project meeting in that night. It’s 1am my time. I think the technology made the distance a non-issue, but the time zone difference is really fragmenting our community (especially Asian communities from the rest of the world), and I with we could somehow fix that.

Then I’ll be heading to Paris, to present in the “What’s Next?” event by Zenika. While this is a for-pay conference, Zenika is also generously hosting a free Jenkins user meetup in Friday night. I’ll be also speaking there, along with a number of French Jenkins developers. If you are using Jenkins or thinking about using it, this is the opportunity to learn about a thing or two and get to know some of the people behind it. Then the following Saturday, we’ll shift the gear a bit and will be doing a hackathon. While the meetup is more for users of Jenkins, hackathon is more for the current and wanna-be developers of Jenkins and its plugins. It’s also a whole day event, so you’ll have more chance of really getting to know people. So if you are already plugin developers or thinking about writing one, please join us. On 5/30, I’lll be doing the last show in Paris, at SFEIR CloudCamp about Jenkins.

On 6/1, I’ll be heading to London and will be doing another talk in Skillsmatter in the evening. The next day, I’ll be doing a one-day training, and I believe some seats are still available. And with that, I’m back to San Francisco!

So please forgive me for any delay in responses to e-mails, and I hope to see as many of you on the road.

Uncategorized

I’ll be doing another Jenkins webinar titled “Mastering Jenkins Security” in the next Thursday 10am Pacific Time. It’s a free event, so please register.

After the first webinar, I got a number of feedbacks about the future webinar topics. So when we thought about doing the next one, this came fairly naturally. Unlike the first one, this time the idea is to pick one topic and go do some in-depth discussions. It’s harder to do in a conference, and so I think it’s better suited for webinars.

By default, no security is enabled in Jenkins, so in an environment where a stricter access control is more benefitial, an administrator needs to set this up to suit their needs, and there’s just a lot of different ways people want to configure it. So in this webinar, I’ll start by outlining the basic design of the security system in Jenkins — authentication and authorization — so that you can build a sufficient mental model of how it works, how they interact, and how it can be made to fit your needs.

We’ll then go through the major implementations of those two pluggability points, so that you can pick the right implementation for your needs. There are some plugins, like Active Directory plugin or OpenID plugin, that tightly integrates with respective systems that provide great integration experience. Then there are other plugins, like script security realm, which provides a general purpose mechanism that can be used to integrate Jenkins with arbitrary systems with little effort. Then there’s an entirely different approach of delegating authentication outside Jenkins to the front end reverse proxy. On the authorization side, there are lesser but still a number of options that you can choose from.

Aside from the authentication/authorization, I’ll discuss the security implications of running builds in Jenkins and other standard webapp security considerations, such as cross-site scripting problems, cross-site request forgery issues, and other attack vectors. I think it’d be useful for those who run Jenkins for a larger team.

So once again, please register if you are interested in attending, and if you have future topic suggestions, please let me know!

jenkins, Uncategorized cloudbees, jenkins, webinar

(This post was originally made under an incorrect location, so I’m moving it here. The contents haven’t changed since its original post on Jan 11th 2011.)

As some of you may know, toward the end of the last year, Hudson project has experienced a fire drill — you can see it here, here, here, and here. In short, the issue was that Oracle was asserting a trademark right to the project name “Hudson”, and that caused some considerable concerns to the community. Since then, key community members were talking with Oracle, in an attempt to produce some kind of proposal for a stable structure and arrangement, which was then going to be proposed to the Hudson community.

And as Andrew posted in hudson-labs.org, there is an update now — the negotiation didn’t work.

The central issue was that we couldn’t convince Oracle to put the trademark under a neutral party’s custody (such as Software Freedom Conservancy), to level the playing field. In a project where the community makes commits two order of magnitudes bigger than Oracle, we felt such an arrangement is necessary to ensure that meritocracy continues to function.

Aside from this, Oracle wanted a broader change to the way the Hudson project operates, including a far more formal change review process, architectures, 3rd party dependencies and their licenses, and so on. Those policies are worth discussing on their own, but it was very risky idea to have someone external to the project draw them up. Instead, in a normal OSS project, such processes would normally come out from the dev community itself, based on how it has been functioning. This is where I felt that the lack of “level playing field” I mentioned above is already affecting us. (And on that note, there’s another asymmetry about the CLAs, that we haven’t even touched on.)

All of those still might not have been a show-stopper if we felt that there is a genuine trust between us, but in this case, we just failed to build such a relationship, even after a month long conversation.

So in the end, we’d like to propose the community that we regrettably abandon the name “Hudson” and rename to “Jenkins” — it’s another English-sounding butler name that doesn’t collide with any software project as far as I can tell. This option was something we’d have liked to avoid, for all the obvious reasons, but I’m convinced that for a long-term health of the project, this is the only choice. It makes me sad at a personal level too, as I named this project Hudson back in 2004, and cherished it ever since. But the storm is gathering over the horizon, and the time to act is now.

The details of the proposal is again in the posting at Hudson Labs, so I won’t repeat it here. One thing I wanted to stress is that we’d like to move Jenkins under the umbrella of SFC, a neutral overlord that doesn’t concern itself with the daily technical matters of the project, just like how Sun was. That’s the model under which Hudson has grown, and I think it still fits us well.

There will be a poll running to get the broader community concensus. Please give us your support, and please let your voice be heard.

Uncategorized hudson

A seemingly innocent user report in the Hudson IRC channel turns into an interesting “discovery” (for me anyway) about JVM. Namely, if you got two threads initializing classes in the opposite order, you can get into a dead lock.

For this test, I wrote the following class. In this way, initialization of Foo results in the initialization of Bar:

package test;
public class Foo {
    static {
        try {
            System.out.println("Initializing Foo");
            Thread.sleep(3000);
            new Bar();
            System.out.println("Foo initialized");
        } catch (Exception e) {
            throw new Error(e);
        }
    }
}

I then wrote the Bar class that does the opposite:

package test;
public class Bar {
    static {
        try {
            System.out.println("Initializing Bar");
            Thread.sleep(3000);
            new Foo();
            System.out.println("Bar initialized");
        } catch (Exception e) {
            throw new Error(e);
        }
    }
}

Now, if you initialize them simultaneously from the opposite direction like this:

public class App {
    public static void main(String[] args) {
        new Thread() { public void run() { new Foo(); }
        }.start();
        new Thread() { public void run() { new Bar(); }
        }.start();
    }
}

And you’ll see that it deadlocks:

"Thread-1" prio=10 tid=0x0000000040696000 nid=0x2d6e in Object.wait() [0x00007ff087ce5000]
   java.lang.Thread.State: RUNNABLE
	at test.Bar.(Bar.java:11)
	at test.App$2.run(App.java:14)

"Thread-0" prio=10 tid=0x0000000040688000 nid=0x2d6d in Object.wait() [0x00007ff087de6000]
   java.lang.Thread.State: RUNNABLE
	at test.Foo.(Foo.java:11)
	at test.App$1.run(App.java:8)

Obviously, in production code, the path from initialization of class Foo to class Bar will be much longer, but you get the idea. I’m kind of surprised that this isn’t a real widespread problem in JavaEE. Developers don’t normally care about the class initialization, and on the server side you tend to have a lot of threads doing random things…

Uncategorized java

I’m happy to announce the beta release of InfraDNA’s Certified Hudson CI (ICHCI) Server. ICHCI is a value-added distribution of Hudson, and here’s why I think it’s useful:

• First, ICHCI is more stable sustaining release trains from Hudson; ICHCI is periodically branched off from a version of Hudson that was of particularly good quality. Its release cycle will be also much slower compared to the once-a-week cycle of Hudson. So it’s better suited for deployments where the stability is more important than rapid feature delivery.
• Second, ICHCI provides a better out of the box user experience. Hudson’s plugin community is so successful that nowadays it’s actually getting difficult to find the plugins you can really benefit from. I often talk to Hudson users who tell me about a particular itch, and I immediately go “yeah, there’s a plugin for that!” — ICHCI improves this situation by bundling and a number of tested open-source plugins together, making it less of a hassle to run Hudson.
• Third, ICHCI comes with commercial value-add plugins from InfraDNA. In this first beta release, for example, we put a plugin that automates regular automated backup of your configuration and build data. Going forward, ICHCI will be the primary vehicle in which we deliver value-add plugins from InfraDNA, and we have a lot of ideas about what we want to do!

60-day evaluation license for ICHCI is available to everyone. The full license is available as a part of the InfraDNA support subscription plans. Please try it out, and let us know what you think!

Uncategorized

For the longest time I haven’t really done anything about kohsuke.org, but as I left Sun/Oracle, I decided to put a bit more effort into it. So this is the new home.

For the time being, I plan to post my blogs both on java.net and here.

Uncategorized