Features & Enhancements

• Support for packages with checksums other than MD5. Spacewalk server and proxy can serve and accept rpms with SHA256 digests, show the checksums in webUI and accept them in API calls.
• Moved from mod_python to mod_wsgi on Fedora 11 and Fedora 12, which promises better performance.
• Improved performance of SSM and API.

Known Issues

• PostgreSQL support still does not work. We will need help with moving this forward.
• Provider GPG key is not sometimes recognized and packages shows up as unknown Provider.
• Documentation search does not work, other search are unaffected.
• Cobbler 2.0 is known to work, but full tests haven’t been done yet.

Congrats to (my old stomping ground) the Spacewalk team on the release.

Zeus pointed out that today marks the 1 year birthday of Spacewalk being announced. He mentions some of the technical accomplishments made during that time, but there are a few other aspects I find important:

• Like he mentions, there have been 5 releases in that time. Even though the code is derived from Satellite, that’s a really impressive turn around for a new project, both from a technical standpoint (getting the build structure in place, adjusting to the new tools involved in being open) and from a management standpoint (moving to a model of rapid releases from much slower production releases is a bit shift in thinking).
• The community is alive and kicking after just one year. It’s awesome to see users answering other users on the Spacewalk mailing list. The Freenode chat rooms (#spacewalk, #spacewalk-devel) are not just filled with Red Hat developers but rather users and other developers as well. We even have non-Red Hat contributors already.
• The team hasn’t imploded in the process. I wasn’t around for the majority of the initial work to release it as open, but I have watched the team migrate to an open model. It’s not as easy as just telling everyone one day to start talking in Freenode instead of the internal IRC server. There were also a number of decisions to make regarding how to manage the relationship between Spacewalk and Satellite that could have been a lot uglier if the team wasn’t so solid.
• There was a ton of activity and interest at the Spacewalk Campground at Red Hat Summit last year.

Check out more at Spacewalk wiki or come find us on Freenode at #spacewalk-devel.

I took a bug today that covers the error messages shown to a user when they input an invalid channel name. Currently, we simply say “Invalid channel name” without any indication of why… was it too short, did it contain invalid characters, was it already in use, etc. Our name validation is correct, but from a user experience stand point, it could use a little love (this was exacerbated by the multi-org addition where a channel name could be taken without you being able to see that data otherwise).

There are a number of different validations we run against the name. A good sampling of them is found in the following snippet:

1
2
3
4
5

if (cname == null || 
    !Pattern.compile(CHANNEL_NAME_REGEX).matcher(cname).find() ||
    cname.length() < 6) {
        throw new InvalidChannelNameException();
    }

Again, the logic is fine. Any of the circumstances in the if clause represent an invalid name. But now we have the need to carry more information to better indicate why it failed.

I started by editing the exception class itself. The constructor now accepts two parameters. The first is the channel name; if we’re saying the exception represents an invalid channel name then it makes sense it should indicate exactly what was invalid. This also saves the UI some work in remembering what was specified that caused the error.

The second is an enum (defined as an inner class of the exception class itself) that describes the reason for the failure. The enum (currently – I’m kinda writing this as I work on it) looks like the following:

1
2
3
4
5
6

public enum Reason {
    REGEX_FAILS,
    TOO_SHORT,
    IS_MISSING,
    NAME_IN_USE
}

I’m a big fan of the enum for something like this. It’s clunky to make subclasses of InvalidChannelNameException just to indicate the different possible reasons for failure, and frankly a series of instanceof checks to later use that information would just be ugly. A similar if/else structure would be needed if I used a series of String constants stored in the exception’s message attribute.

Some camps would argue against the inner enum (is that the way to say an enum defined as an inner class?). Their reasons would center around the usage syntax. I actually feel the opposite way; the syntax I have to use since it’s defined as an inner enum reads really well in my opinion:

1
2
3
4

if (cname == null) {
    throw new InvalidChannelNameException(cname,
        InvalidChannelNameException.Reason.IS_MISSING);
}

Also realize that using an enum lets IntelliJ only show me the enum values when I get to that parameter. There’s no need to hunt around for the possible constants.

Once the extra information was in there, it was just a matter of getting the UI to display a custom message based on what actually happened, cleanly using a switch statement since I’m using enums.

1
2
3
4
5
6
7
8
9
10
11
12

catch (InvalidChannelNameException ferengi) {
    switch (ferengi.getReason()) {
        case IS_MISSING:
            errors.add(ActionMessages.GLOBAL_MESSAGE,
              new ActionMessage("edit.channel.invalidchannelname.missing"));
            break;
 
        case REGEX_FAILS:
            errors.add(ActionMessages.GLOBAL_MESSAGE,
              new ActionMessage("edit.channel.invalidchannelname.regex"));
            break;
[snip]

Again, IntelliJ can auto-complete here, this time only showing the possible values (i.e. the enum values) each time I start a new case clause.

For the record (not that I imagine people will find this all that interesting), the Bugzilla bug can be found here and the Spacewalk commit here. I’m sure everyone is just racing to read those over now.

I’ll try to keep the setup short. We have a map of capabilities and the key is an architecture type (ArchType). The ArchType class, however, didn’t implement equals/hashCode. So when the map was queried by the architecture type, it used the object reference as the key comparison.

There are some more details I’m not going to fully explain. In short, they are all pulled from the database but the instances themselves are potentially cached. So on the first request to the map, the queried type and the the type inside of the map happened to be the same object, so it pulled the result successfully. On subsequent tries however, the caching ended up causing the two instances to be different (despite containing the same data). In those cases, the results came back as null and we saw a really weird, almost non-deterministic error.

The fix was simple, override equals/hashCode in ArchType to use the data (in this case, the id) rather than allow the default comparison by object reference. So no matter how many times we recreate the ArchType objects from the database, it won’t be a problem since the key lookup will use the data inside of the objects, not their references.

Overriding equals and hashCode. Learn it. Live it. Love it.

There are two important things to note in this release:

• Spacewalk now runs on Fedora 10. That’s great news, but now I have to finally stop putting off deciding on a cleaner solution for my home lab machines.
• Since I’ve been on the team for a while, this release has even more of my code in it. Anything I write is guaranteed to be 100% totally awesome and gives happy feelings and good karma to those who use it, making this the best Spacewalk release yet.

Apache Log Files:
/var/log/httpd/error_log
/var/log/httpd/ssl_error_log

Tomcat (Java application server)
/var/log/tomcat/catalina.out

Oracle… one would assume /var/log/oracle right? No, that’s too damn easy.
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/log/listener.log

Why Oracle, why…

Please note that with this release, Spacewalk 0.2 will no longer be available. If you are still using Spacewalk 0.2, please upgrade to Spacewalk 0.4.

Features & Enhancements

• Integration with Cobbler and Koan.
• Introduction of Organization Trusts and Channel sharing, known internally as Multi-Org II: The Sequel.
• Multi-arch enhancements to better work with multi-arch packages on 64-bit systems.
• A new set of APIs, including the following namespaces. See https://fedorahosted.org/spacewalk/wiki/ApiAdditions for a complete list of APIs.
  • channel.access.*
  • channel.org.*
  • package.*
• SELinux support added.
• Added the ability to search documentation, in Spacewalk we include a search index of the online docs.
• Updated the help page to include api docs and docs search.
• More perl to java migrations.
• satellite-httpd was removed in favor of using the standard httpd.
• Upgrades from 0.3 -> 0.4 available as well.

Bugs fixed

An outstanding 118 total bugs fixed since 0.3.

Known issues

• In order to take full advantage of the multi-arch feature, you’ll need:
  • updated client packages
  • recreate the stored profiles
• Bad news is that Spacewalk running on Fedora is not yet available. The good news is that we have started building packages to work with Fedora 10.
• bz480233 – deleting stored profiles causes ISE
• bz479640 – do not conflict with specspo. Work around is to rpm -e specspo.

Community

• A special thanks goes out to Colin Coe for his continued contributions to the apis. Also, thanks to Todd Sanders for his Telemetry contribution. https://hosted.fedoraproject.org/spacewalk/wiki/ContributorList.

Installation Help
https://hosted.fedoraproject.org/spacewalk/wiki/HowToInstall#Installation