Problème utilisation Postscriptum

Bonjour,

J’ai un souci avec l’extension postscriptum. Nous sommes en train de basculer un scServer 4.2 de Opale 3.7 à 3.7 et installation de postscriptum.

  • J’ai récupéré le paquet postscriptum-app-v0.8.008-linux.deb depuis gltlab et lancé l’install sur le serveur (dpkg -i postscriptum-app-v0.8.008-linux.deb).
  • Le wsppack est installé et lors de la génération de contenu on récupère une erreur dont la trace est ci-dessous.
  • J’ai tenté la même manip sur un scServer 5.0 et le même message apparaît.

Est-ce que j’ai raté quelque-chose dans l’installation du paquet ?

Merci d’avance
Franck

Traces de 'Publication PDF (Postscriptum)' pour l'item '/BugExportPDF/BugExportPDF_papier.publi'

--- User details ---
Générateur: gen_printPs - Publication PDF (Postscriptum)
Item racine: /BugExportPDF/BugExportPDF_papier.publi
*      [exec] Result: 1
* events.js:183
* Error: read ECONNRESET
* Generation failed.
  - Postscriptum could not produce the PDF.


--- Admin details ---
<?xml version="1.0" encoding="UTF-8"?>
<trace>
	<start t="07/02/20 09:56:40"/>
	<l t="Error" d="07/02/20 09:56:41">
		<message type="Error" ts="1581065801855" appCtx="chain" user="XXXX" thread="chain-executor-7" desc="     [exec] Result: 1"/>
	</l>
	<l t="Error" d="07/02/20 09:56:41">
		<message type="Error" ts="1581065801879" appCtx="chain" user="XXXX" thread="chain-executor-7" desc="events.js:183">
			<details>events.js:183
      throw er; // Unhandled 'error' event
      ^
</details>
		</message>
	</l>
	<l t="Warning" d="07/02/20 09:56:41">
		<message type="Warning" ts="1581065801880" appCtx="chain" user="XXXX" thread="chain-executor-7" desc=""/>
	</l>
	<l t="Error" d="07/02/20 09:56:41">
		<message type="Error" ts="1581065801880" appCtx="chain" user="XXXX" thread="chain-executor-7" desc="Error: read ECONNRESET">
			<details>Error: read ECONNRESET
    at Pipe.onread (net.js:622:25)
</details>

Bonjour @franck_rouze ,

Peux-tu vérifier que tomcat/jetty dispose des droits sur /opt/postscriptum, notamment l’id du propriétaire (uid/gid)

A+

Xavier

Sinon un problème de parefeu réseau qui bloquerait un flux entre le serveur et une autre machine distante avec laquelle il rentre en communication ?

Bonne idée les droits étaient placés à l’installation sur systemd-network:nogroup
J’ai bascculé sur tomcat8:tomcat8 mais ça ne tourne pas mieux pour autant. Par contre l’erreur est légèrement différente, ça ne fait plus référence à event.js

Traces de 'Publication PDF (Postscriptum)' pour l'item '/BugExportPDF/BugExportPDF_papier.publi'

--- User details ---
Générateur: gen_printPs - Publication PDF (Postscriptum)
Item racine: /BugExportPDF/BugExportPDF_papier.publi
*      [exec] Result: 1
* { Error: Protocol error (Target.setDiscoverTargets): Target closed.
* Generation failed.
  - Postscriptum could not produce the PDF.

Peut-tu lancer postscriptum en ligne de commande ?

En effet, le plus simple est de tester un appel pour avoir un log d’erreur plus complet. Voici un exemple :

sudo -u tomcat8 /opt/postscriptum/bin/postscriptum https://css4.pub/2018/toc/index.html -o /tmp/test.pdf

Ok voici ce que ça donne :
J’ai lancé plusieurs fois la commande, ne me demandes pas pourquoi. Ce qui est étrange c’est que j’ai eu deux fois le résultat suivant :

 sudo -u tomcat8 /opt/postscriptum/bin/postscriptum https://css4.pub/2018/toc/index.html -o /tmp/test.pdf
{ Error: Protocol error (Target.setDiscoverTargets): Target closed.
    at Promise (/opt/postscriptum/cli/node_modules/puppeteer/lib/Connection.js:74:56)
    at new Promise (<anonymous>)
    at Connection.send (/opt/postscriptum/cli/node_modules/puppeteer/lib/Connection.js:73:12)
    at Function.create (/opt/postscriptum/cli/node_modules/puppeteer/lib/Browser.js:34:22)
    at Launcher.launch (/opt/postscriptum/cli/node_modules/puppeteer/lib/Launcher.js:177:37)
    at <anonymous>
  message: 'Protocol error (Target.setDiscoverTargets): Target closed.' }

Et les autres fois le résultat suivant :

sudo -u tomcat8 /opt/postscriptum/bin/postscriptum https://css4.pub/2018/toc/index.html -o /tmp/test.pdf
events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at Pipe.onread (net.js:622:25)

Postscriptum n’arrive pas à communiquer avec le processus Chromium. Je te propose d’essayer de le lancer manuellement :

/opt/postscriptum/chromium/chrome --headless --remote-debugging-port=9222

Salut David,

Merci pour ta réponse.

Si je lance la commande
/opt/postscriptum/chromium/chrome --headless --remote-debugging-port=9222
sur un compte standard j’obtiens l’erreur fatale suivante au lancement de la commande

[0210/091844.241145:FATAL:zygote_host_impl_linux.cc(116)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
#0 0x559d4d02af29 base::debug::CollectStackTrace()
#1 0x559d4cf90593 base::debug::StackTrace::StackTrace()
#2 0x559d4cfa4d1e logging::LogMessage::~LogMessage()
#3 0x559d4e60d90e service_manager::ZygoteHostImpl::Init()
#4 0x559d4cbe61b7 content::ContentMainRunnerImpl::Initialize()
#5 0x559d4cc18fca service_manager::Main()
#6 0x559d4cbe4791 content::ContentMain()
#7 0x559d51280178 headless::(anonymous namespace)::RunContentMain()
#8 0x559d51280205 headless::HeadlessBrowserMain()
#9 0x559d4cc17ca3 headless::HeadlessShellMain()
#10 0x559d4ab4f1ac ChromeMain
#11 0x7fecb50222e1 __libc_start_main
#12 0x559d4ab4f02a _start

Received signal 6
#0 0x559d4d02af29 base::debug::CollectStackTrace()
#1 0x559d4cf90593 base::debug::StackTrace::StackTrace()
#2 0x559d4d02aab1 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7fecbb1b10e0 <unknown>
#4 0x7fecb5034fff gsignal
#5 0x7fecb503642a abort
#6 0x559d4d0298e5 base::debug::BreakDebugger()
#7 0x559d4cfa4f61 logging::LogMessage::~LogMessage()
#8 0x559d4e60d90e service_manager::ZygoteHostImpl::Init()
#9 0x559d4cbe61b7 content::ContentMainRunnerImpl::Initialize()
#10 0x559d4cc18fca service_manager::Main()
#11 0x559d4cbe4791 content::ContentMain()
#12 0x559d51280178 headless::(anonymous namespace)::RunContentMain()
#13 0x559d51280205 headless::HeadlessBrowserMain()
#14 0x559d4cc17ca3 headless::HeadlessShellMain()
#15 0x559d4ab4f1ac ChromeMain
#16 0x7fecb50222e1 __libc_start_main
#17 0x559d4ab4f02a _start
  r8: 0000000000000000  r9: 00007ffeabb6ed50 r10: 0000000000000008 r11: 0000000000000246
 r12: 00007ffeabb6efe8 r13: 0000000000000161 r14: 00007ffeabb6f950 r15: 00007ffeabb6f948
  di: 0000000000000002  si: 00007ffeabb6ed50  bp: 00007ffeabb6ef90  bx: 0000000000000006
  dx: 0000000000000000  ax: 0000000000000000  cx: 00007fecb5034fff  sp: 00007ffeabb6edc8
  ip: 00007fecb5034fff efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.

Si je la lance en root :

[0210/092723.550580:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.

Bonjour Franck,

Nous avons déjà rencontré ce type de problème avec Docker. Le serveur est-il lancé dans un container ? Sinon, peux-tu nous donner des détails sur la machine ?

Le paramètre --no-sandbox devrait être accepté si tu lances chromium avec l’utilisateur tomcat :

sudo -u tomcat8 /opt/postscriptum/chromium/chrome --headless --remote-debugging-port=9222 --no-sandbox

PS accepte une variable d’environnement PS_NO_CHROMIUM_SANDBOX pour lancer chromium de cette manière
sudo -u tomcat8 PS_NO_CHROMIUM_SANDBOX="true" /opt/postscriptum/bin/postscriptum https://css4.pub/2018/toc/index.html -o /tmp/test.pdf

La VM est une Debian 9.x avec install SC42 par paquet deb (dépot scenari) donc sans utiliser docker

Au lancement de la commande
sudo -u tomcat8 /opt/postscriptum/chromium/chrome --headless --remote-debugging-port=9222 --no-sandbox
J’ai le message suivant :

Fontconfig warning: "/etc/fonts/fonts.conf", line 100: unknown element "blank"
Home directory not accessible: Permission non accordée

DevTools listening on ws://127.0.0.1:9222/devtools/browser/adf21a19-d06e-4be7-9f18-71b64e792907
[0210/100829.522777:WARNING:ipc_message_attachment_set.cc(49)] MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[0210/100829.521569:WARNING:ipc_message_attachment_set.cc(49)] MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[0210/100829.521586:ERROR:command_buffer_proxy_impl.cc(125)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.

mais au lancement de la seconde commande :

sudo -u tomcat8 PS_NO_CHROMIUM_SANDBOX="true" /opt/postscriptum/bin/postscriptum https://css4.pub/2018/toc/index.html -o /tmp/test.pdf

Tout semble ok et j’ai bien génération d’un PDF dans /tmp

Il est possible de faire fonctionner le sandbox de Chromium sur Debian en activant une fonctionnalité du kernel (nommée « user namespace cloning »).

Il vaut mieux utiliser cette méthode (qui ne fonctionne pas sur Docker) que désactiver complètement le sandbox.

Voici les commandes pour l’activer et pour qu’elle soit prise en compte à chaque démarrage.

echo kernel.unprivileged_userns_clone=1 > /etc/sysctl.d/00-local-userns.conf
sysctl --system

Postscriptum devrait fonctionner ensuite.
Nous avons compléter la documentation d’installation et je vais essayer de produire un message d’erreur plus pertinent.

A bientôt,

David

Re David

Je viens de lancer la commande et effectivement ça fonctionne. Même si je n’ai pas tout pigé à tout ça, il semble que niveau sécurité ce paramétrage assez moyen. Je me trompe ?

A+

oui

non, ça ne devrais pas être nécessaire mais dans mes containers Scenari LXC c’est le cas!

cat /proc/sys/kernel/unprivileged_userns_clone
1

c’est spécifique au Kernel de Debian et c’est assez étrange que tu ais besoin de le faire dans une VM. Je vais faire des tests de mon côté…

Merci Xavier pour tes investigations.
Heu ! petit point d’infrmation qui pourrait peut-être être utile. L’accès via HTTPS sur la VM se fait via un reverse proxy qui se trouve dans l’infra de mon université et pas directement sur le serveur lui même. Est-ce qu’il ne peut pas y avoir un souci d’ouverture de port ?

Le fait de pouvoir désactiver cette fonctionnalité est en effet une spécificité de Debian : ce patch a été refusé par le kernel Linux. Il faut donc relativiser le risque au niveau sécurité : cette fonctionnalité, dont le but est justement d’améliorer la sécurité pour des applications tel que Chrome, est active et non désactivable sur les distributions non Debian.

Le client ne communique pas directement avec PS. Le proxy n’a donc pas de répercussion sur son fonctionnement.

Bonjour,

Après avoir fait des tests de sécurité et en avoir discuté avec d’autres dev. système, les deux options de configuration pour Postscritum se valent en terme de risques.

Il est donc aussi valide dans ton cas d’utilisation, c’est à dire une VM GNU/Debian de type serveur dédiée au fonctionnement de Scenari dont seul tomcat va utiliser Postscriptum (chromium):

  • d’activer « unprivileged_userns_clone » au niveau du noyau du système
  • de ne pas utiliser la sandbox de Chrome/Chromium

En revanche il n’est absolument pas nécessaire d’activer cette fonctionnalité du noyau si on n’utilise pas GNU/Debian avec des conteneurs ou pour utiliser Chrome/Chromium.

Cette fonctionnalité n’est pas désactivée, elle n’est juste pas activée à la compilation du noyau par les dev. Debian en charge de la maintenance du noyau.

Ce n’est pas leur patche qui a été refusé mais c’est toute modification concernant le contrôle de cette fonctionnalité qui a été refusée ! Il suffit de lire l’historique des échanges et surtout la position de Kees Cook pour s’en convaincre.

Les dev. Debian permettent donc à l’admin d’activer ou pas cette fonctionnalité en cas de besoin sinon il ne reste alors pour l’admin. que la possibilité de recompiler le noyau, ce qui est le cas pour la grande majorité des distributions GNU/Linux.

Cordialement,

Xavier

PS: Pour mieux comprendre les concepts d’espace utilisateur, on peut lire le man

Bonjour Xavier,

Je te remercie pour tes recherches et cette explication très complète.

Cordialement
Franck