Paketverwaltung Problem open_basedir, composer

[x4all]

Hallo zusammen, habe ein Contao 3.5.6, bei Klick auf die Paketverwaltung kracht es. Alles andere funktioniert normal. Testweise schon ein jungfräuliches Contao aufgesetzt, gleiches Problem. Es erscheinen Allerhand Warnings und ein Fatal Error, z.B.

Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): (/var/www/xxx/htdocs/public:/var/www/xxxxx/tmp) in phar://composer/composer.phar/src/Composer/Util/RemoteFilesystem.php on line 894

Warning: is_dir(): open_basedir restriction in effect. File(/etc/ssl/certs) is not within the allowed path(s): (/var/www/xxx/htdocs/public:/var/www/xxxxx/tmp) in phar://composer/composer.phar/src/Composer/Util/RemoteFilesystem.php on line 894

Und der Fatal Error:

Fatal error: Uncaught exception Composer\Downloader\TransportException with message The configured cafile was not valid or could not be read. thrown in phar://composer/composer.phar/src/Composer/Util/RemoteFilesystem.php on line 801

Contao möchte also Zugriff auf die Debian SSL Zertifikatsverwaltung /etc/ssl/certs, /etc/ssl, /usr/local/share/certs, /usr/share/ssl/certs etc.

Open_basedir ist in der php.ini richtig gesetzt. Was läuft denn hier schief?

[Spooky]

Open_basedir ist in der php.ini richtig gesetzt. Was läuft denn hier schief?

Auf welchen Wert ist open_basedir laut phpinfo(); gesetzt?

[x4all]

Das ist:

/var/www/contao.xxx.de/htdocs/public:/var/www/contao.xxx.de/tmp

[Spooky]

Laut Fehlermeldung braucht er aber zusätzlich /etc/pki/tls/certs und /etc/ssl/certs

[x4all]

Schon, nur da liegt soweit ich weiß die komplette Zertifikatsverwaltung von Debian. Wenn Contao also eine Sicherheitslücke oder sonst was hätte, könnte man damit ja den gesamten Server übernehmen. Ist das bei allen Hostern so, dass ein CMS grundsätzlich Zugriff auf diese sensiblen Verzeichnisse braucht?

[Spooky]

Das kann ich dir leider auch nicht beantworten. Den Thread hättest du im composer Forum posten sollen - sollte ein Moderator verschieben.

[Ulrich]

Ich habe seit gestern das gleiche Problem ...

[x4all]

@ Ullirch: Auch auf Contao 3.5.6 beim Klick auf die Paketverwaltung? Bei welchem Hoster ist das?

[Ulrich]

@ Ullirch: Auch auf Contao 3.5.6 beim Klick auf die Paketverwaltung? Bei welchem Hoster ist das?

Meine Installation wird bei Alfahosting gehostet und läuft unter Contao 3.5.6. Ich musste erst kürzlich mit entsprechenden Einträgen in der initconfig.php die Pfade für "TMP" und "COMPOSER_HOME" setzen, danach lief der Composer (wieder).

Bei Alfahosting enthält die open_basedir folgende Pfade: "/var/www/.../html/", "/var/www/.../phptmp/", "/var/www/.../files/", "/var/www/.../atd/", "/usr/share/php/" und "/opt/php/". Die Composer-Entwickler verweisen offenbar auf eine unzureichende oder "fehlerhafte" Konfiguration beim Hoster ...

[x4all]

Kannst du mal beide Einträge (initconfig und open_basedir) posten?

[Ulrich]

Kannst du mal beide Einträge (initconfig und open_basedir) posten?

Die Einträge in der initconfig.php:

<?php

// Put your custom configuration here
putenv('COMPOSER_HOME=' . TL_ROOT);
putenv('TMP=' . TL_ROOT . '/system/tmp');
putenv('TEMP=' . TL_ROOT . '/system/tmp');
putenv('TMPDIR=' . TL_ROOT .  '/system/tmp');

open_basedir entspricht den Einträgen, die ich in meiner vorigen Antwort aufgelistet habe ...

[x4all]

Und du bekommst die gleichen Fehlermeldungen auf die Pfade die ich gepostet habe?

[Ulrich]

Und du bekommst die gleichen Fehlermeldungen auf die Pfade die ich gepostet habe?

Im Prinzip ja:

Warning: is_readable(): open_basedir restriction in effect. File(/etc/pki/tls/certs/ca-bundle.crt) is not within the allowed path(s) ...

[x4all]

Vielelicht sollten wir mal ein Ticket bei Github aufmachen?

[Ulrich]

Vielelicht sollten wir mal ein Ticket bei Github aufmachen?

Das kannst Du gerne machen, ich habe inzwischen bei Alfahosting ein Support-Ticket erstellt, mit der Frage, ob die Konfiguration der open_basedir grundsätzlich angepasst werden kann. Ich werde die Antwort von Alfahosting hier mitteilen ...

[hofff]

¡Hola,

das Problem liegt nicht auf der Seite von Contao oder unserer Composerimplementierung, sondern an Composer selbst. Ich bin vor ein paar Tagen auch darüber gestolpert. Mit der neuen Version wurde eine Zertifikatsprüfung eingebaut, die an den bekannten Orten nach Zertifikaten sucht. Durch die open_basedir Beschränkung ist dieses Verzeichnis aber verboten und das findet Composer halt gar nicht so gut. Der Zugriff auf auf diese Zertifikate ist aber grundsätzlich unproblematisch, denn es ist ungefähr so, als wenn man einem Programm auf dem PC verbietet, auf lokale Zertifikate zuzugreifen.

Was er genau da mit den Zertifikaten abgleichen möchte, kann ich aktuell nicht sagen, da müsste Xtra was dazu sagen können. Ich versuche da mal was in Erfahrung zu bringen.

fg
nicky

[Ulrich]

¡Hola,

das Problem liegt nicht auf der Seite von Contao oder unserer Composerimplementierung, sondern an Composer selbst. Ich bin vor ein paar Tagen auch darüber gestolpert. Mit der neuen Version wurde eine Zertifikatsprüfung eingebaut, die an den bekannten Orten nach Zertifikaten sucht. Durch die open_basedir Beschränkung ist dieses Verzeichnis aber verboten und das findet Composer halt gar nicht so gut. Der Zugriff auf auf diese Zertifikate ist aber grundsätzlich unproblematisch, denn es ist ungefähr so, als wenn man einem Programm auf dem PC verbietet, auf lokale Zertifikate zuzugreifen.

Was er genau da mit den Zertifikaten abgleichen möchte, kann ich aktuell nicht sagen, da müsste Xtra was dazu sagen können. Ich versuche da mal was in Erfahrung zu bringen.

fg
nicky

Vielen Dank für die Rückmeldung. Wer also die open_basedir Beschränkung vom Hoster auf's Auge gedrückt bekommt, ist momentan gekniffen und kann nichts tun, außer den Hoster wechseln? Blöde nur, wenn man in einem Vertrag mit Mindestlaufzeit noch einige Monate gebunden ist ...

[baumbaTz]

Schon komisch. Hab nun bei unserem eigentlichen Hoster gerade mal eine nackte Contao 3.5.6 Installation durchgeführt und bekomme beim Installieren von Composer die gleichartige Fehlermeldung wie x4all.

Habe dann bei HostEurope versucht, weil ich ziemlich sicher bin, dort mal Composer testweise am laufen gehabt zu haben... dort bekomme ich von Contao dann nur die nette Meldung, dass ich doch bitte dringend Suhosin deinstallieren soll.

Ob das wohl beides die gleiche Ursache hat? Sehr verwirrend. Konnte mich bisher noch nich so recht mit composer anfreunden und sowas hilft auch nur bedingt.

bisdenndann
björn

[x4all]

@ Nicky: Erstmal besten Dank für die ausführliche Antwort, denke das klärt schon mal auf.

Ich hatte mit meinem Hoster gesprochen, in unserem Fall ist das ein Debian 7 mit PHP 5.6. Der Admin meinte, dass es wohl sehr problematisch ist die Zertifikatsverwaltung freizugeben, denn wenn Contao Sicherheitslücken hätte, kann man auf die kompletten Zertifikate zugreifen.

Nur als Vorschlag: Vielleicht könnte man mal eine Skype-Konferenz oder sowas machen, in der sich z.B. ein Serveradmin, Xtra, ich, oder alle die Interesse haben unterhalten? So wie es ausschaut, scheint das ja mehrere Installationen zu betreffen. Was meint Ihr dazu?

VG
Jan

[hofff]

Hallo,

also es hat primär erstmal nichts mit einer neuen oder alten Contao-Installation zu tun, sondern nur mit der Version der composer.phar unter CT_ROOT/composer ... wenn ihr mit eurem Hoster auf die schnelle keine Lösung findet, dann gebe ich Euch einen kleinen Tipp:

1. sucht euch ein System, was aktuell ist und wo die Paketverwaltung noch läuft
2. geht via FTP auf diesen Webspace und ladet Euch eine Kopie der composer.phar herunter (CT_ROOT/composer)
3. diese composer.phar könnt ihr nun bei den Installationen benutzen, wo die Paketverwaltung aktuell zerstört ist
4. damit ihr beim nächsten Mal nicht wieder das selbe Problem bekommt, geht in System/Einstellung in den Menüpunkt "Composer-Einstellungen" und deaktiviert den Punkt "Composer Bibliothek automatisch aktualisieren" - somit wird die Composerbibliothek nicht mehr automatisch aktualisiert

ABER Achtung: ihr solltet dies nicht zum Dauerzustand werden lassen und die automatische Aktualisierung nach Klärung der Probleme wieder aktivieren, denn sonst kann es zu noch mehr Problemen kommen. Es ist eine Übergangslösung.

fg
nicky

EDIT sagt: Und immer schön eine Sicherung machen und aufpassen: die composer.phar kopieren, keine andere!

[hofff]

@ Nicky: Erstmal besten Dank für die ausführliche Antwort, denke das klärt schon mal auf.

Ich hatte mit meinem Hoster gesprochen, in unserem Fall ist das ein Debian 7 mit PHP 5.6. Der Admin meinte, dass es wohl sehr problematisch ist die Zertifikatsverwaltung freizugeben, denn wenn Contao Sicherheitslücken hätte, kann man auf die kompletten Zertifikate zugreifen.

Nur als Vorschlag: Vielleicht könnte man mal eine Skype-Konferenz oder sowas machen, in der sich z.B. ein Serveradmin, Xtra, ich, oder alle die Interesse haben unterhalten? So wie es ausschaut, scheint das ja mehrere Installationen zu betreffen. Was meint Ihr dazu?

VG
Jan

Können wir gern machen ... mein Serveradmin war anfangs auch nicht wirklich begeistert, aber es geht hier halt um die öffentlichen Zertifikate, das sollte meines Wissens nach, nicht so problematisch sein, aber genaueres kann ich dazu auch nicht sagen - ich bin kein Serveradmin.

fg
nicky

[Spooky]

Solange die Schreibrechte auf dem Server überall korrekt gesetzt sind und jede Website bzw. jeder VirtualHost unter einem eigenen User läuft, kann die open_basedir restriction theoretisch komplett entfernt werden.

[Ulrich]

... das ist die Antwort von Alfahosting:

... eine individuelle Serverkonfiguration ist nur mit einem eigenen System möglich: https://alfahosting.de/server-hosting/
Die open_basedir restriction ist eine accountübergreifende Sicherheitsmaßnahme auf jedem unserer Webhostingserver (übrigens tarifunabhängig), welche nicht einzeln angepasst werden kann.
Daher müsste eine Möglichkeit gefunden werden, skriptseitig Anpassungen vorzunehmen.

[Nicolas]

Hi Leute,

ich hatte ähnliche Probleme mit dem Composer und konnte Sie mittlerweile lösen, allerdings kann ich nicht genau sagen wie!

Der Tipp von Nicky scheint plausibel, kann aber definitiv keine Langzeitlösung sein.

Mein Tipp, versucht die Composer Funktionen "Composer Cache leeren & Composer aktualisieren" direkt aufzurufen:
.../main.php?do=composer&clear=composer-cache
.../main.php?do=composer&update=composer

Irgendwann ging es dann bei mir komischer Weise wieder!

MfG
Nicolas

[Contao-Academy]

Hi,

hab hier das gleiche Problem und vorerst so gelöst wie Nicky das vorgeschlagen hat.
Danke erst mal.

Ich gehe allerdings mal davon aus, dass es bald sehr viele Contao-User betreffen wird.
Eine allgemein Lösung wäre sicher wünschenswert.

Viele Grüße
Christian

[designpilot]

Hi

Wenn ich mich nicht irre, müsste man dem Problem auch entgegenwirken können, in dem man "/etc/ssl/certs" usw. (für diejenigen die Plesk als Panel im Einsatz haben) unter HOSTING EINSTELLUNGEN -> open_basedir die Pfade getrennt durch ein : einträgt (ACHTUNG SEHR WICHTIG DAS DER BESTEHENDE EINTRAG DRIN BLEIBT) einfach am schluss des Standard Eintrages einfügen.

z.B. wie folgt:
{WEBROOT}{:}{/}{TMP{/}:/etc/pki/tls/certs


Gesendet von iPhone mit Tapatalk

[Ulrich]

Hi

Wenn ich mich nicht irre, müsste man dem Problem auch entgegenwirken können, in dem man "/etc/ssl/certs" usw. (für diejenigen die Plesk als Panel im Einsatz haben) unter HOSTING EINSTELLUNGEN -> open_basedir die Pfade getrennt durch ein : einträgt (ACHTUNG SEHR WICHTIG DAS DER BESTEHENDE EINTRAG DRIN BLEIBT) einfach am schluss des Standard Eintrages einfügen.

z.B. wie folgt:
{WEBROOT}{:}{/}{TMP{/}:/etc/pki/tls/certs


Gesendet von iPhone mit Tapatalk

Das geht nur dann, wenn man einen "eigenen" Server verwaltet, also einen Server-Vertrag abgeschlossen hat, bei einem Webhosting-Vertrag leider nicht ...

[designpilot]

Das geht nur dann, wenn man einen "eigenen" Server verwaltet, also einen Server-Vertrag abgeschlossen hat, bei einem Webhosting-Vertrag leider nicht ...

Hi Ulrich

Danke für deine Info (ich frag mich halt, wieso das man bei einem normalen Hosting in Plesk diese Einstellung editieren kann und zusätzliche Pfadangaben machen kann). Aber ist schon einleuchtend das dies auf Systemebene nur dann funktioniert wenn es ein eigener Server ist

DAS HIER KÖNNTE VIELLEICHT FUNKTIONIEREN
http://download1.parallels.com/Plesk...Name=74969.htm

(ABER NUR FÜR DIEJENIGEN WELCHE PLESK ALS CONTROL PANEL HABEN)

[hofff]

Wir arbeiten an einer Lösung! …

[Spooky]

Irgendein Hinweis darauf wie diese Lösung aussieht? Habe selbst bei meinem Root Server Probleme die Warnings komplett wegzubekommen..

[xtra]

Die fixes sind hier alle als diff aufgelistet.

https://github.com/contao-community-...29a8...023ef72

Zum testen empfiehlt es sich jedoch, den hotfix/various-issues branch zu verwenden/downloaden.

Bitte zeitnah Testberichte bei den entsprechenden tickets, dann kann ich die Version taggen und offiziell frei geben.

[designpilot]

Die fixes sind hier alle als diff aufgelistet.

https://github.com/contao-community-...29a8...023ef72

Zum testen empfiehlt es sich jedoch, den hotfix/various-issues branch zu verwenden/downloaden.

Bitte zeitnah Testberichte bei den entsprechenden tickets, dann kann ich die Version taggen und offiziell frei geben.

Hi Xtra

Das heisst, dass ich nur die entsprechenden Dateien wie auf GitHub angegeben anpassen und oder ergänzen muss korrekt ???

[lucina]

Das kann man schon so machen, aber ... ;-)

Der weitaus simplere Weg wäre doch wohl, in der Paketverwaltung den entsprechenden Branch hotfix/various-issues zu Installation auszuwählen und zu installieren.

Vermutlich ist es eine gute Idee, das nicht auf dem Produktivsystem zu machen (aber das gilt ja für alle Testszenarien).

[designpilot]

Das kann man schon so machen, aber ... ;-)

Der weitaus simplere Weg wäre doch wohl, in der Paketverwaltung den entsprechenden Branch hotfix/various-issues zu Installation auszuwählen und zu installieren.

Vermutlich ist es eine gute Idee, das nicht auf dem Produktivsystem zu machen (aber das gilt ja für alle Testszenarien).

Also ich hab jetzt mal den Weg von Nicky gewählt (von einer noch laufenden Composer Installation die composer.phar genommen und per FTP auf den Server geladen) und in den Einstellungen die automatische Aktualisierung des Composers ausgeschaltet (das funktioniert für den ersten Moment).

Ich werde noch warten bis Xtra die Lösung freigeben wird und dann das durchführen

[Contao-Academy]

Hab soeben den Hotfix installiert. Bei mir läuft es.

Composer version cff35071b68e286f68ac64908c990c15b3ac4a0d

Danke und viele Grüße
Christian

[bizon]

Hotfix funktioniert auch bei mir.

[Ulrich]

Der Hotfix funktioniert auch bei mir ...

[x4all]

Hab den Hotfix mal komplett per FTP hochgeschoben, bei mir läufts noch nicht.

Mehrere Warning:

Warning: is_readable(): open_basedir restriction in effect. File(/etc/pki/tls/certs/ca-bundle.crt) is not within the allowed path(s): (/var/www/web221/html/:/var/www/web221/phptmp/:/var/www/web221/files/:/var/www/web221/atd/:/usr/share/php/:/opt/php/) in phar://composer/composer.phar/src/Composer/Util/Silencer.php on line 67

und eine Fatal Error

Fatal error: Uncaught exception Composer\Downloader\TransportException with message The configured cafile was not valid or could not be read. thrown in phar://composer/composer.phar/src/Composer/Util/RemoteFilesystem.php on line 797

[designpilot]

Also ich hab das mal wie folgt gemacht:
1. eine frische Installation von Contao 3.5.6
2. die ersten Einstellungen gemacht
3. Sitestruktur angelegt (Startpunkt)
4. Dateiverwaltung(Ordner erstellt und Files hochgeladen)
5. das Unavailable Template für den Wartungsmodus angepasst

Diese Schritte hier habe ich wie mit Fenepedia am Telefon erörtert durchgeführt:
1. Composer Client installiert
2. composer.phar vor der Migration von einer Contao 3.5.3 in Verzeichnis TL_ROOT/composer kopiert
3. automatische aktualisierung des Composers in Einstellungen deaktiviert
4. Migration ausgeführt (ohne Fehler / Warnmeldung)
5. Composer Cache gelert
6. Datenbank aktualisiert
7. AuthKey für GitHub unter Paketverwaltung -> Einstellungen hinzugefügt
8. in der Paketverwaltung den Composer Client Eintrag ausgewählt den obersten DEV hotfix ausgewählt und zur Installation vorgemerkt
9. Pakete aktualisieren angeklickt

Und nun hab ich den folgenden schwerwiegenden Fehler

Fatal error: Uncaught exception BadMethodCallException with message Entry res/cacert.pem does not exist thrown in system/modules/!composer/src/Util/CaBundleWorkaround.php on line 65

#0 system/modules/!composer/src/Util/CaBundleWorkaround.php(65): Phar->offsetGet('res/cacert.pem')
#1 system/modules/!composer/src/Runtime.php(531): ContaoCommunityAlliance\Contao\Composer\Util\CaBundleWorkaround::setCaFileIfOpenBaseDirInUse(Object(Phar))
#2 system/modules/!composer/src/ClientBackend.php(290): ContaoCommunityAlliance\Contao\Composer\Runtime::registerComposerClassLoader()
#3 system/modules/!composer/src/ClientBackend.php(125): ContaoCommunityAlliance\Contao\Composer\ClientBackend->loadComposer()
#4 system/modules/core/classes/Backend.php(423): ContaoCommunityAlliance\Contao\Composer\ClientBackend->generate()
#5 system/modules/core/controllers/BackendMain.php(131): Contao\Backend->getBackendModule('composer')
#6 contao/main.php(20): Contao\BackendMain->run()
#7 {main}

Ich verstehe das nicht, wieso das selbst bei einer kompletten NEU INSTALLATION passiert. Ich werde heute Abend noch probieren die Dateien manuell anzupassen wie auf GitHub gezeigt und mal sehen ob es dann wenigstens so funktioniert.

[x4all]

Ich bin folgendermaßen vorgegangen.

Bei einer Test-Installation (3.5.6) hatte ich noch die Erweiterungsverwaltung aktiv. Habe über diese dann den Composer Client installiert, lief auch alles gut, bis zum DB-Update. Habe dann den hotfix hochgeschoben, dann wurde mir der Migrationsassistent angezeigt. Beim migrieren dann krachte es.