Notes de version de Sun Java Communications Suite 5

Nouveautés de cette version

Calendar Server 6.3 contient les modifications et nouvelles fonctions suivantes :

Prise en charge de Calendar Server dans la console Delegated Administrator

Auparavant, le déploiement de Calendar Server pour le schéma 2 pouvait être réalisé à l'aide de l'utilitaire Delegated Administrator, mais pas avec la console Delegated Administrator. Avant cette version, la console était une interface utilisateur graphique, accessible sur le Web, chargée d'administrer Messaging Server uniquement. Aujourd'hui, la console peut également être utilisée pour administrer les entrées LDAP du calendrier. À l'aide de la console, vous pouvez ajouter, supprimer ou modifier des entrées LDAP pour les utilisateurs de calendrier, les groupes, ressources et domaines. De nouveaux écrans et éléments de menu ont été ajoutés à la console pour la prise en charge de Calendar Server. Pour obtenir des informations sur l'utilisation de l'interface, consultez l'aide en ligne de Delegated Administrator. Vous trouverez également des informations dans le Sun Java System Calendar Server 6.3 Administration Guide.

Prise en charge des pièces jointes WCAP dans Calendar Server 6.3

La prise en charge des pièces jointes a été ajoutée aux commandes WCAP, avec de nouveaux paramètres et valeurs.

Les utilisateurs d'Universal Web Client (Communications Express) et Connector for Microsoft Outlook peuvent placer des pièces jointes dans leurs évènements et leurs tâches et peuvent envoyer des pièces jointes avec des invitations.

Dans le cadre de la prise en charge des pièces jointes, les modifications suivantes ont été apportées au WCAP :

fetchattachment.wcap : une nouvelle commande a été ajoutée pour extraire plus facilement les pièces jointes. Seule la pièce jointe est extraite et non pas l'événement ou la tâche.
deleteattach : nouvel argument de la commande storeevents, utilisé pour supprimer les pièces jointes existantes d'un évènement ou d'une tâche sans supprimer ces derniers.
fetchattach : nouveau paramètre ajouté à toutes les commandes fetch_by_* afin que les pièces jointes puissent être renvoyées avec l'événement et la tâche.
sendattach : nouveau paramètre pour la commande storeevents, utilisé pour spécifier l'envoi ou non de la pièce jointe avec l'invitation iTIP.
X-S1CS-CLIENT-ATTACH-ID : jeton X contenant l'identifiant unique de la pièce jointe. Ce jeton X est émis uniquement si le client a fourni l'ID de la pièce jointe lors du stockage de celle-ci. Sinon, la pièce jointe actuelle est envoyée avec l'événement.
L'argument attachments désapprouvé, trouvé dans les commandes storeevents et storetodos, peut stocker des références URL vers des pièces jointes stockées en dehors du magasin de données de Calendar Server. Ce mode d'utilisation des pièces jointes est conservé pour une compatibilité ascendante dans cette version mais sera supprimé dans les prochaines versions.

Pour obtenir de plus amples informations sur les pièces jointes, voir le Sun Java System Calendar Server 6.3 WCAP Developer’s Guide.

Prise en charge des groupes LDAP dans Calendar Server 6.3

Il est désormais possible de créer des groupes LDAP en utilisant Delegated Administrator. Les groupes comportent les fonctionnalités suivantes :

Un groupe est une liste d'utilisateurs. Le groupe ne « contient » pas d'utilisateurs répertoriés. Ce n'est pas un conteneur.
Un groupe peut posséder un calendrier de groupe.
Les invitations envoyées à un groupe résident sur tous les calendriers des membres, ainsi que sur le calendrier de groupe.
Tous les membres du groupe partagent les mêmes droits d'accès au calendrier de groupe.
Un calendrier de groupe n'a pas de propriétaire principal.

Mode de domaine multiple par défaut dans Calendar Server 6.3

Dans les versions précédentes du logiciel Calendar Server, il n'y avait pas de structure de domaine. Tous les enregistrements d'utilisateur et de groupe LDAP résidaient sous la racine. Puis, dans les versions suivantes, vous pouviez choisir d'établir un ou plusieurs domaines, nommés hosted domains ou virtual domains. Avec cette version du logiciel Calendar Server 6.3, toutes les installations doivent utiliser le mode de domaine multiple par défaut. Cela signifie que vous devez posséder au moins un domaine, le domaine par défaut, qui doit résider sous le domaine racine. Toutes les entrées d'utilisateur et de groupe LDAP doivent résider sous ce domaine par défaut ou vous pouvez choisir d'avoir plus de domaines. Lorsque vous êtes en mode de domaine multiple, chaque domaine canonical doit contenir des ID d'utilisateur et de groupe uniques. Pour plus d'informations sur les domaines multiples, voir le Sun Java System Calendar Server 6.3 Administration Guide, spécifiquement le Chapitre 10, Setting Up a Multiple Domain Calendar Server 6.3 Environment du Sun Java System Calendar Server 6.3 Administration Guide.

Le programme de configuration, csconfigurator.sh, que vous devez exécuter pour créer l'environnement d'exécution, vous demandera le nom de votre domaine par défaut. Si ce domaine n'existe pas, le programme le créera pour vous.

Si votre déploiement précédent de Calendar Server n'utilisait pas de domaines, ou même un seul domaine, vous devez déplacer les enregistrements de l'utilisateur et du groupe d'utilisateurs sous le nouveau domaine par défaut.

Pour créer des domaines supplémentaires dans un environnement de schéma version 2, utilisez la console ou l'utilitaire de Sun Java System Delegated Administrator. Pour plus d'informations sur Delegated Administrator, consultez le Sun Java System Delegated Administrator 6.4 Administration Guide .

Si vous utilisez le schéma version 1 et que vous ne migrez pas vers le schéma version 2, vous pouvez utiliser l'utilitaire Calendar Server csdomain pour créer des domaines supplémentaires.

Améliorations du programme de configuration de Calendar Server 6.3

Des écrans ont été ajoutés au programme de configuration pour les opérations suivantes :

Création de votre domaine LDAP par défaut

À partir de cette version, il y aura toujours au moins un domaine sous la racine. Celui-ci sera le domaine par défaut. Vous pouvez dès à présent spécifier le nom du domaine par défaut dans votre environnement à domaines multiples dans le programme de configuration.

Prise en charge des bases de données distribuées de Calendar Server

Vous pouvez spécifier les noms des machines frontales et d'arrière-plan pour votre environnement de bases de données distribuées, qui utilise le protocole DWP et le plug-in CLD. Les bases de données de calendrier peuvent être distribuées sur une ou plusieurs machines d'arrière-plan. Ces machines peuvent être associées à une machine frontale. Les nouveaux écrans du programme de configuration vous permettent de nommer les machines d'arrière-plan et de les associer avec une machine frontale.

Ajout du champ d'adresse e-mail sur l'écran de l'assistant de configuration

Dans l'écran du domaine par défaut, un nouveau champ a été ajouté pour l'adresse e-mail du superutilisateur du calendrier (calmaster).

Détails de récurrence inclus dans les invitations par e-mail dans Calendar Server 6.3

Pour les événements périodiques, les invitations par e-mail envoyées aux participants contiennent désormais les détails de récurrence.

csstored désormais processus obligatoire dans Calendar Server 6.3

Le démon csstored gère désormais diverses bases de données de Calendar Server. Puisque chaque service qui accède au magasin dépend du démarrage réussi de ce service de magasin, celui-ci doit continuer à s'exécuter sur tous les serveurs (frontal et d'arrière-plan) à chaque exécution du système Calendar Server. Les commandes de démarrage et d'arrêt standard,start-cal et stop-cal, démarrent et arrêtent csstored en même temps que les autres démons.

Dans les versions précédentes, si les sauvegardes automatiques n'étaient pas configurées, il n'était pas nécessaire d'exécuter le script PERL, csstored.pl. Le script pouvait être démarré et arrêté comme souhaité. Le script PERL a été désapprouvé en faveur du démon csstored. L'exécution de ce démon n'est plus facultative, que vous décidiez de configurer des sauvegardes automatiques ou non.

Auparavant, vous pouviez désactiver l'exécution du script en définissant le paramètre local.store.enable de ics.conf sur "no". Désormais, csstored doit toujours être activé avec local.store.enable défini sur "yes" (valeur par défaut).

Redémarrage automatique des services de Calendar à l'aide du Watcher

Calendar Server et Messaging Server utilisent maintenant le même mécanisme d'arrêt et de démarrage. La commande start-cal lance le processus watcher, puis lance tous les autres processus. Le processus watcherconnaît les dépendances des autres services et les séquences dans lesquelles les services doivent être démarrés.

Chaque service (processus) enregistré ouvre une connexion vers le Watcher. Si un processus meurt sans s'être déconnecté correctement, le Watcher le redémarre automatiquement. Si le processus meurt une deuxième fois dans un intervalle défini, Watcher ne le redémarre pas. Cet intervalle d'attente est configurable.

Informations supplémentaires sur le Watcher :

Services de Calendar Server contrôlés par Watcher

Watcher contrôle tous les services enregistrés disponibles. Pour Calendar Server, les processus enregistrés sont les suivants : cshttpd, csadmind , csdwpd, csnotifyd, et csstored.

Le démon csstored doit être activé. Assurez-vous de définir le paramètre de configuration local.store.enable sur "y" . L'activation de csstored était facultative dans la version précédente de Calendar Server, mais celle-ci est maintenant obligatoire. Le démon csstored doit être démarré avec succès avant que chaque service accédant au magasin ne soit démarré. S'il s'arrête, les processus dépendants doivent également être arrêtés et redémarrés.

Configuration du Watcher dans Calendar Server 6.3

Watcher est activé par défaut. Pour gérer le processus Watcher, de nouveaux paramètres ont été ajoutés au fichier ics.conf :

local.watcher.enable = "y" : le programme de démarrage (csservice) tente de démarrer le Watcher avant tout autre service. Si ce paramètre est défini sur "n", alors le programme Watcher est désactivé.
service.autorestart = "y" : Watcher redémarre automatiquement les services interrompus. S'il est défini sur "n", Watcher ne redémarre pas les services interrompus. Si ce paramètre est défini sur "n" , Watcher continue à contrôler les services et à envoyer des messages d'erreur de panne ou de défaut de réponse à la console et au fichier cal-svr-base/data/log .
local.autorestart.timeout = "600" : délai par défaut au cours duquel une seconde panne du serveur commande à Watcher d'arrêter toute tentative de redémarrage.
local.watcher.port : le port par défaut est "49994"; cependant, si vous avez installé Messaging Server, le programme écoutera également sur ce port et sera en conflit avec Calendar Server. Pour éviter ce genre de conflit, il est préférable de choisir un port différent d'écoute pour Watcher.

Connexion du Watcher dans Calendar Server 6.3

Watcher écrit dans un seul journal, cal-svr-base/data/log/watcher.log , qui contient les informations suivantes :

Messages d'erreur de panne et de défaut de réponse envoyés à la console d'administration.
Enregistrements de tous les arrêts et démarrages du serveur.

Redémarrage automatique en déploiements haute disponibilité dans Calendar Server 6.3.

Si un serveur tombe en panne deux fois dans la période d'attente, le système arrête toute tentative de redémarrage du serveur. Dans un système HA, Calendar Server est fermé et un basculement vers un autre système s'opère.

Démarrage et arrêt de Calendar Server 6.3 à l'aide des scripts Wrapper pour csservice

Les interfaces publiques pour csservice sont start-cal et stop-cal. Cette section décrit l'utilisation de chaque script wrapper et présente des tableaux expliquant leurs options et une liste des composants à démarrer ou arrêter.

Script Wrapper start-cal pour Calendar Server 6.3

Utilisation de start-cal :

./start-cal [options...] [components...]

Liste des options :

-? ou --help: Affiche cette fenêtre d'aide.
-d: Active le mode de débogage.
-l: Répertorie les services actifs.
-L: Répertorie les services activés.
-A: Répertorie tous les services.

Liste des composants :

watcher

ens

store

notify

admin

http

dwp

Si aucun composant n'est répertorié, start-cal démarre tous les services activés.

Script Wrapper stop-cal pour Calendar Server 6.3

Utilisation de stop-cal :

./stop-cal [options...] [components...]

Liste des options :

-? ou --help: Affiche cette fenêtre d'aide.
-d: Active le mode de débogage.
-f: Force l'arrêt à l'aide de SIGKILL. (Fonctionne uniquement avec les plates-formes UNIX®.)

Liste des composants :

watcher

mfagent

ens

store

notify

admin

http

dwp

Si aucun composant n'est répertorié, stop-cal interrompt tous les services activés.

Intégration de Monitoring Framework dans Calendar Server 6.3

Cette section décrit l'implémentation dans Calendar Server de Monitoring Framework et aborde les sujets suivants :

Pour plus d'informations sur Java Enterprise System Monitoring Framework, consultez le Sun Java Enterprise System 5 Monitoring Guide .

Mode d'implémentation de Monitoring Framework dans Calendar Server

Calendar Server et Messaging Server s'intègrent de manière minimale dans Monitoring Framework pour Java Enterprise System. Alors que Monitoring Framework est en cours d'exécution, le programme vérifie périodiquement l'attribut operationalStatus, qui peut être défini sur OK lorsque le système est en cours d'exécution ou DOWN lorsque le système n'est pas exécuté.

Un nouveau processus, l'agent Monitoring Framework (csmfagent), se lance au démarrage du système (start-cal). Il s'agit du premier processus démarré. Le processus instancie une application et déclare son statut sur OK. Il intercepte également SIGTERM et, une fois fait, déclare son statut sur DOWN et quitte l'application.

De la même manière, lorsque Watcher est configuré et exécuté, si une partie du système se met en échec ou ne répond plus, Watcher envoie un signal à SIGTERM, qui arrête alors csmfagent.

Configuration de Calendar Server pour Monitoring Framework

Modifiez le fichier de configuration ics.conf pour ajouter le paramètre suivant :

local.csmfagent.enable = "y"

Configuration de Monitoring Framework pour Calendar Server

Procédez comme suit :

Copiez /opt/SUNWcsgar/config/com.sun.cmm.cs.xml vers /opt/SUNWmfwk/xml.
Arrêtez puis redémarrez le processus de Manufacturing Framework.

Exigences d'installation de Monitoring Framework pour Calendar Server 6.3

Voici les deux exigences pour utiliser Monitoring Framework :

Java Enterprise System Monitoring Framework (JESMF) doit être installé.

Sinon, csmfagent ne s'exécutera pas.
Calendar Server doit être capable de rechercher les bibliothèques nécessaires.

Calendar Server recherche les bibliothèques à l'aide de liens symboliques dans /opt/SUNWics5/lib .

Bibliothèques 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

Remarque –

Il s'agit de la liste complète des bibliothèques JESMF. Il est possible qu'elles ne soient pas toutes nécessaires à l'implémentation de la partie Calendar Server de Monitoring Framework.

Transition vers Message Queue pour les services de notification de Calendar Server

Cette version comprend deux services de notification pour les notifications d'événement et les alertes : Sun Java System Message Queue (JMQ) et Event Notification System (ENS). Dans la prochaine version, les produits Communications Service utiliseront uniquement JMQ ; ENS sera supprimé. Cependant, pour cette version, les produits Communications Services (Messaging Server, Calendar Server et Instant Messaging) conservent des dépendances internes sur ENS. Vous pouvez donc continuer à utiliser ENS pour les notifications et alertes.

Pour utiliser JMQ, plutôt que ENS, Sun Java System Message Queue doit être installé et configuré. En outre, vous devez écrire vos propres notifications étant donné qu'aucune notification n'est fournie par Calendar Server 6.3.

Installez le produit à l'aide du programme d'installation de Sun Java Enterprise System. Pour obtenir des informations sur la configuration de Message Queue, voir Message Queue Documentation .

Paramètres de configuration de Calendar Server pour JMQ

Pour configurer Calendar Server pour JMQ, vous devez ajouter les lignes suivantes au fichier ics.conf :

local.server.csmfagent.enable = "yes"

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

ou bien

caldb.serveralarms.jmqlib = "/opt/sun/calendar/lib/libmqcrt.so" (pour 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"

Propriétés de notification de mise à jour de Message Queue pour Calendar Server 6.3

La propriété suivante est nécessaire pour chaque notification : MQ_MESSAGE_TYPE_HEADER_PROPERTY . Elle permet d'identifier le type de notification correspondant.

En outre, vous pouvez définir d'autres propriétés pour les notifications comme décrit dans le tableau suivant :

action: Propriété de chaîne indiquant le type d'action produite par cette notification. Valeurs disponibles : "EMAIL", "AUDIO", "DISPLAY", "PROCEDURE", "FLASHING".
aid: Propriété de chaîne contenant l'ID de l'alarme.
calid: Propriété de chaîne contenant l'ID du calendrier.
comptype: Propriété de chaîne indiquant le type de composant. La valeur correspondante est "event" (événement) ou "todo" (tâche).
rid: Propriété de nombre entier contenant l'ID de la récurrence.
uid: Propriété de chaîne contenant l'ID du composant, c'est-à-dire soit l'ID de l'évènement soit l'ID de la tâche.

Valeurs de notification de mise à jour de Message Queue dans Calendar Server 6.3

Il existe deux types de notification : les notifications d'alerte et les notifications de mise à jour pour les événements et les tâches.

Pour les notifications d'alerte, la valeur de MQ_MESSAGE_TYPE_HEADER_PROPERTY est simplement "alarm" (alerte) .

Pour les notifications de mise à jour, la valeur de MQ_MESSAGE_TYPE_HEADER_PROPERTY dépend du type d'action déclenchée par la notification. Le Tableau 2–2 répertorie les actions déclenchées et les valeurs correspondantes pour cette propriété.

Tableau 2–2 Valeurs des notifications de mise à jour


Déclenchement	Valeur de la notification de mise à jour
Suppression d'un calendrier	`DELETECAL`
Modification d'un événement	`MODIFYEVENT`
Modification d'une tâche	`MODIFYTODO`
Création d'un événement	`CREATEEVENT`
Création d'une tâche	`CREATETODO`
Rafraîchissement d'un événement	`REFRESHEVENT`
Rafraîchissement d'une tâche	`REFRESHTODO`
Réponse à un événement	`REPLYEVENT`
Réponse à une tâche	`REPLYTODO`

Réception de notifications de réponse par e-mail par les organisateurs d'événement dans Calendar Server 6.3

Il est désormais possible d'envoyer des notifications par e-mail aux organisateurs lorsqu'un participant répond à une invitation.

Configurez cette fonction en définissant le paramètre ine.reply.enable du fichier ics.conf. Choisissez "y" pour activer la fonction pour l'ensemble du système ou "n" pour la désactiver. Par défaut, cette fonction est activée.

Les trois types de réponse sont les suivants : accepter, refuser et accepter provisoirement. La notification indique si la réponse s'adresse à une invitation unique ou à un événement périodique. Les nouveaux paramètres de fichier de format de message suivants ont été ajoutés. Les fichiers de format correspondants ont également été ajoutés :

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"

Remarque –

Cette fonction ne fait pas partie des préférences utilisateur. Il s'agit d'un paramètre de configuration système et celui-ci s'applique donc à tous les utilisateurs qui envoient des invitations.

Pour obtenir plus d'informations sur la configuration de Calendar Server relative aux notifications par e-mail, reportez-vous à la section To Enable Email Notifications du Sun Java System Calendar Server 6.3 Administration Guide .

Possibilité de modification des copies d'événement des participants

L'interface WCAP a été modifiée pour permettre à une copie d'évènements du calendrier destinée aux participants d'être modifiée, y compris les champs de résumé et de description.

Amélioration de l'outil de renommage

L'utilitaire Calendar Server 6.3 rename comprend des éléments supprimés lors du renommage de données du calendrier.

Modification du calcul libre-occupé dans Calendar Server 6.3

Les évènements refusés n'apparaissent plus comme « occupés » dans les calendriers libre-occupé.

Désactivation de l'ancienne interface utilisateur Calendar Express dans Calendar Server 6.3

Avec les versions précédentes de Calendar Server, Calendar Express (ancienne interface utilisateur) était automatiquement installé et activé. Vous ne pouvez pas le désactiver, même si vous ne l'avez pas utilisé auparavant. Si vous procédez à une mise à niveau vers Calendar Server 6.3, le processus ajoute service.http.ui.enable="y" dans le fichier ics.conf. Cela permet de maintenir l'ancienne interface utilisateur activée si vous voulez l'utiliser ; aucune action supplémentaire n'est nécessaire.

Pour désactiver Calendar Express, définissez la valeur de service.http.ui.enable sur "n" dans le fichier ics.conf.

L'interface utilisateur Calendar Express n'est pas automatiquement installée dans Calendar Server 6.3

Calendar Express n'est plus automatiquement installé dans une nouvelle installation. Si vous effectuez une nouvelle installation de Calendar Server 6.3, mais que vous voulez utiliser Calendar Express comme interface utilisateur, vous devez explicitement l'installer en utilisant le programme d'installation de Communications Suite 5. Puis vous devez le configurer en ajoutant service.http.ui.enable="y" au fichier ics.conf . (Le paramètre interne par défaut est "n" pour les nouvelles installations, par conséquent, vous devez explicitement le définir sur "y".)

Si vous procédez à la mise à niveau à partir d'une version antérieure de Calendar Server, le processus ajoute ce paramètre à ics.conf à votre place, avec sa valeur définie sur "y". Cela vous permet de continuer à utiliser l'ancienne interface utilisateur sans aucune modification. Cependant, si vous souhaitez la désactiver, définissez ce paramètre sur "n".

Installation de plates-formes matérielles mixtes

Auparavant, pour les environnements de bases de données distribuées (DWP avec plug-in CLD), il était nécessaire d'installer les processus frontaux et d'arrière-plan sur la même plate-forme matérielle face aux problèmes big-endian et little-endian. Ce n'est désormais plus le cas. Les processus frontaux et d'arrière-plan peuvent maintenant être installés sur différentes plates-formes matérielles.

Par exemple, vous pouvez avoir une machine plate-forme X-86 comme machine frontale et une machine plate-forme SPARC comme machine d'arrière-plan.

Compatibilité iTIP dans Calendar Server 6.3

Les messages envoyés par Calendar Server sont désormais compatibles avec iTIP (pour l'interopérabilité avec Microsoft Outlook).

comm_dssetup.pl : nouvelle option pour un fichier de mots de passe améliorant la sécurité dans Calendar Server 6.3

Pour une plus grande sécurité, il est désormais possible de spécifier un fichier de mots de passe au lieu d'un mot de passe texte lors de l'exécution de comm_dssetup.pl. Grâce à la nouvelle option -j <passwordfilename >, vous pouvez protéger vos mots de passe et obtenir ainsi une plus grande sécurité. Cette option est particulièrement pratique pour les scripts. Si vous avez des scripts exposant votre mot de passe et que vous souhaitez les modifier, supprimez l'option -w < password> et remplacez-la par la nouvelle.

Remarque –

Il s'agit de la solution proposée pour le problème n° 6392093.

Utilitaires csdb, cscal, et csuser de Calendar Server 6.3 déplacés vers cal/sbin

Dans les versions précédentes de Calendar Server, csdb, cscal et csuser se trouvaient dans le répertoire cal/bin. Celui-ci est désormais remplacé par le répertoire cal/sbin.

Modifications SSL apportées au fichier ics.conf pour Calendar Server 6.3

Suite aux modifications du code de programme de Calendar Server, le fichier ics.conf a été modifié comme suit :

service.http.ssl.certdb.path a été désapprouvé en faveur de local.ssldbpath. Le chemin donné doit pointer vers le fichier config ("/etc/opt/SUNWics5/config").
Au lieu d'inclure le mot de passe réel à la base de données de certificats dans le fichier ics.conf, le mot de passe réside désormais dans un fichier (sslpassword.conf) du répertoire config.

Voici le format de mot de passe à utiliser dans ce fichier :
```
Interne (Logiciel) Jeton :mot de passe
```