Just a quick reminder, as much for myself as for my readers – Oracle has released Beehive 2.0.1, which I will be looking at in about two weeks, to see if it will be able to replace our current Collaboration Suite Calendar installation. Sadly, it still seems like Oracle insist that you must use their inferior email server to use the rest of the system.
The directory server we use at work is a Fedora Directory Server installation, running 4 nodes in a multi-master setup. We’ve been looking into migrating it to a Sun Java System Directory Server Enterprise Edition (sic) for a while, since I returned from the course in the US, but I haven’t had the time to get a proper test installation running yet. With Beehive 1.5.1 out, and given my enthusiasm for that, I decided to try and see if it would work with the Fedora Directory Server, even though it wasn’t supported.
I went with the template for synchronizing a Sun directory, as my sources had told me the two were very similar, in fact originally from the same source tree. The templates are pretty readable, but have manual handy for checking what some of the stuff means. One caveat: The attributes in the template are generally written like this:
<profile_name><enter profile name here></profile name>
What they expect you to write, is something like this:
<profile_name>Test profile</profile_name>
The extra angle brackets are just put there to confuse us 😉
My main concern at this point was that while I could define specific attribute values to mean external mail or not, it didn’t seem like this could be set merely by the presence of absence of attributes. I may have to re-think the directory structure slightly to address this.
When I added the profile using beectl, it turned out not to validate. Beehive was unable to find the directory server changelog. As it turns out, Beehive relies on an “old-fashioned” approach to synchronization between directory servers, and in fact one that can be enabled using a “Retro Changelog Plugin” for the Fedora Directory Server. So, if you’re on Google, trying to figure out how to make Beehive work with Fedora Directory Server: Use the Retro Changelog Plugin!
After setting this up, things seemed to just work. Now, there’s another little caveat: Beehive works with a concept of “principals”, that are your login credentials; In the default case your email for login and for instant messenging, and your phone number for voicemail. I changed the mail principal to be the user’s UID, but left them for IM and voicemail – meaning some users weren’t imported into Beehive, as it insists on the attributes used for this (mail and telephoneNumber) being unique in the directory. We have people who rightly have the same telephone number, for instance sharing an office, and Beehive doesn’t seem to like that. My idea of how to handle it: Make seperate attributes for voicemail-principals and instant messenging principals if you’re going to need those things, or disable them in the sync profile.
I would rather like for all our users to have an instant messenging principal that’s their UID @ some domain. I haven’t been able to find the option for it yet, and I’m not sure if it exists at all … if you know it doesn’t, and you’re a Beehive developer: Go fix this! 😉
Oracle released version 1.5.1 of their new-ish collaboration product, Beehive, on Friday. I’d been waiting for it ever since returning from the course in the US, and I was eager to try it out this morning. My setup was this:
I had preinstalled Database 11.1.0.6, as this was the latest recommended release for Beehive 1.4.3. The Enterprise Manager was set up with this. I hadn’t done any patching at all, since I just wanted to try it out from a clean install.
Not surprisingly, looking at the track record for Beehive, the first install with a vanilla database didn’t work. Some of the schema deployment failed, which was the same sort of error I got with 1.4.3 when I first tried installing that. Main problem: Oracle hadn’t released the documentation for 1.5.1 yet. I decided to try patching the database up in the same way required for 1.4.3, ie. with patches 6168363, 6708565, 6750049 and 6526468. At first, it seemed to do the trick – the installation worked way past the schema bits – but during the framework deployment, starting the beemgt service failed, and the installation stopped. Retrying the step didn’t seem to make any difference, and that’s where I left it at work.
Tonight, though, Oracle have released the documentation – linked above – with a few more interesting notes in it. There’s two more patches mentioned for 11.1.0.6, but those aren’t actually available to us regular users through Metalink. More importantly, Oracle seem to now support version 11.1.0.7 of the database, and from the Oracle Forums I understand that it’s actually the prefered version. You just have to apply a few patches – 12 to be exact, at the time of writing.
I’d better upgrade the database when I get back tomorrow. Check that all the table parameters are set correctly, install that dozen of patches, clear out the old Beehive database and set up a new one – and then see if that makes the install sail through. Somehow, I doubt it. Beehive is a nice product, but the installation and making all the bits fit together seems to hinge on having everything set up in exactly the way they have over in Redwood Shores – and maybe that’s just too much to ask for.
Update – 5 May 2009:
Clearing out the database didn’t make much of a difference. However, after trying that, I tried going over the client side, making sure it was absolutely pristine before I started – and again I checked the database, creating it exactly as was specified in the manual for 1.5.1. Et voila; suddenly I had a Beehive 1.5.1 installation. At least, it got a lot further – so long that I actually had to leave my office before it finished, so I won’t know the details until I get back tomorrow.
I happened to arrive rather early at the first day of the course, having gotten up very early due to a bit of jetlag. I’d met some of the other course participants in front of the hotel that morning, and we quickly got to talking about the course and our expectations. As it turned out, a large portion of the participants were from academia, either universities or in one case a research institution. There were a few people from real businesses as well – and over the course of the week, quite a few people from Oracle who were either in the course, or just popped in to say hi.
The location was a decent, not very conspicuous building on the edge of the Oracle campus – in fact, across a bridge over a small stream from the main Oracle campus. Free drinks and snacks were provided, which is always a nice bonus 😉
The course itself consisted of 20 lessons in all, ranging from architecture overview and installation tasks over how to use the system as an end-user, to system administrator tasks and backup. Most of the course lessons featured a practical exercise in addition to the traditional classroom slides and lecture-presentation. After going through the initial presentation of the course structure and the Beehive architecture, we proceeded to trying to install Beehive ourselves on our prebuilt OVM-machines. This turned out to be a bit more of a challenge than we had first expected.
The installation procedure for Oracle Beehive is quite simple – at least if you already have the database set up and preconfigured, which Oracle had kindly done for us. It’s a lot of clicking “next” and typing in well known information, such as your database server, and which system passwords you would like. You also have to decide on your “enterprise name” at this point, which seems to be a quite static and somewhat exposed parameter, so it’s probably something one would want to have thought about beforehand.
The actual installation process starts after these few windows of clicking “next” – and it’s quite a long procedure. Granted, we did run the databases and the Beehive instances on the same virtual machines – you might not want to do this, for several reasons – but it took about half a day. This would have been okay, if the installation had been just that – okay. But for a small number of the course participants, it didn’t go quite well – and for one, the one sitting next to me, it took several tries over the next days to get a working installation.
This experience of installations failing was not a new one for me – I had the same problem back in December, when I tried installing 1.4.1. We were running an internal 1.5.0 beta, though, and both the course lecturers as well as the visiting Oracle product managers ensured us that this was because we were running on low-spec uncertified Oracle Virtual Machines.
At first, the curriculum seemed very basic – the first chapters were installing the software itself and the management software, Beekeeper, which wasn’t very complicated. However, it quickly picked up on the second day, with in-depth coverage of areas like LDAP synchronisation and logging. We had a lot of material to get through, but the schedule was loose enough that we were allowed a full hour for lunch, frequent breaks and time to spare for when the several different product managers for parts of Beehive popped in to say hi.
A few of the lessons were not accompanied by practical exercises, in particular the Exchange coexistance part. While the theoretical coverage was good, anyone wishing to implement this should probably arrange for some hands-on practice in addition to this course before attempting. Most of the practical exercises were good, though they all had very explicit instructions, and didn’t require much on the part of the student to complete. Still, they allowed a good feel of how to work with Oracle Beehive.
In conclusion, I was very happy with the course, but in particular with the amount of contact with the product managers and developers – something that’s not likely to make it into the final curriculum 😉 Still, I wouldn’t hestitate to recommend this course to anyone, and I would also recommend taking a good look at Oracle Beehive when choosing your next collaboration software. More about the product itself in a later post.