Cette section répertorie sous forme de tableaux les problèmes connus les plus importants au moment de la sortie de Calendar Server 6.3 :
Nous connaissons actuellement les restrictions suivantes :
Le programme de configuration place une valeur incorrecte dans le paramètre DWP de ics.conf
Régression des performances pour l'interface utilisateur désapprouvée
Suppression de toutes les instances de préférences utilisateur à valeurs multiples
Identification des patchs installés dans un environnement clusterisé
Déploiement des utilisateurs pour Communications Express en mode Schéma 1
Saisie obligatoire du nom complet et du nom relatif de l'hôte dans le fichier de configuration
Obligation de mettre entre guillemets les données non compatibles RFC des jetons X
Utilisateurs non validés avant d'être ajoutés comme propriétaires secondaires
Calendriers de propriétaire non mis à jour par l'utilitaire de migration
Purge automatique impossible des données LDAP mises en cache obsolètes
>Échec des utilitaires Calendar en l'absence d'un arbre de composant de domaine
Messages d'erreur vagues envoyés par les utilitaires de Calendar Server
Disparition de l'interligne dans les descriptions lors de leur stockage
(Linux uniquement) Échec du redémarrage de Calendar Server après réinitialisation
Les évènements entre le 11 mars 2007 et le 1er avril 2007 sont décalés d'une heure.
L'importation de données du calendrier ne fonctionne que pour les données provenant du même calid
Si vous utilisez la fonction de haute disponibilité (via le package SUNWcsics HD de Calendar Server), après avoir procédé à une mise à niveau d'une ancienne version de Calendar Server vers Calendar Server 6.3, suivez la procédure ci-dessous pour ne pas rencontrer le problème 6560681.
Solution :
Supprimez manuellement le package SUNWscics fourni avec Calendar Server 6.3.
Utilisez la commande pkgadd pour ajouter le package SUNWscics intégré au logiciel Java Enterprise System.
Si vous déployez Calendar Server avec un serveur frontal et un serveur d'arrière-plan, ce qui nécessite l'utilisation du protocole DWP, le programme de configuration vous demande d'ajouter le nom d'hôte du serveur d'arrière-plan. Lorsqu'il enregistre cette valeur dans le paramètre caldb.dwp.server.hostname.ip de ics.conf, il l'enregistre en tant qu'adresse IP à la place du nom d'hôte complet qui devrait être enregistré. Cela signifie que le système n'est pas en mesure de trouver le serveur d'arrière-plan.
Solution :remplacez l'adresse IP par le nom d'hôte complet du serveur d'arrière-plan. Ceci peut se faire simplement en modifiant le fichier ics.conf, qui est un fichier texte.
Les instructions correctes concernant les valeurs à utiliser pour cette opération ainsi que d'autres paramètres utilisés pour configurer les serveurs (frontal et d'arrière-plan) se trouvent dans le Chapitre 5, Configuring Calendar Database Distribution Across Multiple Machines in Calendar Server Version 6.3 du Sun Java System Calendar Server 6.3 Administration Guide du Sun Java System Calendar Server Administration Guide.
Ce problème est reporté sous le problème n° 6542989 dans la section suivante de ces notes de version : Problèmes signalés dans Calendar Server 6.3 .
Sur le système d'exploitation Linux, après la mise à niveau vers Calendar Server 6.3, des messages d'erreur apparaissent dans le fichier http.log après l'exécution de start-cal:
cshttpd[2984] : erreur générale : caldb : caldb_pvt_isLocalUrl : le nom d'hôte de hostname.xyz.com ne peut pas être résolu. Vérifiez que le nom d'hôte est correct et que l'interpréteur du nom d'hôte est correct.
De plus, après une tentative de connexion, le message d'erreur suivant apparaît :
L'hôte d'arrière-plan ne peut pas être résolu. Veuillez réessayer.
Correction : le problème est corrigé dans Calendar Server 6.3 Mise à jour 1, patch numéro 121658-17.
Il s'agit du même problème que le problème n° 6516438 de la section suivante :Problèmes signalés dans Calendar Server 6.3 .
Les paramètres dupliqués sont autorisés dans le fichier de configuration ics.conf . Cela peut causer une certaine confusion sur la valeur du paramètre. Pour déterminer quelle instance de paramètre est utilisée par le système, recherchez la dernière instance dans le fichier. Le système utilise la valeur de la dernière instance du paramètre trouvé lors du traitement du fichier.
Meilleures pratiques : ajoutez toutes les modifications à la fin du fichier ics.conf dans une section intitulée, par exemple, # Mes modifications de paramètres. Pour conserver un historique des modifications apportées, ajoutez un commentaire décrivant les raisons la date correspondantes.
Mettez périodiquement en commentaire les anciennes modifications que vous n'utilisez plus. Si vous n'avez pas besoin d'un historique, supprimez les anciennes duplications non utilisées, conservant ainsi les dernières modifications dans le fichier.
Dans cette version, la substitution de chaînes dans les fichiers XSL ne s'effectue plus lors d'une étape de pré-traitement de la présentation. Par conséquent, les chaînes sont substituées en temps réel, ce qui entraîne une baisse des performances de l'interface utilisateur Calendar Express.
Solution : vous pouvez effectuer la substitution de chaînes avant d'exécuter Calendar Server en traitant l'ensemble des fichiers XSL et en insérant manuellement les chaînes de language correctes. Pour ce faire, vous devez ajouter le script perl (xslvarparser.pl ) se trouvant dans le répertoire { CAL_SERVER_BASE}/tools/unsupported/bin . Le script contient ses propres instructions d'exécution.
Par commodité, nous vous les reportons ci-dessous :
Utilisez le script perl xslvarparser.pl pour substituer les variables dans les fichiers XSL afin d'accélérer le rendu XSL.
Copiez ce fichier dans le répertoire /opt/SUNWics5/cal/html (répertoire par défaut sur Solaris).
Exécutez-le ensuite sous la forme $ perl xslvarparser.pl.
Les fichiers obtenus sont placés sous un répertoire out, dans chaque langue.
Remplacez les fichiers XSL dans chaque langue par les fichiers du répertoire out.
Nous vous recommandons d'enregistrer les fichiers d'origine avant d'effectuer cette substitution.
Ce problème est identique à celui décrit au n° 6385495 dans Problèmes signalés dans Calendar Server 6.3 .
Chaque commande set_userprefs supprime une seule instance de préférence à valeurs multiples.
Solution : pour supprimer toutes les instances d'une préférence utilisateur à valeurs multiples, vous devez exécuter une commande set_userpref pour chaque instance.
Exemple : exécutez get_userprefs pour lister toutes les préférences utilisateur. Si plusieurs valeurs sont associées à une même préférence, comme icsSubscribed, vous devez utiliser une commande set_userprefs pour supprimer chacune des valeurs de cette préférence.
Il n'existe aucune commande showrev propre au cluster qui indique les éléments installés sur chacun des nœuds du cluster. (Ce problème est général et ne concerne pas uniquement Calendar Server. Il s'applique à tout produit installé sur un système de fichiers global.)
Ce problème est particulièrement ennuyeux lorsque vous souhaitez mettre à jour Calendar Server. Vous devez appliquer le patch à chaque nœud sur lequel Calendar Server a été installé. De plus, vous ne pouvez pas appliquer le patch sur un nœud sur lequel Calendar Server n'a pas été installé. Si vous ne connaissez pas les nœuds qui disposent de Calendar Server, vous allez pour le moins perdre du temps à tenter de découvrir sur quels nœuds il est installé.
Solution : exécutez la commande suivante pour voir tous les nœuds sur lesquels Calendar Server est installé : pkgparam -v SUNWics5 | grep ACTIVE_PATCH
Certaines fenêtres de Calendar Server ne s'affichent pas si un programme de blocage de fenêtres contextuelles est activé.
Solution : désactivez les programmes de blocage de fenêtres contextuelles de l'URL de Calendar pour vous assurer que toutes les fenêtres Calendar Server s'afficheront.
Exception : ni Norton Inet Security AD_BLOCKER ni Mozilla built-in POP_BLOCKER n'affectent les fenêtres Calendar Server.
L'utilitaire csuser n'active pas les utilisateurs qu'il crée pour le carnet d'adresses.
Solution : activez l'utilisateur à l'aide de ldapmodify.
Le programme de configuration, csconfigurator.sh, ne configure qu'un seul domaine.
Solution : si vous avez besoin d'un environnement de calendrier à domaines multiples (appelés soit domaines virtuels, soit domaines hébergés), vous devez effectuer deux opérations :
Activez les domaines hébergés.
Ajoutez vous-même les domaines à l'aide de Delegated Administrator ou de l'utilitaire csdomain si vous utilisez toujours le schéma LDAP de Sun.
Reportez-vous au Chapitre 10, Setting Up a Multiple Domain Calendar Server 6.3 Environment du Sun Java System Calendar Server 6.3 Administration Guide et au Chapitre 13, Administering Calendar Server Domains du Sun Java System Calendar Server 6.3 Administration Guide.
(Également numéro de bogue 4777792) Le cache peut être rempli, ce qui entraîne des erreurs. Calendar Server n'expire pas les données de cache LDAP.
Solution : supprimez régulièrement le contenu du fichier. Redémarrez ensuite Calendar Server.
Le fichier de configuration demande deux fois le nom d'hôte, une fois le nom complet, puis le nom relatif. Exemple :
caldb.dwp.server.skate.red.sesta.com.ip = "skate.red.sesta.com" caldb.dwp.server.skate.ip = "skate" caldb.dwp.server.test12.red.sesta.com.ip = "test12.red.sesta.com" caldb.dwp.server.test12.ip = "test12"
Si des données non compatibles RFC se trouvent dans un jeton X, elles doivent être mises entre guillemets. Par exemple, deux points dans un jeton X doivent apparaître sous la forme ":".
L'utilitaire cscal de Calendar Server ne valide pas les utilisateurs avant de les ajouter à la liste des propriétaires comme propriétaires secondaires.
L'utilitaire de migration csmig de Calendar Server ne met pas à jour icsSubscribed avec les calendriers des propriétaires.
Celle-ci doit être effectuée manuellement.
Le service de notification d'événements a été désapprouvé. Ce bogue est insoluble. Utilisez Sun Java System Message Queue à la place.
Lorsqu'un utilisateur modifie un événement et choisit l'option de modifier l'événement du jour et tous les événements futurs, tous les événements antérieurs sont supprimés et ne sont plus affichés dans l'interface utilisateur.
Échec d'initialisation SSL en mode SSLv2. Impossible d'utiliser le client SSLv2.
Pour le schéma 1, vous devez créer les nœuds de l'arbre de composant de domaine avant de créer ou de gérer des calendriers.
Les messages d'erreur sont vagues car un message d'erreur est émis suite à la mise en échec de plusieurs niveaux pour diverses raisons. Le programme de niveau supérieur suivant n'interprète pas le message d'erreur avant de l'avoir fait passer au niveau supérieur.
Si vous lancez une description avec un espace à gauche, l'espace n'est pas stocké avec le texte et n'apparaît pas lorsque l'évènement est affiché.
Il s'agit d'une RFE qui n'a pas été implémentée pour cette version.
Les fichiers de verrouillage restants empêchent le redémarrage de Calendar Server. Supprimez-les avant de redémarrer.
Vous les trouverez dans le répertoire suivant :
/opt/sun/calendar/lib/lock/__db.001
Les dates du passage à l'heure d'été ont été modifiées. Le logiciel Calendar Server 6.3 contient les tables des fuseaux horaires corrigées. Tous les évènements et les tâches créés par la suite seront correctement configurés. En revanche, les évènements et tâches préexistants se produisant entre l'ancienne et la nouvelle date seront décalés d'une heure. Ce problème se produit deux fois par an, lors du passage à l'heure d'été et lors du passage à l'heure d'hiver.
Il s'agit du même problème que le problème n° 6502376 décrit dans Problèmes signalés dans Calendar Server 6.3 , plus loin dans ce document.
Correction :pour corriger ce problème, il faut permettre aux utilisateurs de régler les heures pour tous les évènements concernés dans leurs calendriers.
Il existe un programme de correction que le support technique peut fournir sur demande.
Vous ne pouvez pas utiliser la fonction d'importation pour déplacer des données entre les calendriers. Ces dernières ne peuvent être importées que dans le même calendrier (calid identique) que celui à partir duquel elles ont été exportées.
Cette restriction porte le n° 6461183 dans la section Problèmes signalés dans Calendar Server 6.3 de ce document.
La liste suivante répertorie les problèmes signalés sur le produit :
Pour un environnement de domaine hébergé, csexport requiert que calid ait un nom complet. Par exemple, au format uid@domain.
Fichier d'état non créé.
Lorsque csconfigurator.sh est appelé avec l'option -saveState , le fichier d'état spécifié n'inclut pas de chemin, alors celui-ci n'est pas créé. Exemple :
/opt/sun/calendar/sbin/csconfigurator.sh -saveState cs.state
Solution : indiquez toujours le chemin complet de l'emplacement où le fichier d'état doit être créé.
Le statut des invitations par défaut pour les calendriers de ressources devrait être Accepté.
Le statut des invitations doit être défini sur Accepté par défaut pour les calendriers de ressources car ceux-ci ne peuvent pas accepter d'invitations. Il se peut alors que les utilisateurs abonnés ne voient pas ces invitations (s'ils choisissent dans Communications Express->Options->Vue du calendrier de n'afficher que les invitations acceptées).
Solution :L'acceptation automatique des niveaux du serveur est déterminée par le paramètre resource.invite.autoaccept = "yes" de ics.conf. Elle peut également être déterminée par niveaux de ressource en utilisant l'attribut LDAP icsAutoaccept.
Problème avec les événements périodiques.
L'envoi dans les paramètres dtstart et dtend avec des modifications de champs qui ne sont pas de date (utilisation de storeevents) entraîne l'endommagement des données.
Solution : Ne définissez pas dtstart et dtend sur les commandes de modification de stockage nécessitant des modifications de champs qui ne sont pas de date.
Si Directory Server représente le schéma 2, et qu'aucun domaine n'a été créé, le programme de configuration de Calendar Server affiche un message d'erreur et n'autorise pas la configuration par rapport à ce Directory Server.
Ce problème a été résolu uniquement pour la version IG du programme de configuration. Pour la version ligne de commande, vous devez créer un domaine dans Delegated Administrator avant de configurer Calendar Server.
Après une mise à jour à partir de Java ES 2005Q1, la connexion unique à l'aide d'Access Manager ne fonctionne pas. Par exemple, lorsque vous vous connectez au bureau de Portal Server et tentez d'accéder à Calendar Server, la page de connexion apparaît au lieu d'être automatiquement authentifiée à travers une connexion unique.
Solution :il n'existe aucune solution à ce problème.
Après une mise à jour d'un déploiement de Calendar Server incluant des installations frontales et d'arrière-plan, les communications à l'aide de DWP, les tentatives de démarrage des installations frontales échouent, générant ainsi diverses erreurs dans le journal. Ce problème survient car les répertoires du cache n'ont pas été copiés vers la nouvelle installation.
Solution :copiez les répertoires cld_cache et ldap_cache de /var/opt/SUNWics5/csdb.old vers /var/opt/SUNWics5/csdb. Ensuite, définissez le propriétaire et le groupe des nouveaux répertoires sur icsuser et icsgroup.
Accumulation de fichiers journaux de base de données dans csdb.
Le démon du magasin lit un paramètre de fichier de configuration incorrect. Il recherche caldb.berkeley.*.enable, qui n'existe pas. Il prend ensuite le paramètre par défaut pour la journalisation circulaire qui est désactivée. Cela entraîne d'autres problèmes, notamment le blocage de la sauvegarde à chaud. Le paramètre ics.conf correct est caldb.berkeleydb.*.enable.
Solution :redémarrez les services. csstored se charge du problème d'accumulation des journaux en supprimant les fichiers journaux correspondants.
Impossible d'utiliser la fonction exportation/importation pour déplacer des données entre les calendriers avec des calid différents. Les données importées doivent avoir le même calid que le calendrier dans lequel vous les importez.
csrestore ne prend pas en compte le calendrier personnel des utilisateurs.
Après avoir créé un calendrier personnel et procédé à une sauvegarde avec succès, supprimez manuellement le calendrier personnel. Ensuite, restaurez-le à l'aide de la commande restore. À partir des fichiers journaux, vous pouvez vérifier si la restauration du calendrier a été effectuée avec succès. En revanche, il vous est impossible de voir ou de gérer un calendrier personnel lors de la journalisation vers UWC ou l'interface Calendar Express. Le problème est que csrestore ne prend pas en compte les entrées LDAP de l'utilisateur, ainsi que les calendriers abonnés ou personnels.
Solution :modifiez ou supprimez manuellement l'attribut à valeurs multiples, icsSubscribed pour chaque utilisateur, qui a été supprimé et restauré à l'aide de csrestore.
Corruption de la base de données de session provoquant des échecs de connexion et des messages de délai d'expiration de session excessifs.
Solution :
arrêtez les services.
Supprimez la base de données de session.
Lancez les services.
Aucun client JMQ n'est intégré aux packages Calendar. Utilisez le client JMQ du Messaging Server installé. L'échec de l'installation du client JMQ peut provoquer un arrêt anormal du processus admind
lorsque JMQ est activé.
Solution :copiez le client JMQ depuis le bundle Messaging Server.
Les évènements du calendrier sont décalés d'une heure entre le 11 mars 2007 et le 1er avril 2007.
Cela se produit car les dates du passage à l'heure d'été et à l'heure d'hiver ont été modifiées afin d'étendre la période de l'heure d'été. Les dates de changement d'heure ont lieu plus tôt au printemps (mars) et plus tard en automne (novembre) que les années précédentes. Le fichier de fuseau horaire distribué avec Calendar Server 6.3 a été mis à jour pour refléter ces modifications.
Pour Communications Express, qui utilise les informations de fuseau horaire de JVM au lieu du fichier de fuseau horaire de Calendar Server, vous devez mettre à jour votre JVM pour avoir les nouvelles modifications de fuseau horaire. Sun recommande l'utilisation de la dernière version mise à jour de Sun Java SE JDK/JRE comme outil préféré pour la distribution des mises à jour des données de fuseau horaire ainsi que toute autre amélioration produit, comme les corrections de sécurité. Utilisez le programme de mise à jour JVM comme décrit dans le document suivant :
http://java.sun.com/javase/tzupdater_README.html
Une fois les informations de votre fuseau horaire mises à jour, les évènements programmés avant cette mise à jour affichent un décalage d'une heure pour les jours situés entre l'ancienne et la nouvelle date de modification.
Il existe un correctif exécutable disponible auprès du service technique sur demande.
Une autre approche consiste simplement à demander aux utilisateurs de mettre à jour les heures des évènements situés entre les dates de transition. Sinon, exécutez votre propre script pour traiter la base de données pour les évènements nécessitant une mise à jour.
L'emplacement des outils LDAP a été modifié.
Si vous avez installé la version précédente (bêta) de Java Enterprise System, vous devez supprimer le package SUNWldapcsdk-tools avant d'installer la version commercialisée de Java Enterprise System 5. Ceci est dû au changement d'emplacement du package SUNWldapcsdk-tools dans la version commercialisée. Si vous ne supprimez pas ce package et que vous essayez de lancer Calendar ou Messaging Server après avoir installé la version commercialisée, vous obtiendrez le message d'erreur suivant :
Could not find .../bin/ldapsearch utility Please install the ldapcsdk-tools package |
Ce message d'erreur est dû au changement d'emplacement des outils LDAP.
Solution :supprimez le package SUNWldapcsdk-tools avant d'installer la version commercialisée de Java Enterprise System 5. Pour vérifier la version de SUNWldapcsdk-tools, exécutez la commande pkgparam -v SUNWldapcsdk-tools VERSION.
Votre version doit être 6.00,REV=2006.12.11.00.08 ou supérieure. Sinon, vous obtiendrez un message d'erreur indiquant que l'utilitaire de recherche LDAP n'a pas été trouvé.
Utilisez la commande pkgrm SUNWldapcsdk-tools pour supprimer le package SUNWldapcsdk-tools.
Si vous avez déjà exécuté le programme d'installation de Java Enterprise System 5, vous pouvez supprimer manuellement le package SUNWldapcsdk-tools et l'installer à l'aide de la commande :
cd <jes5_distro>/Solaris_sparc/Product/shared_components/Packages pkgadd -d . SUNWldapcsdk-tools |
Impossible de démarrer le serveur csmfagent sur une plate-forme Linux.
Les binaires du calendrier ne peuvent pas localiser les bibliothèques partagées pour Monitoring Framework sous Linux. Le chemin exact pour les fichiers de Monitoring Framework est le suivant : /opt/sun/mfwk/share/lib, mais Calendar Server s'attend à ce qu'il soit dans /opt/sun/calendar/lib.
Solution :ajoutez un lien symbolique vers la bibliothèque adéquate dans la bibliothèque de Calendar Server, comme indiqué dans l'exemple suivant :
# cd /opt/sun/calendar/lib # ln -s /opt/sun/mfwk/share/lib/*.so .
Sinon, vous pouvez démarrer les services du calendrier depuis la bibliothèque de Monitoring Framework, par exemple : /opt/sun/mfwk/share/lib
Sur une plate-forme Linux, impossible de se connecter après la mise à niveau vers Calendar Server 6.3.
Ceci est corrigé dans Calendar Server 6.3 Mise à niveau 1, patch n° 121658-17. Pour plus d'informations sur ce problème, consultez la section suivante de ces notes de version : Restrictions connues de Calendar Server.
Lorsque vous utilisez le programme de configuration pour configurer un serveur d'arrière-plan, il place de façon incorrecte l'adresse IP à la place du nom d'hôte complet dans le paramètre suivant :
caldb.dwp.server.hostname.ip
Vous devez modifier le fichier ics.conf pour corriger la valeur du paramètre, sinon le système ne sera pas en mesure de trouver le serveur d'arrière-plan. La valeur correcte est le nom d'hôte complet du serveur d'arrière-plan.
Le package haute disponibilité SUNWcsics requiert des mises à jour pour fonctionner correctement. Le package utilisé dans le logiciel Java Enterprise System est valide. Jusqu'à ce qu'un patch soit disponible pour corriger ce problème, procédez comme suit :
Supprimez manuellement le package SUNWcsics de votre distribution Calendar Server.
Exécutez la commande pkgadd en utilisant le package SUNWcsics de la distribution logicielle Java Enterprise System.