Notas de la versión de Sun Java Communications Suite 5

Novedades de la nueva versión de Calendar Server

Calendar Server 6.3 incluye los siguientes cambios y nuevas funciones:

Soporte para Calendar Server en la consola de Delegated Administrator

Anteriormente se podía utilizar la utilidad de Delegated Administrator para preparar Calendar Server para Schema 2, pero no la consola de Delegated Administrator. Antes de esta versión, la consola era la interfaz de usuario gráfica de web que se utilizaba para administrar sólo Messaging Server. Ahora también es posible utilizar la consola para administrar las entradas LDAP del calendario . La consola le permite agregar, eliminar o modificar las entradas LDAP para los usuarios del calendario, los grupos, los recursos y los dominios. Se han agregado nuevas pantallas y comandos de menú en la consola para ofrecer compatibilidad con Calendar Server. Para obtener instrucciones sobre cómo utilizar la interfaz, consulte la ayuda en línea de Delegated Administrator. También podrá encontrar información en la Sun Java System Calendar Server 6.3 Administration Guide.

Compatibilidad con los documentos adjuntos de WCAP en Calendar Server 6.3

Se ha incluido asistencia para documentos adjuntos en los comandos WCAP con la inclusión de nuevos parámetros y valores.

Los usuarios del Cliente web universal (Communications Express) y de Connector para Microsoft Outlook pueden agregar documentos adjuntos a sus eventos y tareas y enviar invitaciones adjuntas.

Para poder ofrecer asistencia para los documentos adjuntos, se han incluido los siguientes cambios en WCAP:

fetchattachment.wcap: Se ha incluido un nuevo comando para facilitar la búsqueda de documentos adjuntos. Sólo se busca el adjunto, no los datos del evento ni de la tarea.
deleteattach: Se ha incluido un nuevo argumento en el comando storeevents, que sirve para eliminar los documentos adjuntos existentes de un evento o tarea sin borrar el elemento ni la tarea en cuestión.
fetchattach : Se ha incluido un nuevo parámetro en todos los comandos fetch_by_* que permite recuperar los documentos adjuntos además de los datos del evento y de la tarea.
sendattach : Nuevo parámetro del comando storeevents, que se utiliza para especificar si el documento adjunto debe enviarse con la invitación iTIP o no.
X-S1CS-CLIENT-ATTACH-ID : Un X-Token (testigo X ) que contiene el identificador único del documento adjunto. Este X-Token (testigo X ) se emite sólo si el cliente facilitó el ID del documento adjunto cuando éste fue guardado. De lo contrario, el documento adjunto se envía con el evento.
El argumento desaprobado attachments que se encontraba en los comandos storeevents y storetodos, puede guardar referencias a URL en los documentos adjuntos guardados fuera del almacén de datos de Calendar Server. Esta versión aún mantiene la forma de utilizar documentos adjuntos para poder ser compatible con versiones anteriores, pero esta función dejará de distribuirse en futuras versiones.

Para más información sobre los documentos adjuntos, consulte la Sun Java System Calendar Server 6.3 WCAP Developer’s Guide.

Compatibilidad con grupos LDAP en Calendar Server 6.3

Ahora es posible crear grupos LDAP utilizando Delegated Administrator. Estas son las características de los grupos:

Los grupos son listas de usuarios. Los grupos no "contienen" a los usuarios de la lista. No son contenedores.
Los grupos pueden tener calendarios de grupo.
Las invitaciones que se envíen a los grupos residen en los calendarios de todos los miembros, y también en el calendario del grupo.
Todos los miembros del grupo tienen los mismos derechos de acceso al calendario del grupo.
Los calendarios de grupo no tienen propietario principal.

Modo multidominio por defecto en Calendar Server 6.3

En las versiones anteriores del programa Calendar Server, no había estructura de dominio. Todos los registros LDAP de grupo y de usuario residían en la raíz. En versiones posteriores, el usuario podía elegir entre establecer uno o varios dominios, llamados dominios alojados o dominios virtuales. Con el lanzamiento de Calendar Server 6.3, todas las instalaciones deben utilizar el modo multidominio por defecto. Esto quiere decir que debe tener como mínimo un dominio, el predeterminado, residiendo en el dominio de la raíz. Todas las entradas de LDAP de grupo y de usuario residen en este dominio predeterminado, o bien puede elegir tener más dominios. Cuando se encuentra en el modo de dominio múltiple, cada dominio reconocido debe contener un ID de usuario y de grupo únicos. Para más información sobre los dominios múltiples, consulte la Guía de administración de Sun Java System Calendar Server 6.3, en concreto, el Capítulo 10, Setting Up a Multiple Domain Calendar Server 6.3 Environment de Sun Java System Calendar Server 6.3 Administration Guide.

El programa de configuración, csconfigurator.sh, que debe ejecutar para crear el entorno en tiempo de ejecución, le pedirá el nombre de su dominio predeterminado. Si no existe ese dominio, el programa lo creará por usted.

Si su implementación anterior de Calendar Server no utilizaba dominios múltiples, o ni siquiera un solo dominio, es preciso que mueva los registros LDAP de grupo y de usuario al nuevo dominio predeterminado.

Para crear dominios adicionales en un entorno de la versión 2 de Schema, utilice la consola o la utilidad del administrador delegado de Sun Java System. Para más información sobre el administrador delegado, consulte la Sun Java System Delegated Administrator 6.4 Administration Guide.

Si utiliza la versión 1 de Schema y no piensa cambiar a la versión 2, puede utilizar la utilidad csdomain de Calendar Server para crear dominios adicionales.

Mejoras en el programa de configuración de Calendar Server 6.3

El programa de configuración incorpora pantallas nuevas para:

Creación de su dominio LDAP predeterminado

Por primera vez en esta versión, siempre habrá como mínimo un dominio bajo la raíz. Este será el dominio predeterminado. Ahora puede especificar el nombre del dominio predeterminado para su entorno de dominios múltiples en el programa de configuración.

Soporte de las bases de datos distribuidas del servidor de calendarios

Ahora puede especificar los nombres de las máquinas principales y secundarias para su entorno de bases de datos distribuidas, el cual utiliza el protocolo DWP y el complemento CLD. Es posible distribuir las bases de datos del calendario en una o varias máquinas secundarias. Estas máquinas pueden asociarse con una máquina principal. Las nuevas pantallas del programa de configuración le permiten poner nombre a las máquinas secundarias y asociarlas con la máquina principal.

La pantalla del asistente de configuración incorpora un campo de dirección de correo electrónico

En la pantalla del dominio predeterminado se ha incluido un nuevo campo para la dirección de correo electrónico del superusuario del calendario (calmaster).

Detalles de recurrencia incluidos en las invitaciones de correo electrónico de Calendar Server 6.3

Para los eventos recurrentes, las invitaciones de correo electrónico enviadas a los asistentes contienen ahora detalles de recurrencia.

csstored es ahora un proceso obligatorio en Calendar Server 6.3

El daemon csstored ahora gestiona las diferentes bases de datos de Calendar Server. Como todos los servicios que acceden al almacén dependen del inicio correcto de este servicio de almacén, debe estar en funcionamiento en todos los servidores, tanto principales como secundarios, siempre que el sistema Calendar Server esté en funcionamiento. Los comandos típicos de iniciar y apagar, start-cal y stop-cal, inician y detienen csstored junto con los otros daemons.

En las versiones anteriores, a menos que configurase la realización automática de copias de seguridad, no era necesario ejecutar la secuencia de comandos PERL csstored.pl. La secuencia de comandos podía iniciarse y detenerse cuando se quisiese. La secuencia de comandos PERL se ha sustituido por el daemon csstored. Ejecutar este daemon ya no es opcional, tanto si decide configurar la realización automática de copias de seguridad como si no.

Antes, usted podía deshabilitar la ejecución de la secuencia de comandos estableciendo el parámetro local.store.enable de ics.conf en "no". Sin embargo, ahora csstored debe estar siempre habilitado, con local.store.enable establecido en "yes", que es el valor predeterminado.

Reinicio automático de los servicios de calendario utilizando Watcher

Calendar Server y Messaging Server utilizan ahora el mismo mecanismo de detención e inicio. El comando start-cal inicia el proceso de watcher y después ejecuta los demás procesos. El proceso de watcherconoce las dependencias que tienen los otros servicios y la secuencia con la que deberían iniciarse.

Cada servicio registrado (proceso) abre una conexión con Watcher. Si se interrumpe un proceso sin desconectarlo correctamente, Watcher lo reinicia automáticamente. Si se interrumpe el proceso dos veces en un intervalo definido, Watcher no lo reiniciará. Es posible configurar este intervalo de tiempo de espera.

Información adicional de Watcher:

Servicios de Calendar Server supervisados por Watcher

Watcher supervisa todos los servicios que se han registrado en él. Los procesos registrados para Calendar Server son: cshttpd, csadmind , csdwpd, csnotifyd, y csstored.

Debe habilitarse el daemon csstored. Asegúrese de establecer el parámetro de configuración local.store.enable en "y" . La activación decsstored era opcional en la versión anterior de Calendar Server, pero ahora es obligatoria. El daemon csstored debe iniciarse correctamente para que puedan activarse todos los servicios que dan acceso al almacén. Si se detiene, será necesario interrumpir y reiniciar también los procesos dependientes.

Configuración de Watcher en Calendar Server 6.3

Watcher está habilitado por defecto. Para gestionar el proceso Watcher, se han agregado nuevos parámetos al archivo ics.conf:

local.watcher.enable = "y": El programa de inicio (csservice) intentará iniciar Watcher antes que cualquier otro servicio. Si este parámetro está establecido en "n", se deshabilitará el programa Watcher.
service.autorestart = "y": Watcher reinicia automáticamente los servicios detenidos. Si está establecido en "n", Watcher no reiniciará los servicios detenidos. Cuando este parámetro esté establecido en "n" , Watcher controlará los servicios y enviará mensajes de error avisando de los fallos o de la falta de respuesta a la consola y al archivo cal-svr-base/data/log.
local.autorestart.timeout = "600": El tiempo predeterminado durante el cual un segundo fallo del servidor hace que Watcher se abstenga de intentar reiniciar los servicios.
local.watcher.port: El puerto predeterminado es "49994"; sin embargo, si usted dispone de Messaging Server, tenga en cuenta que este programa utiliza también este puerto y se producirá un conflicto con Calendar Server. Para evitar posibles conflictos, se recomienda elegir un puerto diferente para Watcher.

Registro de Watcher en Calendar Server 6.3

Watcher escribe en un solo registro: cal-svr-base/data/log/watcher.log , que contiene la siguiente información:

Los avisos de fallos y los mensajes de error por falta de respuesta que se enviaron a la consola administrativa.
Los registros con las detenciones y los inicios del servidor.

Reinicio automático en implementaciones de alta disponibilidad en Calendar Server 6.3

Si un servidor falla dos veces dentro del periodo de tiempo de espera, el sistema dejará de intentar reiniciar el servidor. En un sistema de alta disponibilidad se cierra Calendar Server y se produce un relevo en el otro sistema

Iniciar y detener Calendar Server 6.3 utilizando secuencias de comandos del empaquetador para csservice

Las interfaces públicas de csservice son start-cal y stop-cal. Esta sección muestra cómo utilizar cada una de estas secuencias de comandos del empaquetador y contiene tablas con explicaciones de sus opciones y con la lista de componentes que deberán iniciarse o detenerse.

Secuencia de comandos del empaquetador start-cal para Calendar Server 6.3

El uso de start-cal es el siguiente:

./start-cal [opciones...] [componentes...]

A continuación se muestra la lista de opciones:

-? o --help: Mostrar esta lista de ayuda.
-d: Habilitar modo de depuración.
-l: Enumerar los servicios activos.
-L: Enumerar los servicios habilitados.
-A: Enumerar todos los servicios.

A continuación se muestra la lista de componentes:

watcher

ens

store

notify

admin

http

dwp

Si no aparece ningún componente en la lista, start-cal iniciará todos los servicios habilitados.

Secuencia de comandos del empaquetador start-cal para Calendar Server 6.3

El uso de stop-cal es el siguiente:

./stop-cal [opciones...] [componentes...]

A continuación se muestra la lista de opciones:

-? o --help: Mostrar esta lista de ayuda.
-d: Habilitar modo de depuración.
-f: Obligar a que deje de utilizar SIGKILL. (Esto sólo funciona en plataformas UNIX®.)

A continuación se muestra la lista de componentes:

watcher

mfagent

ens

store

notify

admin

http

dwp

Si no aparece ningún componente en la lista, stop-cal detendrá todos los servicios habilitados.

Integración con Monitoring Framework en Calendar Server 6.3

En esta sección se describe la implementación que ha hecho Calendar Server de Monitoring Framework y trata los siguientes temas:

Puede obtener más información acerca de Java Enterprise System Monitoring Framework en la Sun Java Enterprise System 5 Monitoring Guide.

Cómo se implementa Monitoring Framework en Calendar Server

Tanto Calendar Server como Messaging Server ofrecen una integración mínima en Monitoring Framework de Java Enterprise System. Cuando está ejecutándose, Monitoring Framework efectúa comprobaciones periódicas del siguiente atributo: operationalStatus , cuyo estado puede ser OK, si el sistema está ejecutándose, o DOWN, si el sistema no está ejecutándose.

Un nuevo proceso, el agente de Monitoring Framework (csmfagent), se inicia al iniciarse el sistema (start-cal). Este es el primer proceso que se inicia. El proceso crea una instancia de una aplicación y valora su estado como OK. También capta a SIGTERM y al captar uno, valora el estado como DOWN y se cierra.

De forma parecida, cuando Watcher está configurado y ejecutándose, emitirá una señal a SIGTERM en caso de que alguna parte del sistema falle o no responda, y Watcher detendrá a csmfagent.

Configuración de Calendar Server para Monitoring Framework

Edición del archivo de configuración, ics.conf, para que contenga el siguiente parámetro:

local.csmfagent.enable = "y"

Configuración de la estructura de supervisión para Calendar Server

Siga estos dos pasos:

Copie /opt/SUNWcsgar/config/com.sun.cmm.cs.xml en /opt/SUNWmfwk/xml.
Detenga y después inicie el proceso de Monitoring Framework.

Requisitos de instalación de Monitoring Framework para Calendar Server 6.3

Para poder utilizar (Monitoring Framework) hay que reunir dos requisitos:

Deberá estar instalado Java Enterprise System Monitoring Framework (JESMF).

Si JESMF no está instalada, csmfagent no podrá ejecutarse.
Calendar Server debe poder encontrar las bibliotecas necesarias.

Calendar Server encuentra las bibliotecas utilizando vínculos simbólicos en /opt/SUNWics5/lib .

A continuación se muestran las bibliotecas de JESMF:

/opt/SUNWmfwk/lib/libMfTransaction.so

/opt/SUNWmfwk/lib/libMfRelations.so

/opt/SUNWmfwk/lib/libMflog4c.so

/opt/SUNWmfwk/lib/libMfMEServer.so

/opt/SUNWmfwk/lib/libmfBeepConnectorServer.so

/opt/SUNWmfwk/lib/libMfRserver.so

/opt/SUNWmfwk/lib/libMfMEInstrum.so

/opt/SUNWmfwk/lib/libMfDiscovery.so

/opt/SUNWmfwk/lib/libMfHashTable.so

/opt/SUNWmfwk/lib/libMflog.so

/opt/SUNWmfwk/lib/libasn1cebuf.so

/opt/SUNWmfwk/lib/libbeepcore.so

/opt/SUNWmfwk/lib/libbeepxmlutil.so

/opt/SUNWmfwk/lib/libbptostransport.so

/opt/SUNWmfwk/lib/libbptosutil.so

/opt/SUNWmfwk/lib/libbptoswrapper.so

/opt/SUNWmfwk/lib/libbputil.so

/opt/SUNWmfwk/lib/libcmm_native.so

/opt/SUNWmfwk/lib/libmfCserver.so

/opt/SUNWmfwk/lib/libmfNotificationProfile.so

/opt/SUNWmfwk/lib/libmfRequestResponseProfile.so

/opt/SUNWmfwk/lib/libmfTimers.so

/opt/SUNWmfwk/lib/libmfTimersJNI.so

/opt/SUNWmfwk/lib/libmfUtils.so

/opt/SUNWmfwk/lib/libmfber.so

/opt/SUNWmfwk/lib/libmfberj.so

/opt/SUNWmfwk/lib/libxmlglobal.so

Nota –

Es una lista de todas las bibliotecas JESMF. Es posible que no las necesite todas para implementar la porción de Calendar Server de Monitoring Framework.

Transición a la cola de mensajes de los servicios de notificación de Calendar Server

Esta versión incluye dos servicios de notificación de eventos y alarmas: Sun Java System Message Queue (JMQ) y Event Notification System (ENS). En las versiones futuras, los productos de Communications Service utilizarán exclusivamente JMQ y se eliminará ENS. Sin embargo, en esta versión los productos de Communications Services (Messaging Server, Calendar Server, e Instant Messaging) todavía dependen internamente de ENS, por lo que puede continuar usándolo para las notificaciones y alarmas.

Si desea utilizar JMQ en vez de ENS, deberá tener Sun Java System Message Queue instalado y configurado. Además, deberá escribir sus propias notificaciones, ya que Calendar Server 6.3 no le proporcionará ninguna.

Para instalar el producto, utilice el programa de instalación de Sun Java Enterprise System. Para obtener información sobre la instalación de Message Queue, consulte la Documentación de Message Queue .

Parámetros de configuración de Calendar Server para JMQ

Para configurar Calendar Server para JMQ, debe agregar las siguientes líneas al archivo ics.conf:

local.server.csmfagent.enable = "yes"

caldb.serveralarms.jmqlib = "/opt/SUNWics5/cal/lib/libmqcrt.so" (para Solaris)

o bien

caldb.serveralarms.jmqlib = "/opt/sun/calendar/lib/libmqcrt.so" (para Linux)

caldb.serveralarms.dispatchtype = "jmq"

caldb.serveralarms.jmqhost = "localhost"

caldb.serveralarms.jmqport = "7676"

caldb.serveralarms.jmqUser = "guest"

caldb.serveralarms.jmqPWD = "guest"

caldb.serveralarms.jmqTopic = "JES-CS"

Propiedades de notificación de actualización de la cola de mensajes en Calendar Server 6.3

Cada notificación debe tener la siguiente propiedad: MQ_MESSAGE_TYPE_HEADER_PROPERTY . Esta propiedad identifica el tipo de notificación.

Además, las notificaciones pueden tener otras propiedades, tal y como se muestra en la siguiente tabla:

action: Propiedad de cadena que indica el tipo de acción que provoca esta notificación. Esta propiedad puede tener los siguientes valores: "EMAIL", "AUDIO", "DISPLAY", "PROCEDURE", "FLASHING".
aid: Propiedad de cadena que contiene el ID de la alarma.
calid: Propiedad de cadena que contiene el ID del calendario.
comptype: Propiedad de cadena que indica el tipo de componente. El valor puede ser "event" o "todo".
rid: Propiedad entera que contiene el ID de la recurrencia.
uid: Propiedad de cadena que contiene el ID del componente, es decir que contiene bien el ID del evento bien el ID de la tarea

Valores de notificación de actualización de la cola de mensajes en Calendar Server 6.3

Las notificaciones pueden ser de dos tipos: notificaciones de alarmas y notificaciones de actualizacion para eventos y tareas.

En el caso de las notificaciones de alarma, el valor de MQ_MESSAGE_TYPE_HEADER_PROPERTY es simplemente "alarm".

En el caso de las notificaciones de actualización, el valor de MQ_MESSAGE_TYPE_HEADER_PROPERTY depende del tipo de acción que desencadenó la notificación. La Tabla 2–2 incluye una lista de las acciones desencadenantes y los correspondientes valores de esta propiedad.

Tabla 2–2 Actualizar valores de la notificación


Desencadenar	Actualizar valor de la notificación
Borrar un calendario	`DELETECAL`
Modificar un evento	`MODIFYEVENT`
Modificar una tarea	`MODIFYTODO`
Crear un evento	`CREATEEVENT`
Crear una tarea	`CREATETODO`
Actualizar un evento	`REFRESHEVENT`
Actualizar una tarea	`REFRESHTODO`
Responder a un evento	`REPLYEVENT`
Responder a una tarea	`REPLYTODO`

Los organizadores de eventos reciben notificaciones de respuesta por correo electrónico en Calendar Server 6.3

Ahora es posible enviar notificaciones por correo electrónico a los organizadores cada vez que un asistente conteste a una invitación.

Para configurar esta función, establezca el parámetro de ics.conf,ine.reply.enable. Establézcalo en "y" para habilitar esta función para todo el sistema. Establézcalo en "n" para deshabilitar la función. Esta función se encuentra habilitada por defecto.

Existen tres tipos de respuesta, que son: aceptar, rechazar y aceptar provisionalmente. La notificación indica si se trata de una respuesta a una sola invitación o a un evento recurrente. Se han agregado los siguientes parámetros de archivo de formato al nuevo mensaje. También se han agregado los correspondientes archivos de formato.

calmail.imipeventacceptnotification.fname= "mail_eventacceptnotification.fmt"
calmail.imipeventdeclinenotification.fname= "mail_eventdeclinenotification.fmt"
calmail.imipeventtentativeacceptnotification.fname= "mail_eventtentativeacceptnotification.fmt"
calmail.imipeventacceptnotificationrecur.fname= "mail_eventacceptnotificationrecur.fmt"
calmail.imipeventdeclinenotificationrecur.fname= "mail_eventdeclinenotificationrecur.fmt"
calmail.imipeventtentativeacceptnotificationrecur.fname= "mail_eventtentativeacceptnotificationrecur.fmt"

Nota –

Esta función no es una preferencia del usuario. Se trata de un parámetro de configuración para todo el sistema, por lo que se aplica a todos los usuarios que envían invitaciones.

Para obtener más información sobre cómo configurar Calendar Server para que envíe notificaciones por correo electrónico, consulte To Enable Email Notifications de Sun Java System Calendar Server 6.3 Administration Guide

Es posible modificar las copias de eventos de los asistentes

Se ha modificado la interfaz WCAP para permitir la modificación de las copias de los eventos del calendario de los asistentes, incluyendo los campos resumen y descripción.

Renombrar las mejoras de la herramienta

La utilidad de Calendar Server 6.3 rename incluye elementos eliminados al cambiar el nombre de los datos del calendario.

Cambio de cálculo libre-ocupado en Calendar Server 6.3

Los eventos rechazados ya no aparecen como ocupados en los calendarios "libre-ocupado".

Deshabilitar la antigua interfaz de usuario de Calendar Express en Calendar Server 6.3

Con versiones anteriores de Calendar Server, se instalaba y habilitaba automáticamente Calendar Express, la antigua interfaz de usuario. No era posible desactivar esta interfaz aunque nunca la utilizara. Si va a actualizarse a Calendar Server 6.3, el proceso de actualizacion agrega service.http.ui.enable="y" al archivo ics.conf. De esta forma, la antigua interfaz de usuario se mantiene activada por si desea utilizarla, y no es preciso hacer nada más.

Para desactivar Calendar Express, establezca el valor de service.http.ui.enable a "n" en el archivo ics.conf.

La interfaz de usuario de Calendar Express no se instala automáticamente en Calendar Server 6.3

Calendar Express ya no se instala automáticamente en las nuevas instalaciones. Si va a volver a instalar Calendar Server 6.3, pero desea utilizar la interfaz de usuario de Calendar Express, deberá instalarlo explícitamente utilizando el programa de instalación de Communications Suite 5. Después, tendrá que configurarlo agregando service.http.ui.enable="y" al archivo ics.conf . (La configuración interna predeterminada es "n" para las instalaciones nuevas, por lo que deberá establecerla en "y".)

Si va a actualizar una versión anterior de Calendar Server, el proceso de actualización agrega el parámetro al archivo ics.conf, con el valor establecido en "y". Esto permite seguir utilizando la interfaz anterior del usuario sin cambio alguno. Sin embargo, si desea deshabilitarla, establezca este parámetro en "n".

Instalación en plataformas de hardware mixtas

Hasta ahora, para los entornos de bases de datos distribuidas (DWP con el complemento CLD), los procesos principales y secundarios tenían que instalarse en la misma plataforma de hardware debido a problemas relacionados con las codificaciones big-endian y little-endian. Ahora ya no es así. Ahora los procesos principales y secundarios pueden instalarse en distintas plataformas de hardware.

Por ejemplo, una máquina principal podría tener la plataforma X-86, mientras que la secundaria podría ser un equipo de plataforma SPARC.

Compatibilidad de iTIP en Calendar Server 6.3

Los mensajes enviados por Calendar Server son ahora compatibles con iTIP (que proporciona interoperabilidad con Microsoft Outlook).

comm_dssetup.pl: Nueva opción para el archivo de contraseña que aumenta la seguridad en Calendar Server 6.3

Para aumentar la seguridad, ahora es posible especificar un archivo de contraseña en lugar de una contraseña de texto al ejecutar comm_dssetup.p. Con la nueva opción -j <passwordfilename> puede proteger las contraseñas y aumentar la seguridad. Esto es especialmente útil para las secuencias de comandos. Si tiene secuencias de comandos que exponen la contraseña actualmente, y desea cambiarlos, elimine la opción -w < contraseña> y sustitúyala por esta nueva.

Nota –

Esto soluciona el problema nº 6392093.

Las utilidades de Calendar Server 6.3 csdb, cscal, y csuser reubicadas en cal/sbin

En versiones anteriores de Calendar Server, csdb, cscal y csuser se encontraban en el directorio cal/bin, pero ahora están en el directorio cal/sbin.

Cambios de SSL en el archivo ics.conf para Calendar Server 6.3

Debido a los cambios introducidos en el código de programación de Calendar Server, se han hecho los siguientes cambios en el archivo ics.conf:

service.http.ssl.certdb.path descartado en favor de local.ssldbpath. La ruta dada debería llevar al archivo config ("/etc/opt/SUNWics5/config").
En vez de incluir la contraseña real en la base de datos de certificados en el archivoics.conf, la contraseña se encuentra ahora en un archivo (sslpassword.conf) ubicado en el directorio config.

El formato adecuado para las contraseña de este archivo es:
```
Testigo (de software) interno:contraseña
```