Bonjour à tous,

Désolé de polluer comme ça la liste depuis hier, mais je galère sur une
mise à jour de serveur à la suite d'un déménagement d'infrastructure...

J'ai installé il y a plusieurs années un serveur Alfresco, tout d'abord
en version 6.0 puis en version 6.1. Initialement, il tournait avec
Tomcat8 et au fur et à mesure des mises à jour Tomcat9.

J'ai eu beaucoup de mal à avoir un système fonctionnel. Une fois la configuration faite, je n'y ai plus touché.

Récemment, j'ai fait un dist-upgrade après le percement de sites SPIP.
Depuis, alfresco ne fonctionne plus et j'ai l'impression que le problème
se situe au niveau de Tomcat. Apache, je maîtrise, mais les machins
autour de Java ne sont pas ma tasse de thé.

La configuration de tomcat (que je peux fournir) n'a pas changé. J'ai naturellement vérifié sur les sauvegardes avec un diff -u.

J'ai l'impression que Tomcat se lance correctement. Un processus Java mouline durant une minute, le fichier catalina.out semble indiquer que
tout se passe correctement. Seul le connecteur entre Alfresco et
Libreoffice râle si je ne le tue pas à la main avant de relancer Tomcat.

Sauf que je ne peux même pas me connecter sur localhost:8080 pour interroger directement Tomcat. Pas d'erreur, la requête termine en
timeout. Tomcat semble pourtant commencer à répondre puisqu'il y a des paquets qui transitent sur le port 8080.

10:38:14.805214 IP legendre.systella.fr.60864 >
rayleigh.systella.fr.http-alt: Flags [.], ack 1, win 4480, options
[nop,nop,TS val 1 ecr 2794777751], length 0
10:38:14.805471 IP legendre.systella.fr.60864 >
rayleigh.systella.fr.http-alt: Flags [P.], seq 1:469, ack 1, win 4480,
options [nop,nop,TS val 1 ecr 2794777751], length 468: HTTP: GET / HTTP/1.1 10:38:14.805511 IP rayleigh.systella.fr.http-alt >
legendre.systella.fr.60864: Flags [.], ack 469, win 253, options
[nop,nop,TS val 2794777752 ecr 1], length 0
^C

J'ai bien mon processus qui tourne :

Root rayleigh:[/etc/tomcat9] > ps auwx | grep tomcat
tomcat 18743 0.0 0.5 667928 96640 ? Sl juil.02 0:00 /usr/lib/libreoffice/program/soffice.bin -accept=socket,host=127.0.0.1,port=2022;urp; -env:UserInstallation=file:///opt/alfresco/tmp/.jodconverter_socket_host-127.0.0.1_port-2022
-headless -nocrashreport -nodefault -nofirststartwizard -nolockcheck
-nologo -norestore
tomcat 30483 7.7 6.6 10155676 1081020 ? Sl 10:09 2:17 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/opt/alfresco/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.awt.headless=true -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Dorg.apache.catalina.security.SecurityListener.UMASK=0022 -Dignore.endorsed.dirs= -classpath /usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar -Dcatalina.base=/opt/alfresco -Dcatalina.home=/usr/share/tomcat9 -Djava.io.tmpdir=/opt/alfresco/tmp org.apache.catalina.startup.Bootstrap
start

Et le port est bien en écoute :

Root rayleigh:[/etc/tomcat8] > nmap 192.168.1.1
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-04 10:39 CEST
...
8080/tcp open http-proxy
...

Un autre point me semble étrange :
Root rayleigh:[/opt/alfresco/logs] > grep xml catalina.out
INFOS: Déploiement du descripteur de configuration [/etc/tomcat9/Catalina/localhost/share.xml]
INFOS: Le traitement du descripteur de déploiement [/etc/tomcat9/Catalina/localhost/share.xml] a pris [8 087] ms
INFOS: Déploiement du descripteur de configuration [/etc/tomcat9/Catalina/localhost/manager.xml]
AVERTISSEMENT: L'attribut path avec la valeur [/manager] dans le
descripteur de déploiement [/etc/tomcat9/Catalina/localhost/manager.xml]
a été ignoré
INFOS: Le traitement du descripteur de déploiement [/etc/tomcat9/Catalina/localhost/manager.xml] a pris [517] ms
INFOS: Déploiement du descripteur de configuration [/etc/tomcat9/Catalina/localhost/alfresco.xml]

Or j'ai plus de descripteurs dans le configuration de Tomcat :
Root rayleigh:[/etc/tomcat9/Catalina/localhost] > ls
alfresco.xml docs.xml host-manager.xml manager.xml share.xml solr.xml

Je n'ai aucune trace de ces descripteurs dans le lancement de tomcat. Aucune erreur.

Je ne sais plus où chercher et suis preneur de toute idée.

Bien cordialement,

JKB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonsoir à tous,

Trouvé... Enfin, j'ai trouvé le fautif, mais je ne sais pas trop comment résoudre le problème.

J'avais galéré pour installer Alfresco et j'avais utilisé la variable

CATALINA_BASE=/opt/alfresco

dans /etc/default/tomcat9. Ça fonctionnait très bien. Sauf que depuis la dernière mise à jour de tomcat9, ça ne fonctionne plus correctement.
J'ai retiré la variable en question et j'arrive à lancer tomcat sur la machine.

J'essaie donc de modifier les contexts de tomcat pour réussir à lancer
alfresco en rajoutant un path. Rien n'y fait.

J'ai par exemple ceci :

<?xml version='1.0' encoding='utf-8'?>
<Context crossContext="true">
<Resources>
<PostResources base="/opt/alfresco/modules/platform"

className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/lib"/>
</Resources>
</Context>

Comment rajouter le path là-dedans ? J'ai bien tenté un

<?xml version='1.0' encoding='utf-8'?>
<Context crossContext="true" docBase="/opt/alfresco">
<Resources>
<PostResources base="/opt/alfresco/modules/platform"

className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/lib"/>
</Resources>
</Context>

qui renvoie :
GRAVE: Erreur lors du déploiement du descripteur de configuration [/etc/tomcat9/Catalina/localhost/alfresco.xml]
java.lang.IllegalStateException: Erreur lors du démarrage du conteneur fils Caused by: org.apache.catalina.LifecycleException: Echec de démarrage du composant [org.apache.catalina.webresources.StandardRoot@d91e8c7]
at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4881)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5014)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726)
... 37 more
Caused by: java.lang.IllegalArgumentException: L'ensemble de ressources principal [/var/lib/tomcat9/webapps/alfresco] est invalide
at org.apache.catalina.webresources.StandardRoot.createMainResourceSet(StandardRoot.java:777)
at org.apache.catalina.webresources.StandardRoot.startInternal(StandardRoot.java:734)
at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
... 41 more

juil. 05, 2023 6:27:56 PM org.apache.catalina.startup.HostConfig deployDescriptor

Merci de toute idée...

Bien cordialement,

JB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Avertissement: si je n'ai pas répondu à ton précédent message c'est que
je suis totalement inculte sur le sujet

Y a un paragraphe de la doc Alfresco qui a l'air de s'intéresser aux
aspects du problème qui t'intéresse (regarde à "classpath"): https://docs.alfresco.com/content-services/7.2/install/zip/tomcat/#install-application-server

désolé si ça ne répond pas à la question tel que tu l'espérais: vu mon niveau j'en suis réduit aux conjectures, hein...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

didier gaumet a écrit :

Avertissement: si je n'ai pas répondu à ton précédent message c'est que je suis totalement inculte sur le sujet

Y a un paragraphe de la doc Alfresco qui a l'air de s'intéresser aux
aspects du problème qui t'intéresse (regarde à "classpath"): https://docs.alfresco.com/content-services/7.2/install/zip/tomcat/#install-application-server

désolé si ça ne répond pas à la question tel que tu l'espérais: vu mon niveau j'en suis réduit aux conjectures, hein...

Merci de t'être penché sur le sujet. J'avance de mon côté et il y a plusieurs problèmes qui se superposent. J'ai réussi à relancer Alfresco, mais il est bancal. J'essayerai de faire une réponse avec la résolution,
mais le problème est côté Tomcat, pas côté Alfresco.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 05/07/2023 à 22:24, BERTRAND Joël a écrit :

didier gaumet a écrit :

Avertissement: si je n'ai pas répondu à ton précédent message c'est que >> je suis totalement inculte sur le sujet

Y a un paragraphe de la doc Alfresco qui a l'air de s'intéresser aux
aspects du problème qui t'intéresse (regarde à "classpath"):
https://docs.alfresco.com/content-services/7.2/install/zip/tomcat/#install-application-server


désolé si ça ne répond pas à la question tel que tu l'espérais: vu mon >> niveau j'en suis réduit aux conjectures, hein...

Merci de t'être penché sur le sujet. J'avance de mon côté et il y a plusieurs problèmes qui se superposent. J'ai réussi à relancer Alfresco, mais il est bancal. J'essayerai de faire une réponse avec la résolution, mais le problème est côté Tomcat, pas côté Alfresco.

Bon alors mon niveau de compréhension de ton problème ressemble assez à celui de la vache qui regarde passer le train, relativement au mode de locomotion de celui-ci ;-)

Mais ceci étant, le lien -bien qu'extrait du site Alfresco- que je t'ai indiqué semble justement expliquer comment installer et configurer
*Tomcat* pour le bon fonctionnement d'Alfresco, entre autres les
chemins, mais pas seulement

Mais bon, j'ai peut-être rien compris, hein :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

didier gaumet a écrit :

Mais ceci étant, le lien -bien qu'extrait du site Alfresco- que je t'ai indiqué semble justement expliquer comment installer et configurer
*Tomcat* pour le bon fonctionnement d'Alfresco, entre autres les
chemins, mais pas seulement

Mais bon, j'ai peut-être rien compris, hein :-)

Mais si, mais si... Mais le problème n'est pas exactement là. Ce ne sont pas les classes qui ne sont pas trouvées, mais le fait que ces
classes appellent des scripts et des binaires dans le /bin local
d'alfresco. Et tomcat cherche ces bouts de code dans $CATALINA_HOME et $CATALINA_BASE. Avant la mise à jour de tomcat, j'avais rusé en collant
l'une des deux variables vers la racine d'installation d'alfresco, ce
qui ne fonctionne plus aujourd'hui.

En d'autres termes, toutes les classes sont bien trouvées, ce sont les programmes annexes qui manquent à l'appel.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 06/07/2023 à 08:26, BERTRAND Joël a écrit :

didier gaumet a écrit :

Mais ceci étant, le lien -bien qu'extrait du site Alfresco- que je t'ai
indiqué semble justement expliquer comment installer et configurer
*Tomcat* pour le bon fonctionnement d'Alfresco, entre autres les
chemins, mais pas seulement

Mais bon, j'ai peut-être rien compris, hein :-)

Mais si, mais si... Mais le problème n'est pas exactement là. Ce ne sont pas les classes qui ne sont pas trouvées, mais le fait que ces
classes appellent des scripts et des binaires dans le /bin local
d'alfresco. Et tomcat cherche ces bouts de code dans $CATALINA_HOME et $CATALINA_BASE. Avant la mise à jour de tomcat, j'avais rusé en collant l'une des deux variables vers la racine d'installation d'alfresco, ce
qui ne fonctionne plus aujourd'hui.

En d'autres termes, toutes les classes sont bien trouvées, ce sont les programmes annexes qui manquent à l'appel.

J'espère que je n'insiste pas de manière déplaisante vu que j'ai peine à comprendre globalement ce dont on parle,

mais ce qui suit (extrait du lien précédent) ne concerne-t-il pas
justement la configuration dans Tomcat de l'emplacement des classes *et*
des bibliothèques (je crois comprendre confusément que c'est ce qui te manque)?

[...]
"
Create an additional classpath to Tomcat, which will be shared among all
web applications.

Create the directories required for a Content Services installation
under <TOMCAT_HOME>:
Create the shared/classes directory.
Create the shared/lib directory.

Open the <TOMCAT_HOME>/conf/catalina.properties file.

Change the value of the shared.loader= property to the following:


shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar "
[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

didier gaumet a écrit :

Le 06/07/2023 à 08:26, BERTRAND Joël a écrit :

didier gaumet a écrit :

Mais ceci étant, le lien -bien qu'extrait du site Alfresco- que je t'ai >>> indiqué semble justement expliquer comment installer et configurer
*Tomcat* pour le bon fonctionnement d'Alfresco, entre autres les
chemins, mais pas seulement

Mais bon, j'ai peut-être rien compris, hein :-)

    Mais si, mais si... Mais le problème n'est pas exactement là. Ce ne
sont pas les classes qui ne sont pas trouvées, mais le fait que ces
classes appellent des scripts et des binaires dans le /bin local
d'alfresco. Et tomcat cherche ces bouts de code dans $CATALINA_HOME et
$CATALINA_BASE. Avant la mise à jour de tomcat, j'avais rusé en collant
l'une des deux variables vers la racine d'installation d'alfresco, ce
qui ne fonctionne plus aujourd'hui.

    En d'autres termes, toutes les classes sont bien trouvées, ce sont >> les
programmes annexes qui manquent à l'appel.

J'espère que je n'insiste pas de manière déplaisante vu que j'ai peine à comprendre globalement ce dont on parle,

mais ce qui suit (extrait du lien précédent) ne concerne-t-il pas
justement la configuration dans Tomcat de l'emplacement des classes *et*
des bibliothèques (je crois comprendre confusément que c'est ce qui te manque)?

[...]
"
Create an additional classpath to Tomcat, which will be shared among all
web applications.

    Create the directories required for a Content Services installation under <TOMCAT_HOME>:
        Create the shared/classes directory.
        Create the shared/lib directory.

    Open the <TOMCAT_HOME>/conf/catalina.properties file.

    Change the value of the shared.loader= property to the following:

shared.loader=${catalina.base}/shared/classes,${catalina.base}/shared/lib/*.jar

"

Si, c'est bien ça. Mais Alfresco utilise aussi une foultitude de scripts et ça met un bazar sans nom dans les fichiers de conf dont les
chemins sont par défaut CATALINA_HOME.

La seule solution simple, c'est de suivre la doc en question *en installant alfresco dans /var/lib/tomcat9*. Sinon, alfresco se lance
mais tomcat ne répond plus. Antérieurement, ça fonctionnait pourtant
bien, c'est ce que j'avais installé. Mais depuis la dernière mise à jour
de tomcat, ça coince.

J'en suis à avoir les deux services tomcat share et alfresco qui tournent, j'arrive à me connecter, mais je n'ai accès à aucun de mes fichiers. Il me reste un access denied sur un script et je ne vois pas
encore où.

2023-07-06 12:25:10,484 INFO [web.site.EditionInterceptor] [ajp-nio-127.0.0.1-8009-exec-1] Successfully retrieved license
information from Alfresco.
2023-07-06 12:25:12,181 ERROR [extensions.webscripts.AbstractRuntime] [http-nio-8080-exec-4] Exception from executeScript: 06060040 Access
refusé. Vous n'avez pas la permission de réaliser cette opération. org.alfresco.repo.security.permissions.AccessDeniedException: 06060040
Access refusé. Vous n'avez pas la permission de réaliser cette opération.
at org.alfresco.repo.security.permissions.impl.ExceptionTranslatorMethodInterceptor.invoke(ExceptionTranslatorMethodInterceptor.java:57)

JB

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 06/07/2023 à 13:58, BERTRAND Joël a écrit :
[...]

org.alfresco.repo.security.permissions.AccessDeniedException: 06060040
Access refusé. Vous n'avez pas la permission de réaliser cette opération.
at org.alfresco.repo.security.permissions.impl.ExceptionTranslatorMethodInterceptor.invoke(ExceptionTranslatorMethodInterceptor.java:57)

Peut-être une piste là (peut-être aussi à adapter concernant un objet différent) : https://hub.alfresco.com/t5/alfresco-content-services-forum/controlling-user-access-to-shared-files/td-p/13103

Bon, désolé, je m'arrête là parce qu'on est depuis longtemps très en dehors de mon champ de compétences ;-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Etienne Vogt a écrit :

Une possible piste est que tomcat9 a des protections additionnelles par rapport à tomcat8, donc si on installe une servlet ailleurs que dans les chemins par défaut, il faut autoriser l'accès dans /etc/systemd/system/tomcat9.service

Par ex. pour un IdP Shibboleth sous tomcat9, j'ai du ajouter :

ReadWritePaths=/opt/shibboleth-idp/logs/ ReadWritePaths=/opt/shibboleth-idp/metadata/

pour que cela fonctionne.

Merci de vous être penché sur le sujet. C'était déjà un tomcat9 avec ces ReadWritePaths. Alfresco est un truc à s'arracher les cheveux lors
de l'installation (je pense que c'est fait pour que les gens prennent le support payant). Après quelques frayeurs concernant l'intégrité des
données, j'y suis arrivé.

Il y a des chemins qui sont maintenant codés en dur. C'est ça qui pose problème. Et il ne faut pas oublier de patcher les jar grâce à l'outil
solr (celui fourni par alfresco dans un second package, le jar originel
ne suffit pas). De la même manière, le jodconverter est tout cassé (il
faut filer un chemin sur la ligne de commande qui n'est pas celui qui
est retourné dans l'erreur Java). Sans compter que le solr fourni
demande dans la doc java 8 et qu'il est compilé... pour fonctionner à
partir de la 11.

Je vais essayer d'écrire un tuto sur l'installation d'Alfresco sur Debian/Devuan.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour,

On Thu, 6 Jul 2023, BERTRAND Joël wrote:

Si, c'est bien ça. Mais Alfresco utilise aussi une foultitude de scripts et ça met un bazar sans nom dans les fichiers de conf dont les chemins sont par défaut CATALINA_HOME.

La seule solution simple, c'est de suivre la doc en question *en installant alfresco dans /var/lib/tomcat9*. Sinon, alfresco se lance
mais tomcat ne répond plus. Antérieurement, ça fonctionnait pourtant
bien, c'est ce que j'avais installé. Mais depuis la dernière mise à jour
de tomcat, ça coince.

J'en suis à avoir les deux services tomcat share et alfresco qui tournent, j'arrive à me connecter, mais je n'ai accès à aucun de mes fichiers. Il me reste un access denied sur un script et je ne vois pas
encore où.

Une possible piste est que tomcat9 a des protections additionnelles par
rapport à tomcat8, donc si on installe une servlet ailleurs que dans les chemins par défaut, il faut autoriser l'accès dans /etc/systemd/system/tomcat9.service

Par ex. pour un IdP Shibboleth sous tomcat9, j'ai du ajouter :

ReadWritePaths=/opt/shibboleth-idp/logs/ ReadWritePaths=/opt/shibboleth-idp/metadata/

pour que cela fonctionne.

--
Etienne Vogt (Etienne.Vogt@obspm.fr)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)