Tuesday, February 08, 2011

GNOME Activity Journal + OpenOffice 3.3

It's been far too long coming, but after some pestering on #zeitgeist(sorry guys :) ), I have gotten the Activity Journal working for our users. Multiple users and documents being on NFS always makes these things more interesting, but I got it working well enough to push to testers.

Right now it's only showing documents created with OpenOffice via .recently-used.xbel; but this is the piece that helps us the most. Because we have a multi-server environment, there is separate instances of this file on different computers. I need to tinker with combining them together either over NFS or with some kind of merging process. That project is on the back burner though.

Here is the journal running from our NAS server. .recently-used.xbel is copied over from the OpenOffice server, loaded into $HOME , daemons started and the GUI launched. I'm sure I'll make improvements to the design as it's tested. So beagle is now bound to Windows+F5, and Journal is bound to Windows+F6. Documents searches have never been easier for our users.

Speaking of OpenOffice, I upgraded us to 3.3 this morning. It was the usual process: Close all running instances, block them from running it in the script, run the upgrade, QA that it worked and then open the one script to our 800 employees. So far no major issues and they are starting to test the new features.

Up next: Two days of debugging and testing Evolution. There are some problems and I want to create proper bug reports.

Friday, February 04, 2011

Beagle Returns

I mentioned that a week ago we installed a new NAS server to hold all of our documents. Now that a few tuning projects are over, I had some time to restore the functionality of having Beagle available for users to search their documents. We continue to use Beagle because it offers the ability to build the databases in a manner suited for multiple users, and multiple departments. You can tell it to create a database of all documents in the IT directory, and then grant permissions for only IT staff to see those files. Each individual user in IT doesn't then have to crawl and find the documents; it's only done once.

Beagle had changed a bit since the old 32bit server was deployed, so I had to check out some new backends and command line arguments. In looking at the old code and clunky UI, I decided to try a new approach to make it easier. This only took a short period of time, it's simply some new bling on top of the old infrastructure.

The old beagle-search UI had their available sources (folders) in a drop down menu along the top that they could toggle on and off. Users rarely found them and didn't know what they were selecting. Since all employees have access to three folders, I made a quick glade/python UI to connect them to the right document databases. The shot below shows the current design for testing. I added this UI to metacity/Windows+F5 so that it can be opened with a simple keystroke. UI pops up and you tell it if you want to search your personal documents, your departmental documents or citywide documents and then beagle-search comes up pointed to that static database. Simple, easy and stable.

Now all I have to do is install our standard MIME document bars on this server and the project is complete.

PS: Looks like Beagle-search really needs some new artwork, pretty fuzzy icon.

Wednesday, February 02, 2011

OpenOffice/Oracle Help, Firefox, OpenFire

Some experimental work has been done to start checking on how well OpenOffice can connect to the Oracle database. The database is outside of my division, so I'm hoping someone just knows how to solve this issue:

We can connect to Oracle cleanly using the jar file driver and everything works. However, for some reason it's displaying what looks like system tables along with the tables we desire. Has anyone experimented with this connectivity and resolved this issue? It seems odd to me that this is being exposed over ODBC.

New Browser Server

After going live on 64bit Firefox we had a few days with some brownouts and issues that required some changes and tuning. Two things seemed to have corrected the problems and it's running very well now. The original deployment used a NFS directory to be the area to hold temporary files instead of /tmp. This worked fine until a certain number of people and combination of plugins and then the disk io started to bottleneck. With 600 users that can access the Internet, there are thousands of sites they visit each day and it's hard to simulate that during beta testing. I moved the temporary storage back to /tmp and then only copied files to NFS when they were needed by external applications. I stumbled on "iotop" which is a beautiful piece of software. Those of us that used SCO Unix back in the day were always spoiled with "iohog" which performed a similar function.

We also had tuned Firefox with some custom tweaks available on the Internet to increase performance. These too worked in beta testing and under smaller loads, but it looks like when we got over a certain number of concurrent users it flooded the Barracuda, firewalls and eventually the Internet circuit with too many requests at once. When these settings were de-tuned things worked better. Even without them, response time is excellent.

So we have settled in around 80-100 concurrent users in Firefox and here is the load:

The City has "cyber cafes" set up in various places to allow employees to get on the Internet. This was done so that non-work related sites could be visited on breaks and eliminate this being done at their desks. I pointed the thin clients to the new server and have created a point release to our internal build with this feature. I'm testing it this very second and it will go live tomorrow. At that point nearly all services are disabled on the old server and we can begin the process of putting it into retirement.

We use OpenFire for Jabber on our internal instant messenger network. I brought over this software from the old server to discover that it was crashing on 64bit Linux. By default it runs its own included Java, which is only 32bit. All I had to do was modify the openfire rc.d file and add a line to point it to JAVA_HOME. It then ran the 64bit version and is working perfectly. Another item off my list.

Projects on the horizon for me: Upgrading to OpenOffice 3.3 (next week), working with Vincent and Hans on some GNOME issues, getting avant-window-navigator recompiled with all of the latest features, watching for updates to NX 4 to allow us to log into the servers with an iPad.