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:
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:
- All machines are Dell SC1425 with a single 3GHz Xeon CPU
- Database server with 4G RAM, 250G disk for the database and some swap, and another disk for the OS
- Beehive server with 4G RAM and just a system disk
- Enterprise Manager server with 1G RAM: Don’t do this at home, it needs a lot more than 1G. Slooow.
I had preinstalled Database 18.104.22.168, 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 22.214.171.124, but those aren’t actually available to us regular users through Metalink. More importantly, Oracle seem to now support version 126.96.36.199 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.
A couple of weeks ago, one of my bosses came into my office with a curriculum description for a course on Oracle Beehive. He asked me to go it over, and tell me what I thought about it. After a quick flick through it, it seemed like a nice course to get some more information on the product, as it’s something we have been thinking about deploying. My boss asked me if I was available to go, March 9th through 13th. To California.
I left home at 3:00 on the 8th, where a nice friend of mine had agreed to look after my car for the week, meaning I could drive to the airport, and not have to get a bus there in the middle of the night. It turned out I was there rather too early, but early is better than late in these cases. So at just around 6:00, I was able to board an airplane for the very first time, for a quick hop to Amsterdam.
Yes, that’s right, I’d never flown before. And the flight didn’t start out too well, with what felt like rather a bumpy ride. The cabin crew seemed cheery enough, so at first I thought it was probably just normal, and wondered how I’d survive the trip across to the US – but then the captain turned on the fasten seatbelt sign, and mentioned that due to all the turbulence, he’d requested permission to fly a bit higher up. Phew! It turned out flying was a lot more comfortable than my first experience had shown, and we got to Amsterdam before time, at around 7:30.
Amsterdam airport, more correctly known as Schiphol, seemed like a nice place to be. It was certainly a lot nicer than Billund, and as I later found out, nicer than San Francisco Intl. After a couple of hours wandering about and using the wireless there (at â‚¬12/90 minutes) they finally let us board the plane – after a security check right at the gate, which seemed a very silly place to put it.
The plane for the second, much longer, half of my journey was a newly refurbished KLM MD-11. I was seated in economy, which didn’t bode well, but the plane was only about 2/3rds full, so almost noone had to sit directly next to anyone, meaning a bit more room to move about ones arms. The seats had screens in them, and once we’d gotten airborne and on the way, they were completely individual “entertainment systems”, capable of showing movies, episodes of tv-series, playing music, audio books or games, or following the in-flight tracking system.
I watched Quantum of Solace and WALL-E on the way, and enjoyed the food, snacks and drinks the very polite cabin crew were serving. The food wasn’t exactly excellent, but it was very decent, and we even got proper metal cutlery to eat it with. Sleeping wasn’t very easy, but I did manage to fall asleep for a couple of hours or so, before landing at San Francisco Intl. at about 14:25, only a short time after we’d taken off at 11:10. Okay okay, there was the small matter of the time difference on top, making it around 11 hours total … yawn.
The hotel, Sofitel San Francisco Bay, were nice enough to pick me up in their shuttle and save me the $30 cab ride, which was a nice touch. The hotel itself was very nice, and while my room wasn’t a lagoon-facing room, it still had an excellent eastward view of the sunrise over the mountains in the morning, and a by my standards huge King-size bed. Everything was nice and clean, and I even managed to unpack and hang my clothes before slipping into a more coma-like sleep.
When you have colleagues like mine, taking a photograph of the tiramisu before it was eaten isn’t a suggestion that’s likely to be accepted – so you will have to contend with a picture of what was left:
They did all enjoy it, and all my hard work yesterday wasn’t entirely wasted.
The amounts are for about 12 people, and they can probably be multiplied. You could probably halve it as well, but making much less than that is an affront to the recipe! 😉
- 8 dl espresso (or strong coffee)
- 2 dl amaretto or marsala – I like amaretto
- 500 grams lady fingers (savoiardi) (or more or less, depending on the tray you use)
- 200 grams sugar
- 8 egg yolks, pasteurised
- 8 egg whites, pasteurised
- 750 grams Mascarpone cheese
- Cocoa powder
I used 750 grams instead of the 1000 grams recommended in the book I adapted it from (Spise med Price, DR Forlag 2008). I liked the result, though some more of the cheese might be nice. It wouldn’t have fit in the tray I used anyway.
Brew the coffee, mix it with the amaretto and leave it to cool.
Mix the egg yolks, sugar and vanilla – I just added more to taste later – and whip until light and fluffy. This will take a while. Mix in the Mascarpone. Whip the egg whites and fold them in, to make the mixture lighter.
Pour the coffee mix in a flat-bottomed container, and dip the savoiardi sugar side up, so the mixture almost reaches the sugary bit – lift them up right away, and place sugar side down in the tray. Cover the entire bottom of the tray this way.
Cover with a layer of the egg-cheese mixture, about 1 to 1.5 cm thick. Use about half of the amount you have. Add another layer of savoiardi, and another layer of the mixture, making sure to level it out nicely.
Cover, for instance with aluminium foil, and refrigerate for at least 6 hours – I had mine in the fridge for 18 before serving.
Right before serving: Dust with cocoa powder – not the sugary stuff used for making drinks, but pure cocoa. Enough should be added that it looks like a dry layer on top of the tiramisu (in my opinion, anyway).
Probably stores well, but there’s not going to be much left anyway 😉
Depending on how long you dip the savoiardi, the tiramisu will taste more or less of coffee, and be more of less mushy. Finding the right balance can be a pleasurable job, as you need to make a new tiramisu each time 😉 There’s a bit of work in making a tiramisu, but it’s lots of fun, and it tastes great. It may not be too healthy to eat it all oneself, though.
Last week, I started working at my new job (which is the same as the old one, but full time) at DAIMI. At the same time, moving has been going on, and I’m almost done now, only really needing to bring along a few things to put in the store room, as well as my electric piano, which I’m going to bring today.
Working full time and moving as well has taken up almost all of my time, which is why I haven’t posted much here. I’ve started cooking a lot more, and I’m really enjoying having my own kitchen and a separate living room and bedroom. So expect some news about food in not too long.
PHP is taking up a lot of my time at work, I’m trying out Zend Studio which seems to be really nice, albeit quite expensive. I may have to try out PDT to see if it’ll do the same sort of things. More about this later as well.
Lastly, if you haven’t seen them yet, you should take a look at the photos I’ve taken of my new place: The first ones taken when I was about to move in, the next ones when I got my dining table and curtains in place, and the latest with my new sofa and sort of living room arrangement.
Today I emailed a number of our users, asking them to change their passwords. To be exact, I emailed 7462 users, which in itself is a bit of a logistical exercise, when you want each mail to be personalized.
Of them, we got some 250 or so bounces – that I saw, anyway, I was smart and redirected them to a colleague. This was quite expected, and will help us improve the data quality.
We also received, during the time that I was there, 75 or so mails from people who were confused, or had problems logging in. This over the course of about 2 hours. This was also expected, although some of the responses were a bit more over the top than I’d expected. People seem to not want to change their passwords.
I had the pleasure of handling some of the support requests, and I think I can happily say that they are mostly an issue of noone having used this system before. People didn’t know what their user name was (even though it was stated in the email), not did they know what password was to be changed. Still, apart from the 75 or so support requests I saw, more than 400 people have managed to change their passwords. All in all, I am quite satisfied at this first try – we knew it was going to be a hassle, and it’s proven us right. 😉 It will hopefully improve a lot when we send out the 2nd and 3rd rounds in a few weeks time, and be much, much better when we do it all over in February.
I started back at work yesterday, and I’ve gotten up to speed today and gotten a few things done. In particular, I have added some more intelligence to one of the web systems I work on, in order to avoid duplication of users. It’s the form for creating users I’ve been working on, and it now looks at the data you enter, compare it to the data already in the LDAP directory, and tries to guess if the user is already there.
I showed it to a colleague, having explained the nature of the script, and we agreed it looked okay. Then I showed it to my boss, who immediately mistook the functionality for a search engine – clearly unwanted behaviour! I will have to find a way to make it more obvious that it’s just trying to help you.
Now I think I’ll sit down for half an hour and practice on my piano.
I have now returned from work, ready for 3 weeks of summer holiday.
That is all.