Factotum: Documentation Handyman

Why get bored with exporting/importing your calendar? From daBrain:

Export and Import is an easy way to get your Mac iCal up to date. But doing it manually is boring, therefor I thought it would be nice to have this scripted ...My result so far now is a small shell script which export your calendar from the Calendar Server, save it as export.ics and open iCal with the exported.ics file, you only have to click OK for the import.

Sun Microsystems working on CalDAV support for Symbian OS.

As the Calendar Server 7 docs state:

(you can)...set up Calendar Server 7 (CalDAV Server) in an existing Calendar Server 6 deployment, where calendar users exist on both the Calendar Server 7 and Calendar Server 6 environments. In such a deployment, you enable both freebusy lookup and iCalendar Transport-Independent Interoperability Protocol (iTIP) invitation between the two Calendar Server deployments. That is, users should have the capability to check freebusy information of users on any server, and the capability to invite any user. Invitations to users on a different server would be delivered by using iTIP.

Now, Andreas has some more info on this setup, here.

(Photo Credit: muhammad younas)

Interesting write-up by one of our TSC engineers, who just completed a Comms 7 Installation. Focus of the writeup is on our new product, Calendar Server 7.

Note: The single host deployment example (for SPARC), referenced in the above blog entry, is not yet publicly available. There is, however, this document for Red Hat Linux, that is available.

Hat Tip DougG

It might not be widely known at this point, but Sun has been a leader in the CalDAV community, and our investments are about to pay off with the upcoming shipment of Calendar Server 7, included in the Communications Suite 7 release.

Sun is firmly committed to making CalDAV our calendaring protocol of choice. Sun has been very active in the CalConnect community to make sure that our CalDAV service interacts with other vendors and their services. Project Aries has been the name of Sun's CalDAV effort, and for the past year, we've enabled customers to get a taste of our technology through a hosted preview.

Why the need anyways for a CalDAV server?

The challenge in the calendaring space has always been about getting everyone to agree on a standard protocol that enables data to be exchanged between a calendar client and a calendar server, regardless of vendor. To date, we've been using the iCalendar data format for calendar and task data, as specified in RFC 2445. The good news has been that Sun and others have used this common data format. The bad news with this approach has been that, lacking a standard protocol, you end up using one big file to store all your calendar events. Reading calendar info may be fine, but making changes is not. Because your calendar database is essentially one big flat file, the only way a change can be made is for the client to upload a new version of a user's entire calendar data file and overwrite the copy on the server. That's a lot of data to move, for example, when all you have to do is push out a meeting change of one hour. The situation worsens if multiple users want to update a calendar. The last user to overwrite the copy on the server wins and changes other people have made are lost.

Having a real calendar access protocol would solve these problems and provide other nice features, such as calendar sharing, change logs, and free/busy lookups. The first attempt at such a protocol came in 1999 with the creation of the Calendar Access Protocol (CAP). WCAP, or Web Calendar Access Protocol, is an implementation of CAP over HTTP. Sun Java System Calendar Server 6.3 uses this protocol. Unfortunately, timing is everything. When the dot-com bubble burst, work on WCAP fizzled out. The result: Vendors went back to using their proprietary protocols.

Luckily, the situation did not remain the same. Though it took awhile, a new idea emerged to extend the WebDAV protocol to provide calendar specific support. The result was CalDAV and is documented in RFC 4791.

Of course, having an open protocol buys you nothing if vendors do not implement it in popular products. That is a big reason why CAP didn't take off. Fortunately, CalDAV seems to have gained enough momentum to stick around, as envinced by the CalConnect industry consortium, whose charter is to make sure CalDAV implementations work together and are widely adopted.

Yes, calendaring "nirvana" might still be a long way off, but we are getting closer with Calendar Server 7.

For more information on Calendar Server 7, see the following pages:

• Introduction to Calendar Server 7
• Calendar Server 6 and Calendar Server 7 Comparison and Coexistence
• Calendar Server 7 What's New
• Complete list of Calendar Server 7 documentation

The Calendar Server cscapture utility collects all parts of Sun Java System Calendar Server environment that are useful for debugging, such as log files, database, host environment, config and more. It will also gather core files and debugger data for core analysis.

An updated version of cscapture (1.1) is now available with the following changes:

• Detects just the current version of the Calendar Server and not the original version that was initially installed prior to upgrading. The previous way of detecting the version was not ideal and was confusing when reading the summary file.
• Handles relative path names so it won't include the absolute path in the cscapture tar file. Running ./cscapture /var/crash will not longer cause /var/crash/cscapture-xxx to be present in the tar file. Instead the file path will be relative for more easier untar'ing of the data.
• Includes the system messages files from /var/adm in the cscapture archive.
• Uses the version 3 of the pkgapp script. This has been included with cscapture v1.1 for recommended use.

  Get the updated cscapture utility here: http://www.sun.com/bigadmin/scripts/sunScripts/SUN-GDD_calendar_cscapture.tar.gz

Check out Project Aries.

Project Aries is the code-name for Sun's advanced calendar server based on CalDAV. As standards-based calendar usage increases, the ability to share calendars and support multiple calendar clients becomes increasingly important. Aries satisfies this need by introducing a standards-based calendar server that supports Apple iCal, Mozilla Lightning, and other standards-based clients. Project Aries is a key component of Sun Java Communications Suite. This Hosted Preview provides you the opportunity to view and test drive this new calendar server. While not all functionality is implemented yet, we want to share this exciting new product with you for your review and feedback.

A new Calendar Server 6 patch was made available this week on SunSolve. Patch IDs are:

• Solaris OS: 121657-28
• Solaris x86: 121658-28
• Linux: 121659-28

This is the first patch since -25, when the l10n requirements were unified. If you use non-english l10n patches, you now no longer need them. However, be sure to read the README before installing this patch.

And, if you are patching a Calendar Server deployment on Solaris x86, you must read the README before upgrading for a required procedure. This procedure is required only for x86 deployments. If you are running Calendar Server on SPARC OS or Linux, you do not need to follow this procedure. You need only perform this procedure one time. Following is the applicable text from the README:

CR 6642958 - Bad data representation with 121658-19 patch in x86
version of 6.3 calendar server (x86 ONLY)
----------------------------------------------------------------------------------------------------------
With 121658-20 and later, calendar server uses new berkeley db library
which is incompatible with the db created by earlier versions. In
order to use the DB created by 121658-19 (or prior) with this patch,
the data needs to be updated by following the below procedure.

1> Make sure the calendar installation is 121658-19 or prior.
2> Take a copy of the current DB
3> Check to make sure the DB is in good condition by running db_verify
and csdb check
4> Dump the data using db_dump
	Set LD_LIBRARY_PATH to /SUNWics5/cal/lib
	eg: ./db_dump -r -f /var/opt/SUNWics5/dump/ics50alarms.db.txt
/var/opt/SUNWics5/csdb/ics50alarms.db
	Do the same for all the DBs.
5> Apply this patch (121658-24 or later)
6> Load the data dumped in the above step to the DB files using the
cs_dbload provided in this patch.
	Set LD_LIBRARY_PATH to /SUNWics5/cal/lib
	Run cs_dbload to load files dumped in step <4>
	eg: ./cs_dbload -f /var/opt/SUNWics5/dump/ics50alarms.db.txt
/var/opt/SUNWics5/dbload/ics50alarms.db
	Do the same for all the DBs
7> Run csdb check or csdb rebuild on the db files created in the above step.

We just posted a new technical article on how to install, configure, and verify Cloudmark Anti-Abuse Client (CAAC) with Sun Java System Messaging Server.

The component products covered by this technical article are:

• Sun Java System Messaging Server 6.3 and Sun Java System Messaging Server 6 2005Q4
• Cloudmark Anti-Abuse Client (CAAC) 1.3.1.4

Get the article.

Need to know what attributes Calendar Server requires in Directory Server for an end user? The following sample for a newly created user using the commadmin user create command to create a mail/calendar user should get you there. (Hat tip Deb)

# cd /opt/SUNWcomm/bin
# ./commadmin user create -D admin -w password -F New -l nuser -L User \
-n lab.example.com -p 80 -W password -X construction.lab.example.com -S \
mail,cal -E nuser@lab.example.com -H construction.lab.example.com

# cd /opt/SUNWdsee/dsee6/bin/
# ./ldapsearch -D "cn=directory manager" -w password -b o=isp uid=nuser
version: 1
dn: uid=nuser,ou=People,o=lab.example.com,o=isp
icsFirstDay: 2
userPassword: {SSHA}RMn5bkqZRlLOI03vnmutikGAcvRgVdlvk2lGfQ==
uid: nuser
iplanet-am-modifiable-by: cn=Top-level Admin Role,o=isp
icsTimezone: America/Denver
givenName: New
mail: nuser@lab.example.com
mailUserStatus: active
sn: User
cn: New User
mailDeliveryOption: mailbox
icsStatus: Active
icsCalendar: nuser@lab.example.com
mailDeferProcessing: No
mailHost: construction.lab.example.com
objectClass: userpresenceprofile
objectClass: icscalendaruser
objectClass: top
objectClass: iplanet-am-managed-person
objectClass: iplanet-am-user-service
objectClass: organizationalperson
objectClass: inetadmin
objectClass: person
objectClass: sunamauthaccountlockout
objectClass: inetuser
objectClass: inetlocalmailrecipient
objectClass: iplanetpreferences
objectClass: ipuser
objectClass: inetorgperson
objectClass: inetsubscriber
objectClass: inetmailuser
inetUserStatus: Active

Notes:

• The icsFirstDay and icsTimeZone attributes are not absolutely required and will be created when a user first logs in. However, the others are required and if using DWP, setting icsDWPHost to the Calendar backend host may be necessary (though this should also get set upon first login).
• Also, creating users using the above commands, make sure the domain is also enabled for mail and calendar, for example:

  # ./commadmin domain modify -D admin -w password -X construction.lab.example.com -n \
  lab.example.com -p 80 -d lab.example.com -S mail,cal -H construction.lab.example.com
  

  So the domain entry in LDAP looks like:

  dn: o=lab.example.com,o=isp
  o: lab.example.com
  objectClass: inetdomainauthinfo
  objectClass: sunismanagedorganization
  objectClass: top
  objectClass: sunnamespace
  objectClass: sundelegatedorganization
  objectClass: sunmanagedorganization
  objectClass: maildomain
  objectClass: icscalendardomain
  objectClass: organization
  objectClass: nsManagedDomain
  mailAccessProxyPreAuth: no
  icsTimezone: America/Denver
  sunRegisteredServiceName: DomainMailService
  sunRegisteredServiceName: GroupMailService
  sunRegisteredServiceName: GroupCalendarService
  sunRegisteredServiceName: UserMailService
  sunRegisteredServiceName: iPlanetAMAuthService
  sunRegisteredServiceName: UserCalendarService
  sunRegisteredServiceName: iPlanetAMAuthLDAPService
  sunRegisteredServiceName: DomainCalendarService
  sunNameSpaceUniqueAttrs: uid
  mailDomainStatus: active
  preferredMailHost: construction.lab.example.com
  nsNumUsers: 1
  icsStatus: active
  icsExtendedDomainPrefs: domainaccess=@@d^a^lsfrwd^g;anonymous^a^r^g;@^a^s^g
  icsExtendedDomainPrefs: calmasterUid=calmaster
  sunPreferredDomain: lab.example.com
  inetDomainStatus: active
  sunOrgType: full
  sunNumUsers: 18
  

Someone was asking recently about Calendar Server best practices information on one of the support aliases. So I went searching the Calendar Server documentation, and discovered this best practice tip:

Note –

Duplicate parameters are allowed in the ics.conf file. The system takes the value of the last instance of the parameter in the file.

Best Practices: To avoid confusion, add your customizations to the end of the file in a section you create for that purpose. For example, you can create a comment line with the following text: ! My ics.conf Changes. Then add any new parameters or any parameters that you are modifying, and their values. Add comments to each parameter describing why the change was made and add the current date. This will give you a history of the changes made to the system for later reference.

If you make extensive customizations, to improve processing efficiency, you might consider commenting out the original parameter that you are replacing. Also, periodically review the file, commenting out obsolete duplicate parameters.

Other BP tips that folks suggested include:

Take nightly backups then run csdb check on the backup DP, to capture any DB corruption.

Implement the Calendar Server automatic backup facility.

These were just a few tips that came up. Have a Calendar Server best practice? Feel free to add to this entry by posting in the Comments.

Our internal Sun Java System Calendar Server hosts (yes, we do use our own products) recently went through an upgrade, but alas, an error was encountered where email reminders were not getting sent out. As a Calendar Server end user, I was left to my own devices to discover this: and along the way, I found out just how much I've come to depend on this seemingly trivial technology to help drive my corporate life. Yes, I need those email reminders about upcoming meetings and events!

Now, granted this was a fairly trivial post-upgrade situation, and our IT folks quickly remedied the situation. Nevertheless, for all those who have had an upgrade bite you in the ***, I feel your pain.

Wouldn't it be great to have a Mr. Fixit handy, when problems on your server arise? (Just kidding, I know today's software is a wee bit more complicated than say your in-house plumbing.)

Well, the next best thing for Calendar Server issues anyways might just be the cscapture utility, developed by the folks at the Sun GDD project. Compared to its predescesor capture_environment, cscapture can collect alot more information, including:

• All Calendar Server configuration files
• Calendar logs
• Calendar database
• Core files, pstack's, and pmap's
• Execute multiple gcores on hung or spinning processes
• Gather pkg_app data for core analysis
• General host information with performance and resource statistics
• Provides a summary overview of server setup and problems

The cscapture utility is available from BigAdmin here:

http://www.sun.com/bigadmin/scripts/indexSjs.html

For more information on the Sun Gathering Debug Data program, check it out here:

http://www.sun.com/service/gdd/index.xml

Note:The cscapture utility is only currently available for Solaris OS; for other OSs, continue to use the capture_environment utility.

Jhawk is showing how to use Swing to develop a new client for Sun Java System Calendar Server. Check it out.

Lightning brings the Sunbird calendar to the popular email client, Mozilla Thunderbird. Since it's an extension, Lightning is tightly integrated with Thunderbird, allowing it to easily perform email-related calendaring tasks.

A new release of Lightning, 0.5, was recently made available. If you're a Lightning user, you should check it out.

The latest public build is at:

http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.5rc2/lightning-wcap/

Calendar Server users should get the WCAP build. WCAP is Sun's calendar access protocol that is publicly documented if you wanted to write your own tools to access the data.

The plugin developers also have a calendar blog that's worth checking out:

http://weblogs.mozillazine.org/calendar/

You'll find additional instructions at:

http://wiki.mozilla.org/Calendar:WCAP_Guide