This chapter describes how to use the Calendar Server utilities to manage users and resources. This chapter contains the following sections:
Calendar users and resources can be administered using one of the following user management tools:
Delegated Administrator Console
Use this GUI to provision users and resources in LDAP for Calendar Server. For information on using the GUI, see the Delegated Administrator Console online help.
Delegated Administrator Utility (commadmin)
Use these tools to provision users and resources in LDAP for Calendar Server . For detailed instructions, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.
Delegated Administrator does not manage calendars. To create calendars for users and resources, use the Calendar Server utilities.
Calendar Server utilities (csuser and csresource)
Use these utilities to manage calendars. In addition, use them for user and resource management if your configuration meets all of the following criteria:
You are not using Access Manager.
You have an earlier version of Calendar Server or Messaging Server installed using Sun LDAP Schema 1
You plan to continue using Schema 1.
See also the command-line utility reference in this guide, Appendix D, Calendar Server Command-Line Utilities Reference.
In certain cases, even if you are using Schema 2 and Delegated Administrator, you will need to use some of the Calendar Server command-line utilities to perform special functions. When this is necessary, task oriented documentation in this guide will tell you which utility to use.
This section provides the following information about managing new Calendar Server users and resources:
You can use either the Delegated Administrator Console or Utility:
Delegated Administrator Console
In the Delegated Administrator Console, use the Create New User wizard. (Click New in the User List page for the organization where the user is to reside.) For more information, see the Delegated Administrator Console online help.
Delegated Administrator Utility
Use the commadmin utility user create command. For example, to add user jdoe in the sesta.com domain:
commadmin user create -D calmaster -F John -n sesta.com -k hosted -l jdoe -w calmasterpassword -W jdoepassword -L Doe -S cal -B red.sesta.com -E jdoe@sesta.com
For details on all the available options for the commadmin utility, refer to the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide
Use the csuser utility. For example, to add user jdoe in the sesta.com domain:
csuser -m jdoe@sesta.com -d sesta.com create jdoe
You can use either the Delegated Administrator Console or Utility:
Delegated Administrator Console
In the Delegated Administrator Console, use the Create New Resource wizard. (Click New in the Calendar Resources tab for the organization where the resource is to reside.) For more information, see the Delegated Administrator Console online help.
Delegated Administrator Utility
User the commadmin utility rescource create command to create an LDAP entry. For example, to add the conference room Conference_Room_100, use the following command:
commadmin resource create -D calmaster -w calmasterpassword -n sesta.com -c room100 -N Conference_Room_100
You must then use csresource to create the actual resource calendar. For information on how to create a resource calendar, see Creating Calendars
For details on all the available options for the commadmin utility, refer to the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide
Use the csresource utility to create both the LDAP entry and the resource calendar. For example, to add a projector, p101, use the following command:
csresource -m p101@siroe.com -c p101 create Projector_101
For more information on csresource, see the csresource.
Calendar Server requires users and resources to have the mail attribute, which contains the email address of the user or resource. This enables people to search for calendars and resources using an email address or a calid. When you create new users with Delegated Administrator, it adds the mail attribute automatically. This happens even if the user has not been assigned mail service.
Calendar Server does not support email notifications for resource calendars.
Adding the mail attribute does not enable email notifications for user calendars.
To enable email notification for user calendars, add the following two attributes to the user’s LDAP entry:
icsExtendedUserPrefs:ceNotifyEnable=1 icsExtendedUserPrefs:ceNotifyEmail=jdoe@sesta.com
If your users and resources were added in an earlier version of Calendar Server (when the mail attribute was not required), you might have to add the mail attribute to your existing user and resource LDAP entries.
This section covers the following topics:
To check if the attribute has been set, use the csattribute list command with the -v (verbose) option:
csattribute -v list Room100
The output tells if the mail attribute is present:
cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com has mail: Room100@sesta.com
To add the mail attribute to existing users and resources, use one of the following methods:
Use the Calendar Server csattribute utility.
The following example adds the LDAP mail attribute for an existing conference room named Room100 on the sesta.com server:
csattribute -a mail=Room100@sesta.com add Room100
Use ldapmodify to add the attribute directly to the LDAP entry.
After your users are created, use the csuser utility to perform the following administrative tasks:
To list all calendar users or to display the calendar attributes of a specified user, use the csuser utility list command.
For example, to display all users enabled for calendaring:
csuser list
To display all of the calendar attributes of a single user such as jsmith:
csuser -v list jsmith
The purpose of disabling a user is to prevent the user from logging into Calendar Server. This is handled differently depending on which user management tool you used to create the user. Users created in the Delegated Administrator Console should be administered using it also. Likewise, if you assigned calendar service to the user with Delegated Administrator Utility, use it to remove the service. And finally, users in a non-hosted domain environment should be administered using only the Calendar Server Utilities. Each handles the situation a bit differently.
This section contains the following topics:
Calendar Server Utilities (csuser disable) (Calendar Server utilities)
In the Delegated Administrator Console, select the user from the User List page. In the Properties for this user, delete the service package with calendar service in it. This disables the user for calendar, including setting the user's icsStatus to inactive.
If the package also contains other services, you will have to reassign those services using another package that does not contain calendar.
To prevent a user from accessing calendar services, remove the service from the user’s LDAP entry, as shown in the example that follows:
commadmin user delete jsmith -S cal
This disables the user for calendar without completely removing the LDAP entry. In addition, this command changes the user's icsStatus to inactive.
The disable command prohibits a user from accessing calendar data, but it does not remove the user’s information from the LDAP entry or the Calendar Server database. This command changes the icsStatus attribute from active to inactive. In non-hosted domain mode, there is no such thing as a calendar service.
For example, to disable jsmith from accessing Calendar Server:
csuser disable jsmith
If jsmith is currently logged into Calendar Server, jsmith retains access to calendar data until he logs off.
To enable a user, use one of the following tools:
Delegated Administrator (commadmin user create)(for Schema 2)
Calendar Server Utilities (csuser enable) (for Schema 1).
You can add enable both a new user and an existing user:
New user — When the user is created, using the New User wizard, assign the user a service package that includes calendar service. The user is automatically enabled.
Existing user — Select the user from the User List page and use the Assign Service Package wizard to select a service package with calendar service. The user is automatically enabled.
When creating a user, enable the user for calendar services, as illustrated in the example that follows:
commadmin user create jsmith -S cal
If you did not enable the user for calendar services when the user was created, you can add calendar services to the user later, using a modify command, as illustrated in the following example:
commadmin user modify jsmith -S cal
If you used csuser create when you created the user entry, the user is automatically enabled.
If a user sends a request to another user who has not been enabled for calendaring (that is, the user does not have a default calendar), Calendar Server returns the “Calendar not found” error to the user sending the request.
If you need to setup email aliases for a calendar user, add the mailalternateaddress attribute to the user's LDAP entry. The mail attribute provides the primary mail address, and the mailalternateaddress attribute is used for email aliases. Both attributes map the mail addresses to the user’s calendar ID (calid).
You can add the attribute using the Calendar Server Utility csattribute, or by directly updating LDAP with ldapmodify. The following example uses csattribute.
To enable these changes, you might also need to rebuild alias tables or configurations. Refer to the documentation for Messaging Server (or your email product) as well as your site's own documentation and procedures regarding changes to mail services. Messaging Server documentation is available on this at: http://docs.sun.com/coll/1312.1.
For example, to add the mailalternateaddress attribute for a user named John Smith with these values:
User ID (uid) and calid: johnsmith
password: password for John Smith
Email address: john.smith@sesta.com
Email aliases: johns@sesta.com and jsmith@sesta.com
csattribute -a mailalternateaddress=johns@sesta.com add johnsmith csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith
To determine if a specific user exists in your directory server and is enabled to access Calendar Server data, use the csuser utility check command.
For example, to check if jsmith is enabled for calendaring:
csuser check jsmith
If the check command indicates that a user does not exist in your LDAP directory server, you must create a directory server entry for the user.
Use different tools depending on whether you are deleting a user from a hosted domain or a non-hosted domain:
There is no undelete command.
Once users in hosted domains are deleted using Delegated Administrator, they must be purged and re-added from scratch. The user name can not be reused until the purge happens.
For non-hosted domains, see For Non-Hosted Domains Only: Undeleting Users Marked for Deletion but Not Purged.
You can mark users for deletion with either Delegated Administrator interface. However you can not purge users from LDAP with Delegated Administrator Console. You must use the Delegated Administrator Utility for that. The following task lists the steps for deleting a user from LDAP. The user is not actually removed from LDAP until the last step is complete.
Mark a user entry for deletion.
For Delegated Administrator Console: Select the users to delete in the User List page and click Delete.
For Delegated Administrator Utility: Use the commadmin user delete command. For example:
commadmin user delete -D chris -n siroe.com -w bolton -l jsmith
In both cases the icsStatus attribute in the user LDAP entry is changed from active to deleted.
Use the Calendar Server Utility csclean to remove all calendars belonging to all deleted users in one or all domains, as shown in the following example:
csclean clean “*”
Or to remove calendars belonging to all deleted users in one domain, specify the actual domain, as shown in the following example: csclean clean sesta.com
If you inadvertently purge the users from LDAP before deleting the users' calendars, you can remove them later using the cscal utility, as described in Managing User Calendars.
Purge the domain of all users marked for deletion, using Delegated Administrator Utility command commadmin domain purge.
For example:
commadmin domain purge -D chris -d sesta.com -n siroe.com -w bolton
In this example, all users in sesta.com that are marked as deleted will be purged, that is, permanently removed.
Run this utility manually from time to time to clean up your LDAP directory. For more information about this command, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.
To remove the specified user’s LDAP entry and the user’s default calendar, use the Calendar Server utility csuser with the delete command.
For example, to delete the LDAP entry and the default calendar for user jsmith use the following command:
csuser delete jsmith
If you wish to remove the other calendars belonging to this user, you must use cscal as described in Managing User Calendars.
For a non-hosted domain, to undelete users marked for deletion but not yet purged, it is necessary to reset the users' icsStatus attributes to active. You can achieve this by directly changing the LDAP entries (using ldapmodify), or by using the Calendar Server Utility csattribute.
However, in a non-hosted domain, once the user is purged, you can only recover the LDAP server information by restoring it from a backup.
To restore the default settings of all calendar LDAP attributes for a specific user, use the csuser utility reset command.
For example, to reset all calendar attributes of jsmith to the default configuration settings:
csuser reset jsmith
After a calendar user has been reset, all of the calendar attributes are removed from the user’s LDAP entry, including icsCalendarUser (object class), icsSubscribed, icsCalendarOwned, icsCalendar, and icsDWPHost (if in the LDAP CLD setup). A Calendar Server administrator will not be able to create calendars on the user’s behalf.
These attributes are restored in the user’s LDAP entry when:
The user logs back into Calendar Server, or
The Calendar Server administrator issues a csuser enable command for the user (although in this case, the icsDWPHost attribute is not restored).
If one or more user ID's need to be changed, run the csrename utility. This utility performs the following steps:
Converts the user ID's in the Calendar Server LDAP attributes (the ones with the ics prefix). The LDAP directory is updated in place.
Renames the users in events and tasks on the Calendar Server database files. It writes the new database to a destination directory. Existing database files are not modified.
Be aware that changing even one user ID causes the whole database to be rewritten. So this is a “costly” utility to run.
For instructions on how to run the csrename utility, see Appendix D, Calendar Server Command-Line Utilities Reference.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the following ics.conf parameter as shown in the following table:
Parameter |
Description and Default Value |
---|---|
service.wcap. allowpublicwritablecalendars |
Enables users to have publicly writable calendars. This is enabled by default (set to “yes”). |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
After your resources are added, you can administer them using csresource:
Change to the sbin directory.
Use the csresource list command to list one or all resources.
For example, list all the information about all the resources:
./csresource -v list
Change to the sbin directory.
Use the csresource enable command to enable one or more resources.
For example, to enable the ConfRm12 resource:
./csresource -v enable ConfRm12
Change to the sbin directory.
Use the csresource disable command to disable one or more resources. For example, to disable the ConfRm12 resource:
./csresource -v disable ConfRm12
Change to the sbin directory.
Use the csresource delete command to delete one or more resources. For example, to delete the ConfRm12 resource:
./csresource -v delete ConfRm12
This section contains directions for setting up a bitbucket channel for both Messaging Server and Sendmail. The bitbucket channel is a way to discard the email generated for resource calendars. These examples use a resource named Room100 on the sesta.com server. If you don’t set up the bitbucket channel (or equivalent), you will need to periodically delete the email messages sent to the resource calendar.
This section contains the following procedures:
Ensure the bitbucket channel is defined in the imta.cnf file.
To direct messages to the bitbucket channel, create the email address for the resource using the csattribute utility:
csattribute -a mail=Room100@bitbucket.sesta.com add Room100 |
In the /etc/aliases file on the appropriate host, add an entry such as:
Resource/Conference room aliases Room100: /dev/null |
Add the email address for the resource to the LDAP directory using the csattribute utility:
csattribute -a mail=Room100@sesta.com add Room100 |
Manage LDAP attributes used by Calendar Server, with the csattribute utility, or ldapmodify. Attributes can be listed, added, or deleted with csattribute. To modify an attribute, use ldapmodify. This section contains the following topics:
Log in as the user or group under which Calendar Server is running (such as icsuser and icsgroup) that was specified during installation, or as root
Change to the sbin directory.
Use the csattribute list command to list the attributes for a user or a resource. For example, to list the attributes for tchang@sesta.com:, issue the following command:
./csattribute -t user -d sesta.com list tchang
Log in as the user or group under which Calendar Server is running (such as icsuser and icsgroup) that was specified during installation, or as root
If you want this attribute change to be recognized immediately, stop Calendar Server. Otherwise, you do not have to stop Calendar Server.
Change to the sbin directory.
Use the csattribute add command to add an attribute to a user or a resource. For example, to add the LDAP attribute icsCalendar with the value Conference_Schedule to the user tchang:
./csattribute -a icsCalendar=Conference_Schedule add tchang@sesta.com
Log in as the user or group under which Calendar Server is running (such as icsuser and icsgroup) that was specified during installation, or as root
If you want this attribute change to be recognized immediately, stop Calendar Server. Otherwise, you do not have to stop Calendar Server.
Change to the sbin directory.
Use the csattribute delete command to delete an attribute from a user or a resource. For example, to delete the LDAP attribute icsCalendar with the value Conference_Schedule from the user tchang:
./csattribute -a icsCalendar=Conference_Schedule -t user -d sesta.com delete tchang
To modify an LDAP entry attribute, use ldapmodify. For example, to change the status of user with uid=tchang, use ldapmodify as shown:
dn:uid=tchang,ou=people,o=sesta.com changetype: modify add: objectclass objectClass: icsCalendarUser add: icsStatus icsStatus: active |
If your site is using the LDAP CLD plug-in, do not attempt to move a user’s calendars from one back-end host to another by changing the value of icsDWPHost, using csattribute. Modifying icsDWPHost does not cause the calendar to be moved to the new back-end host. For instruction on how to move a calendar from one back-end server to another, see Managing User Calendars.