New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stabilize Composer #4359

Closed
ktomk opened this Issue Apr 30, 2016 · 43 comments

Comments

@ktomk
Contributor

ktomk commented Apr 30, 2016

IIRC minimum stability is alpha only because of composer. At 4th of April (or around that day) composer finally went stable and 2.0.5 yet still has the alpha version tagged, doesn't it?

So I think it would be worth to move to ^1.0.0, we did this in magerun as well the last month and it's just straight forward.

@piotrekkaminski

This comment has been minimized.

Show comment
Hide comment
@piotrekkaminski

piotrekkaminski May 1, 2016

Contributor

+1

Contributor

piotrekkaminski commented May 1, 2016

+1

@thaiphan

This comment has been minimized.

Show comment
Hide comment
@thaiphan

thaiphan May 1, 2016

Contributor

I was trying to use the path repository feature in Composer but wasn't able to until I manually updated Composer. Would be good if Magento updates Composer for us.

Contributor

thaiphan commented May 1, 2016

I was trying to use the path repository feature in Composer but wasn't able to until I manually updated Composer. Would be good if Magento updates Composer for us.

ktomk added a commit to ktomk/composer-magento- that referenced this issue May 1, 2016

Stabilize composer
Composer now has stable releases and supports semantic versioning. This
commit stops magento/composer from blocking stable composer requirements
as it was previously by pinning it to a specific release (1.0.0-beta1).

- Ref: magento/magento2#4359
@ktomk

This comment has been minimized.

Show comment
Hide comment
@ktomk

ktomk May 1, 2016

Contributor

Stabilizing composer is not yet possible because one of its dependencies, magento/composer 1.0.3, pins the composer version to 1.0.0-beta1. I therefore opened a PR to get magento/composer 1.0.4 with a stabilized composer requirement so to become able to update here.

Contributor

ktomk commented May 1, 2016

Stabilizing composer is not yet possible because one of its dependencies, magento/composer 1.0.3, pins the composer version to 1.0.0-beta1. I therefore opened a PR to get magento/composer 1.0.4 with a stabilized composer requirement so to become able to update here.

@hostep

This comment has been minimized.

Show comment
Hide comment
@hostep

hostep Jun 10, 2016

Collaborator

Hi guys

Another vote for stabilizing composer/composer.

We run into an issue on our hosting with Magento 2.1-rc2, because Magento ships with version 1.0.0-beta1

When we try to login to our backend, a PHP warning is thrown:

Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): (/var/www/example.com:/var/www/example.com/wwwroot:/usr/share/pear:/usr/share/php:/usr/share/phpmyadmin:/tmp:/usr/local/lib/php:/usr/share/misc) in /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php on line 914
#1 /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php(915): is_dir('/etc/pki/tls/ce...')
#2 /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php(801): Composer\Util\RemoteFilesystem->getSystemCaRootBundlePath()
#3 /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php(61): Composer\Util\RemoteFilesystem->getTlsDefaults(Array)
...

This happens because in version 1.0.0-beta1 of composer this line fails:
https://github.com/composer/composer/blob/1.0.0-beta1/src/Composer/Util/RemoteFilesystem.php#L914

In a later version (not exactly sure which one) it was fixed by adding an @ sign in front of the is_dir function call:
https://github.com/composer/ca-bundle/blob/205ee8426c0461c9ab14712069ed5c92a7518646/src/CaBundle.php#L115

If we manually add the @ sign to the composer source files, our open_basedir problem is fixed

Please, consider putting a stable composer/composer version in Magento 2.1 GA, so we can actually run it on our hosting.

Thanks!

Collaborator

hostep commented Jun 10, 2016

Hi guys

Another vote for stabilizing composer/composer.

We run into an issue on our hosting with Magento 2.1-rc2, because Magento ships with version 1.0.0-beta1

When we try to login to our backend, a PHP warning is thrown:

Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): (/var/www/example.com:/var/www/example.com/wwwroot:/usr/share/pear:/usr/share/php:/usr/share/phpmyadmin:/tmp:/usr/local/lib/php:/usr/share/misc) in /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php on line 914
#1 /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php(915): is_dir('/etc/pki/tls/ce...')
#2 /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php(801): Composer\Util\RemoteFilesystem->getSystemCaRootBundlePath()
#3 /var/www/example.com/wwwroot/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php(61): Composer\Util\RemoteFilesystem->getTlsDefaults(Array)
...

This happens because in version 1.0.0-beta1 of composer this line fails:
https://github.com/composer/composer/blob/1.0.0-beta1/src/Composer/Util/RemoteFilesystem.php#L914

In a later version (not exactly sure which one) it was fixed by adding an @ sign in front of the is_dir function call:
https://github.com/composer/ca-bundle/blob/205ee8426c0461c9ab14712069ed5c92a7518646/src/CaBundle.php#L115

If we manually add the @ sign to the composer source files, our open_basedir problem is fixed

Please, consider putting a stable composer/composer version in Magento 2.1 GA, so we can actually run it on our hosting.

Thanks!

@hostep

This comment has been minimized.

Show comment
Hide comment
@hostep

hostep Jun 17, 2016

Collaborator

@piotrekkaminski: can you try to get this change into Magento 2.1 GA?

We currently work around it by changing this line in our composer.json file:

"composer/composer": "@alpha"

to:

"composer/composer": "1.1.2 as 1.0.0-beta1",

Which gets us around the issue, but it feels a bit like a hack.

We've been using it for about a week now, and haven't noticed any downsides to it yet.

Collaborator

hostep commented Jun 17, 2016

@piotrekkaminski: can you try to get this change into Magento 2.1 GA?

We currently work around it by changing this line in our composer.json file:

"composer/composer": "@alpha"

to:

"composer/composer": "1.1.2 as 1.0.0-beta1",

Which gets us around the issue, but it feels a bit like a hack.

We've been using it for about a week now, and haven't noticed any downsides to it yet.

@tkn98

This comment has been minimized.

Show comment
Hide comment
@tkn98

tkn98 Jun 27, 2016

Contributor

It would be tremendously great in our eyes if we could see some traction here.

Contributor

tkn98 commented Jun 27, 2016

It would be tremendously great in our eyes if we could see some traction here.

@AydinHassan

This comment has been minimized.

Show comment
Hide comment
@AydinHassan

AydinHassan Jul 7, 2016

Contributor

Chiming it to get some action on this. Composer was stable ages ago - it would be nice to not have to include alpha software (even if I don't doubt the quality of Composer).

Contributor

AydinHassan commented Jul 7, 2016

Chiming it to get some action on this. Composer was stable ages ago - it would be nice to not have to include alpha software (even if I don't doubt the quality of Composer).

@piotrekkaminski

This comment has been minimized.

Show comment
Hide comment
@piotrekkaminski

piotrekkaminski Jul 7, 2016

Contributor

It is on the roadmap @AydinHassan to upgrade to latest.

Contributor

piotrekkaminski commented Jul 7, 2016

It is on the roadmap @AydinHassan to upgrade to latest.

@ktomk

This comment has been minimized.

Show comment
Hide comment
@ktomk

ktomk Jul 7, 2016

Contributor

Can we share where on that roadmap? :) I think this is a perfect fit for "developer experience".

Contributor

ktomk commented Jul 7, 2016

Can we share where on that roadmap? :) I think this is a perfect fit for "developer experience".

@jameshalsall

This comment has been minimized.

Show comment
Hide comment
@jameshalsall

jameshalsall Jul 13, 2016

Contributor

@piotrekkaminski when? where is the product roadmap?

Contributor

jameshalsall commented Jul 13, 2016

@piotrekkaminski when? where is the product roadmap?

@MrLei

This comment has been minimized.

Show comment
Hide comment
@MrLei

MrLei Jul 14, 2016

Hello what is solution this problem but i'm too instal clear Mag 2.1 and see this problem.
Mag 2.1 i get today in oficial site.

MrLei commented Jul 14, 2016

Hello what is solution this problem but i'm too instal clear Mag 2.1 and see this problem.
Mag 2.1 i get today in oficial site.

@mombrea

This comment has been minimized.

Show comment
Hide comment
@mombrea

mombrea Jul 29, 2016

For anyone else stuck here after upgrading to 2.1, @hostep solution to

"composer/composer": "@Alpha"
to:
"composer/composer": "1.1.2 as 1.0.0-beta1"

works great but required a composer update afterward. I also ran composer selfupdate but I'm not sure that was necessary.

mombrea commented Jul 29, 2016

For anyone else stuck here after upgrading to 2.1, @hostep solution to

"composer/composer": "@Alpha"
to:
"composer/composer": "1.1.2 as 1.0.0-beta1"

works great but required a composer update afterward. I also ran composer selfupdate but I'm not sure that was necessary.

@ktomk

This comment has been minimized.

Show comment
Hide comment
@ktomk

ktomk Jul 31, 2016

Contributor

@mombrea: Thanks for sharing, especially as it looks like this ticket is getting really slow and late.

@alankent Can you weight in and progress this a little? That would be wonderful.

Contributor

ktomk commented Jul 31, 2016

@mombrea: Thanks for sharing, especially as it looks like this ticket is getting really slow and late.

@alankent Can you weight in and progress this a little? That would be wonderful.

@vkorotun vkorotun removed the PS label Aug 4, 2016

@jaimiedijstra

This comment has been minimized.

Show comment
Hide comment
@jaimiedijstra

jaimiedijstra Aug 8, 2016

I also have this problem after upgrading from Magento 2.0.7 to Magento 2.1:

Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): (/home/example:/usr/lib/php:/usr/local/lib/php:/tmp) in /home/example/public_html/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php on line 914

Disabling open_basedir works but is not ideal but I am not in any kind of live environment. Will there be a patch for this, or could anyone expand on the fix presented by @hostep or @mombrea ?

jaimiedijstra commented Aug 8, 2016

I also have this problem after upgrading from Magento 2.0.7 to Magento 2.1:

Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): (/home/example:/usr/lib/php:/usr/local/lib/php:/tmp) in /home/example/public_html/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php on line 914

Disabling open_basedir works but is not ideal but I am not in any kind of live environment. Will there be a patch for this, or could anyone expand on the fix presented by @hostep or @mombrea ?

@jameshalsall

This comment has been minimized.

Show comment
Hide comment
@jameshalsall

jameshalsall Aug 8, 2016

Contributor

@jaimiedijstra just add :/etc/pki/tls/certs to the end of your current open_basedir INI setting value

Contributor

jameshalsall commented Aug 8, 2016

@jaimiedijstra just add :/etc/pki/tls/certs to the end of your current open_basedir INI setting value

@jaimiedijstra

This comment has been minimized.

Show comment
Hide comment
@jaimiedijstra

jaimiedijstra Aug 8, 2016

Thanks @jameshalsall I have done this for the time being, seems the best solution. Hoping a later update will change this.

jaimiedijstra commented Aug 8, 2016

Thanks @jameshalsall I have done this for the time being, seems the best solution. Hoping a later update will change this.

@hostep

This comment has been minimized.

Show comment
Hide comment
@hostep

hostep Aug 18, 2016

Collaborator

I just noticed this ticket is lacking a MAGETWO reference number. @piotrekkaminski: are you guys tracking this request in your internal system?

Collaborator

hostep commented Aug 18, 2016

I just noticed this ticket is lacking a MAGETWO reference number. @piotrekkaminski: are you guys tracking this request in your internal system?

@ktomk

This comment has been minimized.

Show comment
Hide comment
@ktomk

ktomk Aug 18, 2016

Contributor

@hostep: Good point, I'll escalate this via enterprise gold support after a bag of sleep.

Contributor

ktomk commented Aug 18, 2016

@hostep: Good point, I'll escalate this via enterprise gold support after a bag of sleep.

@maddyBoy

This comment has been minimized.

Show comment
Hide comment
@maddyBoy

maddyBoy Apr 29, 2017

"config": {
"use-include-path": true,
"disable-tls":true
},

I used this code to solve a:4:{i:0;s:270:"Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): (/var/www/vhosts/websitename.in/:/tmp/)

maddyBoy commented Apr 29, 2017

"config": {
"use-include-path": true,
"disable-tls":true
},

I used this code to solve a:4:{i:0;s:270:"Warning: is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): (/var/www/vhosts/websitename.in/:/tmp/)

@ktomk

This comment has been minimized.

Show comment
Hide comment
@ktomk

ktomk Apr 29, 2017

Contributor

@maddyBoy: Disabling TLS is counter-productive and your last comment therefore a flawed example.

To deal with the error take the information given in the error message directly. Configure the open_basedir setting to allow access to the TLS certificates in the file-system. That's all that is needed.

You don't want such a basedir restriction on certificates (you normally want these certificates read-only but accessible from the PHP process).

/r Just in case my comment might sound harsh, it's not meant so. I only address my personal opinion saying what I think is wrong and provide as well what I think is right. If a concrete example is missing or there are any further questions or critique: as open my comment is, as open I'm to feedback. I'm also aware of the good parts, e.g. providing the error message in text-form allows indexing so is identifiable by future users leading to the issue and the solution discussion. So thank you for your contribution.

Contributor

ktomk commented Apr 29, 2017

@maddyBoy: Disabling TLS is counter-productive and your last comment therefore a flawed example.

To deal with the error take the information given in the error message directly. Configure the open_basedir setting to allow access to the TLS certificates in the file-system. That's all that is needed.

You don't want such a basedir restriction on certificates (you normally want these certificates read-only but accessible from the PHP process).

/r Just in case my comment might sound harsh, it's not meant so. I only address my personal opinion saying what I think is wrong and provide as well what I think is right. If a concrete example is missing or there are any further questions or critique: as open my comment is, as open I'm to feedback. I'm also aware of the good parts, e.g. providing the error message in text-form allows indexing so is identifiable by future users leading to the issue and the solution discussion. So thank you for your contribution.

@orlangur

This comment has been minimized.

Show comment
Hide comment
@orlangur

orlangur May 17, 2017

Contributor

Composer version was bumped to stable one, but minimum stability is still alpha: https://github.com/magento/magento2/blob/develop/composer.json#L261 (maybe it's due to Zend Code 3.x or something?).

Contributor

orlangur commented May 17, 2017

Composer version was bumped to stable one, but minimum stability is still alpha: https://github.com/magento/magento2/blob/develop/composer.json#L261 (maybe it's due to Zend Code 3.x or something?).

@ktomk

This comment has been minimized.

Show comment
Hide comment
@ktomk

ktomk May 17, 2017

Contributor

@orlangur: Most likely this is a left-over and can be removed. I just gave it a try with a clean clone from develop, removing composer.lock and the minimum-stability setting and I did not run into any install problems. Maybe @hostep can provide another pair of eyes.

Contributor

ktomk commented May 17, 2017

@orlangur: Most likely this is a left-over and can be removed. I just gave it a try with a clean clone from develop, removing composer.lock and the minimum-stability setting and I did not run into any install problems. Maybe @hostep can provide another pair of eyes.

ktomk added a commit to ktomk/magento2 that referenced this issue May 17, 2017

...build-test: Revert minimum stability to stable again
Was reduced to alpha in the the past due to earlier required alpha
composer lib version.

NOTE: This commit removes composer.lock to trigger the CI builds w/o it.
      It is not intended to be incorporated upstream.

Refs:

- magento#4359

ktomk added a commit to ktomk/magento2 that referenced this issue May 17, 2017

...build-test: Revert minimum stability to stable again
Was reduced to alpha in the the past due to earlier required alpha
composer lib version.

NOTE: This commit removes composer.lock to trigger the CI builds w/o it.
      It is not intended to be incorporated upstream.

Refs:

- magento#4359
@orlangur

This comment has been minimized.

Show comment
Hide comment
@orlangur

orlangur May 17, 2017

Contributor

I see... Planned to check by myself as well. Could you prepare a PR with regenerated composer.lock then?

Contributor

orlangur commented May 17, 2017

I see... Planned to check by myself as well. Could you prepare a PR with regenerated composer.lock then?

ktomk added a commit to ktomk/magento2 that referenced this issue May 17, 2017

Revert minimum stability to stable, tasks magento#4359
Stability revert from alpha to stable. In 79c9052 set to alpha due to
earlier required composer/composer version which was not yet stable.

Composer upgrade was blocked due to changes w/ composer autoloading and
a PHP 5.3 regression allowing slash-prefixed class names in the past and
the unlucky coincidence that di.xml files made use of such class-names,
fixed in 0b243b8.

Now composer was updated in 0364bf9 and alpha degradation can be lifted.

Refs:

- magento#4359

- 79c9052

- 0b243b8

- 0364bf9
@ktomk

This comment has been minimized.

Show comment
Hide comment
@ktomk

ktomk May 17, 2017

Contributor

Sure I can do that, I have a test build running currently on Travis already and can use the composer.lock from my local install test.

Contributor

ktomk commented May 17, 2017

Sure I can do that, I have a test build running currently on Travis already and can use the composer.lock from my local install test.

@hostep

This comment has been minimized.

Show comment
Hide comment
@hostep

hostep May 17, 2017

Collaborator

@ktomk: removing "minimum-stability": "alpha" is very good. I just tested this manually on the latest revision of the develop branch and experienced no issues.
The PR looks perfectly fine.

Just a small hint: if you only want to update the composer.lock file's "metadata" (this is probably not the correct term), and not update all the dependencies to the latest versions, you can run: composer update --lock or composer update nothing. It makes cleaner diffs if you only update the metadata in one commit and update the dependencies in another commit. Although updating the composer.lock with the latest versions of all dependencies is always a good idea.

Anyway, very happy this is (finally) happening, thanks to everyone involved!

Collaborator

hostep commented May 17, 2017

@ktomk: removing "minimum-stability": "alpha" is very good. I just tested this manually on the latest revision of the develop branch and experienced no issues.
The PR looks perfectly fine.

Just a small hint: if you only want to update the composer.lock file's "metadata" (this is probably not the correct term), and not update all the dependencies to the latest versions, you can run: composer update --lock or composer update nothing. It makes cleaner diffs if you only update the metadata in one commit and update the dependencies in another commit. Although updating the composer.lock with the latest versions of all dependencies is always a good idea.

Anyway, very happy this is (finally) happening, thanks to everyone involved!

@ktomk

This comment has been minimized.

Show comment
Hide comment
@ktomk

ktomk May 17, 2017

Contributor

@hostep; Thanks for the feedback. You're right update nothing works with changed stability setting,. But the two updates it does are fine, too. Thank you, too!

Contributor

ktomk commented May 17, 2017

@hostep; Thanks for the feedback. You're right update nothing works with changed stability setting,. But the two updates it does are fine, too. Thank you, too!

magento-team pushed a commit that referenced this issue Jun 28, 2017

MAGETWO-69256: Revert minimum stability to stable, tasks #4359 #9672
 - Merge Pull Request #9672 from ktomk/magento2:patch/composer-minimum-stability-4359
 - Merged commits:
   1. a141ce4
   2. efd4708

magento-team pushed a commit that referenced this issue Jun 28, 2017

@bunhin

This comment has been minimized.

Show comment
Hide comment
@bunhin

bunhin Jul 2, 2017

Hi all,
I just install Magento CE 2.1.7 downloaded from official magento site, still get the error:
is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): ...and so on still long and many line in var/report file.

I am install it in shared hosting, and i belive dont have access to /etc/pki/tls/certs. I also try to add the folder open_basedir via custom php ini, but the directory still not included in open_basedir of php status info.

I believe this problem is still related to this thread, has it been solved? how do i need to do in order get the error solved without opening other issues, thank you.

bunhin commented Jul 2, 2017

Hi all,
I just install Magento CE 2.1.7 downloaded from official magento site, still get the error:
is_dir(): open_basedir restriction in effect. File(/etc/pki/tls/certs) is not within the allowed path(s): ...and so on still long and many line in var/report file.

I am install it in shared hosting, and i belive dont have access to /etc/pki/tls/certs. I also try to add the folder open_basedir via custom php ini, but the directory still not included in open_basedir of php status info.

I believe this problem is still related to this thread, has it been solved? how do i need to do in order get the error solved without opening other issues, thank you.

@ktomk

This comment has been minimized.

Show comment
Hide comment
@ktomk

ktomk Jul 2, 2017

Contributor

@bunhin: Support requests don't belong into the Github bug tracker but the forums. Search the existing reports there, e.g. https://magento.stackexchange.com/questions/137516/error-on-admin-login-magento-2-1/144254#144254

Contributor

ktomk commented Jul 2, 2017

@bunhin: Support requests don't belong into the Github bug tracker but the forums. Search the existing reports there, e.g. https://magento.stackexchange.com/questions/137516/error-on-admin-login-magento-2-1/144254#144254

@orlangur

This comment has been minimized.

Show comment
Hide comment
@orlangur

orlangur Jul 3, 2017

Contributor

This particular issue can be closed as it is already fixed in develop branch by merging corresponding PR. @okorshenko, please confirm.

@bunhin thanks for searching for an open issue before filling a new one, you really have the same error mentioned in this thread. Please use solution from #4359 (comment) or previous comment.

Fix will be available in 2.2 Magento release, I'm not even sure it could be backported to 2.1 due to backward compatibility constraints.

Contributor

orlangur commented Jul 3, 2017

This particular issue can be closed as it is already fixed in develop branch by merging corresponding PR. @okorshenko, please confirm.

@bunhin thanks for searching for an open issue before filling a new one, you really have the same error mentioned in this thread. Please use solution from #4359 (comment) or previous comment.

Fix will be available in 2.2 Magento release, I'm not even sure it could be backported to 2.1 due to backward compatibility constraints.

@bunhin

This comment has been minimized.

Show comment
Hide comment
@bunhin

bunhin Jul 3, 2017

On shared hosting, it is not easy to upgrade composer because can not login into magento backend, i have tried to change composer version, but the error persist, is it any other way round? such as replacing a file ?

bunhin commented Jul 3, 2017

On shared hosting, it is not easy to upgrade composer because can not login into magento backend, i have tried to change composer version, but the error persist, is it any other way round? such as replacing a file ?

@magento-engcom-team

This comment has been minimized.

Show comment
Hide comment
@magento-engcom-team

magento-engcom-team Sep 13, 2017

Contributor

Fixed in #9672
Thank you @ktomk

Contributor

magento-engcom-team commented Sep 13, 2017

Fixed in #9672
Thank you @ktomk

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment