I am using Windows 10 and composer is installed. When I try to install laravel installer globally using this command:
composer global require laravel/installer
[Composer\Downloader\TransportException]
The "https://repo.packagist.org/packages.json" file could not be downloaded:
failed to open stream: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
It means package not downloaded. I am not using any proxy server.
Composer diagnose result is listed below:
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist:
[Composer\Downloader\TransportException] The "http://repo.packagist.org/packages.json" file could not be downloaded: failed to open stream: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Checking https connectivity to packagist:
[Composer\Downloader\TransportException] The "https://repo.packagist.org/packages.json" file could not be downloaded: failed to open stream: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Checking github.com rate limit: FAIL
[Composer\Downloader\TransportException] The
"https://api.github.com/rate_limit" file could not be downloaded: failed to
open stream: A connection attempt failed because the connected party did not
properly respond after a period of time, or established connection failed
because connected host has failed to respond.
Checking disk free space: OK
Checking pubkeys:
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0 87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B 0C708369 153E328C AD90147D AFE50952 OK
Checking composer version: OK
Composer version: 1.8.0
PHP version: 7.2.1
PHP binary path: E:\xampp\php\php.exe
To resolve this, configure composer to use the https repository by running the following command on the cli before installing Laravel
composer config -g repo.packagist composer https://packagist.org
Do you use any antivirus?
If yes try to disable then check.
Sometime Mcafe prevent to download packagist.
The following steps will fix most "packages.json file could not be downloaded" issue with Composer:
Verify your firewall setting. Disable Firewall for starters
Enable PHP OpenSSL Extension
Enable PHP allow_url_fopen directive
Note: Make sure you are working with the right PHP version and Environment (apache, CLI, etc.) when you modify the php.ini file.
I believe you are facing the same issue as this and
this. Composer recommends the following:
We recommend you fix your IPv6 setup. If that is not possible, you can try the following workarounds:
sadly, for the Windows workaround it says that if your setup cannot be fixed or if that didn't solve the issue then you should outright disable IPv6 which is a common answer and is also suggested here (however the video has been deleted so I've made this post to have a reliable answer).
(I've purposely aligned the windows as such so you can see the steps to the screen)
Open Control Panel
Navigate to Network and Internet
Click on Network and Sharing Centre
On the left hand side of the window click on Change adapter settings
Find your adapter and open the properties by right clicking on it
Find Internet Protocol Version 6 (TCP/IPv6) and uncheck it
Click OK
Edit #1
What is suggested here is:
Install a Windows level VPN or proxy switcher that acts as the default route if you need to change your IP (effectively). Try CyberGhost
and that seemed to solve the issue for the OP.
I noticed this is also happening when changing networks (moving from office to office for example).
How I managed to solve it is to restart the docker container.
I had this situation happening 2 times already and the same solution helped.
All you need to do is to run your cmd/git as Administrator, no need to uninstall anything.
Related
I've made the switch to PHP 8.1 after 7.4.26 and when trying to update some existing projects I get this error while behind my company's proxy:
[Composer\Downloader\TransportException] curl error 60 while
downloading https://repo.packagist.org/packages.json: SSL certificate
problem: self signed certificate in certificate chain
I've rummaged WAMP around and checked to make sure that:
SSL is installed both for apache and PHP
The path to the latest cacert.pem is set in the php.ini under both curl.cainfo and openssl.cafile and both lines are uncommented
Both my http and my https proxies are set in my environment variables
Both composer public keys are set up
Restarting my PC/Apache/PHP
Clearing composer cache
Running the composer diagnostic in verbose mode I can see that it's reading the correct proxies, that the http request is getting a 200 response, but I get error 60 when it tried to get the https ones. What's bugging me is that if I do curl https://repo.packagist.org/packages.json I get the json without problem. I also have npm and git working just fine behind the same proxy. I've tried running composer with TSL disabled, even going back to my previous version of PHP but I keep getting the same error.
If anyone has an idea what this could be, this is an excerpt from composer diagnose:
Checking platform settings: OK
Checking git settings: Executing command (CWD): git config color.ui
Executing command (CWD): git --version
OK git version 2.29.1
Checking http connectivity to packagist: Downloading http://repo.packagist.org/packages.json using proxy (http://10.96.210.50:8080)
[200] http://repo.packagist.org/packages.json
OK
Checking https connectivity to packagist: Downloading https://repo.packagist.org/packages.json using proxy (http://10.96.210.50:8080)
FAIL
[Composer\Downloader\TransportException] curl error 60 while downloading https://repo.packagist.org/packages.json: SSL certificate problem: self signed certificate in certificate chain
Checking HTTP proxy: Downloading https://repo.packagist.org/packages.json using proxy (http://10.96.210.50:8080)
FAIL
[Composer\Downloader\TransportException] curl error 60 while downloading https://repo.packagist.org/packages.json: SSL certificate problem: self signed certificate in certificate chain
Checking github.com rate limit: Downloading https://api.github.com/rate_limit using proxy (http://10.96.210.50:8080)
FAIL
[Composer\Downloader\TransportException] curl error 60 while downloading https://api.github.com/rate_limit: SSL certificate problem: self signed certificate in certificate chain
Checking disk free space: OK
Checking pubkeys:
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0 87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B 0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: Downloading https://getcomposer.org/versions using proxy (http://10.96.210.50:8080)
FAIL
[Composer\Downloader\TransportException] curl error 60 while downloading https://getcomposer.org/versions: SSL certificate problem: self signed certificate in certificate chain
Composer version: 2.5.1
PHP version: 8.1.0
PHP binary path: C:\wamp64new\bin\php\php8.1.0\php.exe
OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
cURL version: 7.77.0 libz 1.2.11 ssl OpenSSL/1.1.1l
zip: extension present, unzip not available, 7-Zip present (7z)
I'm trying to install composer on Windows but I get the following error:
The "https://getcomposer.org/versions" file could not be downloaded:
SSL operation failed with code 1. OpenSSL Error messages: error:
1416F086: SSL routines: tls_process_server_certificate: certificate
verify failed Failed to enable crypto failed to open stream: operation
failed.
What's going on and how do I fix this?
I have fixed it, the issue you have encountered seems to be related to a missing certificate.
You just need to add your certificate to end of this file:
C:\xampp\apache\bin\curl-ca-bundle.crt
Here's an example how to append the certificate:
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4GA1UECxMXR2xvYmFsU2>lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2Jh
bFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjE... (Your certificate)
-----END CERTIFICATE-----
If you are in private network(Restricted Networking) such as Organization, you have to update their certificate in the "curl-ca-bundle.crt", Copy Paste your organization certificate code in the bottom of the "C:\xampp\apache\bin\curl-ca-bundle.crt" file.
I had the same issue. You have to find below Certificate and install manually to Trusted root of "Current User/Local Computer".
C:\xampp\apache\bin\curl-ca-bundle.crt
As a quick workaround I could run composer through its docker image:
docker run --rm --interactive --tty \
--volume $PWD:/app \
composer/composer install
I was bitten by this on my local Ubuntu machine. For no apparent reason, composer would time out.
Experienced same issue and it was caused by VPN app that was running on my computer, exiting it fixed the issue.
I had to exit the VPN for it to work. Posting this for others who may need another alternative if nothing else seems to work.
I have fixed it, the issue you have encountered seems to be related to a missing certificate.
but if don't have certificate, try this... change composer directory else where but not to desktop and try install again.
it's real work to me!!
I installed phabricator on openshift using a quickstart from github
https://github.com/CodeBlock/phabricator-openshift-quickstart
I got it running up fine, but I now have two issues:
1.) A setup issue that says apc.stat is enabled and that must be disabled in
/var/lib/openshift/my-user-hash/php/configuration/etc/php.ini
however I cannot access that with sudo command(sudo permission denied), even if I open it normally, I didn't find any apc.stat settings in the php.ini
2.) I can't figure out how set the local path for tracking repositories for diffusion. It says
I must give a path which should be read-writable by phabricator, I tried to give the persistent storage location ..data/ , but it gives me an exception as follows :
Unhandled Exception ("CommandException")
Command failed with error #1!
COMMAND
(cd '../data/' && HOME='/var/lib/openshift/my-user-hash/app-root/runtime/repo/phabricator/support/empty/' git cat-file --batch)
STDOUT
(empty)
STDERR
sh: line 0: cd: ../data/: No such file or directory
how do I fix this?
1) According to Num Duong answer, it seems like u currently could not resolve this issue, probably u should wait for openshift php.ini permissions policy changes.
Anyway this is minor non blocking issue.
2) Modify config file and re-deploy to openshift.
Look for available phabricator options here
U need smth like this: 'repository.default-local-path' => getenv('OPENSHIFT_DATA_DIR'),
P.S. Anyway there is one particular issue with phabricator on openshift that possibly never got resolved: cloning git repositories from OpenShift instances into Phabricator do not
work by SSH, due to permissions regarding the ssh configuration.
I have a fedora Instance runnig in an Amazon EC2. The problem is, I have a php already installed, but I want to update (PS: Somebody already gave to me the instance with the php installed). When I try the command: yum update php an error message appears.
Setting up Update Process
Setting up repositories
Cannot find a valid baseurl for repo: updates-released
Error: Cannot find a valid baseurl for repo: updates-released
I tried to uncomment the baseurl line in the yum repositorie files, but a new error appears.
Setting up Update Process
Setting up repositories
http://download.fedora.redhat.com/pub/fedora/linux/core/updates/4/i386/repodata/repomd.xml: [Errno 4] IOError: <urlopen error (-2, 'Name or service not known')>
Trying other mirror.
Cannot open/read repomd.xml file for repository: updates-released
failure: repodata/repomd.xml from updates-released: [Errno 256] No more mirrors to try.
Error: failure: repodata/repomd.xml from updates-released: [Errno 256] No more mirrors to try.
The error that you are getting sounds like it's a connection or DNS related issue -- see if you can ping 'download.fedora.redhat.com,' then see if you can use wget to attempt to get the file.
Also, your /etc/yum.repos.d/ directory may contain a repository file with an invalid repository in it -- I'm not sure if they're still publishing updates for Fedora 4 (it was released around 2004ish). Your best bet is to make sure that the version in /etc/fedora-release matches with the version in that repository configuration file.
I'm getting:
Warning: ldap_start_tls()
[function.ldap-start-tls]: Unable to
start TLS: Connect error in
/var/www/X.php on line Y
/etc/ldap/ldap.conf:
TLS_CACERT /etc/ssl/certs/ca.crt
ca.crt is the CA which signed the LDAP server certificate. The certificate on the LDAP server is expired and I can't change it.
You can ignore the validity in windows by issuing
putenv('LDAPTLS_REQCERT=never');
in your php code. In *nix you need to edit your /etc/ldap.conf to contain
TLS_REQCERT never
Another thing to be aware of is that it requires version 3 (version 2 is php default):
//$hostnameSSL example would be "ldaps://just.example.com:636" , just make sure it has ldaps://
$con = ldap_connect($hostnameSSL);
ldap_set_option($con, LDAP_OPT_PROTOCOL_VERSION, 3);
To get a better idea of what's going on, you can enable debug logging by:
ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);
This can be done before the ldap_connect takes place.
The specific scenario presented in the question--with an expired certificate that can't be changed--does appear to require disabling certificate validation on the LDAP client.
However, I suspect a lot of people, like me, reach this page for other root causes of receiving opaque LDAP TLS errors, where disabling validation of TLS certificates is not an appropriate answer.
In my case--using the LDAP Authentication extension for Mediawiki on an Ubuntu 18.04 LTS server, and authenticating against Active Directory on a Windows Server 2012 server--authentication stopped working in January/February 2020. The server certificate and the CA certificate were still both valid, and openssl s_client -verify 2 -connect <AD server>:636 from the Mediawiki server passed just fine.
Eventually I noticed that the signature algorithm in the SSL certificate served by AD/LDAP was SHA1, which I remembered recently suffered from the first known chosen-prefix collision exploit. This led me to investigate the changelog for packages that had recently been updated on the system, which turned up "Mark SHA1 as insecure for certificate signing" in the gnutls28 changelog circa January 8th, 2020. (The chain of dependencies from the php-ldap package in Ubuntu 18.04 goes to php7.2-ldap -> libldap-2.4-2 -> libgnutls30, whose source package is gnutls28.)
I followed some instructions to update the Windows CA to use SHA256 and then selectively followed instructions to renew the AD/LDAP cert, installed the new CA cert on my Mediawiki server, and the problem was solved! Briefly, these steps included:
In an Admin PowerShell on the AD server, run certutil -setreg ca\csp\CNGHashAlgorithm SHA256
In the Certification Authority MMC, right click on the CA -> All Tasks -> Renew CA Certificate
In a blank MMC, add snap-in for Certificates; select Local Computer
Under Personal -> Certificates, find the current entry used by LDAPS (Kerberos Authentication template type) -> All Tasks -> Advanced Options -> Renew This Certificate with the Same Key
In the same window, open the new CA certificate -> Details -> Copy to file -> no private key -> base64-encoded X.509
Copy the resulting file to /usr/share/ca-certificates/ on the Mediawiki server, then run sudo dpkg-reconfigure ca-certificates and select the new CA cert for inclusion.
P.S. For SEO purposes, depending on the mode I was using, error messages included:
ldap_start_tls(): Unable to start TLS: Connect error in /var/www/mediawiki/extensions/LdapAuthentication/LdapAuthenticationPlugin.php in the HTTP error log
ldap_start_tls(): Unable to start TLS: Can't contact LDAP server in [...]
Failed to start TLS. in the Mediawiki debug log (when using wgLDAPEncryptionType = ssl, i.e. encrypted LDAP port, 636)
Failed to bind as CN=foobar,CN=Users,DC=myOrgName,DC=local in the Mediwiki debug log (when using wgLDAPEncryptionType = tls, i.e. STARTTLS on the unencrypted LDAP port, 389)
My solution/workaround is to use
/etc/ldap/ldap.conf:
#TLS_CACERT /etc/ssl/certs/ca.crt
TLS_REQCERT never
If you have any better idea, please post another answer.
The path for ldap.conf in Windows is fixed:
c:\openldap\sysconf\ldap.conf
A restart of the web server may be required to apply changes.
In debian based systems:
Install the package: ldap-utils and in the file
/etc/ldap/ldap.conf, edit the line:
TLS_CACERT /etc/ldap/cacerts/cacert.asc
Create the directory /etc/ldap/cacerts and copy the cacert to
/etc/ldap/cacerts/cacert.asc
Restart apache.
In redhat based systems:
Install the package: openldap-clients and in the file
/etc/openldap/ldap.conf edit the line:
TLS_CACERT /etc/openldap/cacerts/cacert.asc
Create the directory /etc/openldap/cacerts and copy the cacert to
/etc/openldap/cacerts/cacert.asc
Restart httpd
I was able to get this working properly with openldap on Amazon Linux (Elastic Beanstalk PHP 7.0) with MacOS Server 5 LDAP, with TLS set to demand.
in /etc/openldap/ldap.conf:
TLS_REQCERT demand
TLS_CACERT /etc/openldap/certs/yourcacert.pem
(note that if you are not using openldap, the path will be /etc/ldap/certs/yourcacert.pem). This setup did not work until I placed the certificate inside the certs folder; it did not work from any other path.
The certificate to be placed in that path is NOT the TLS certificate of the server. It is the CA (Certificate Authority) certificate of the authority whom issued the server/domain specific TLS certificate. Only the CA certificate placed in that path will allow TLS to work before attempting an LDAP bind in php. Get the CA certificate from your server or download it from the authority's site, they are freely available.
To test if LDAP bind is even working without TLS, set TLS_REQCERT never temporarily (may need to comment # out TLS_CACERT). If you get "Can't connect to LDAP" it is not a TLS error; it simply cannot connect to the server and you likely need to open port 389 (not 636 for TLS).
Remember to restart your Apache server every time you make a change to the config file or certificate.
Some additional help for others, the certificate solution here solved my ldapsearch command line issue, but still PHP complained **Can't contact LDAP server**
Turned out to be SELinux on RHEL7 ( CentOS7 ) blocks HTTPD from using LDAP ports 389 and 636 by default, you can unblock with:
setsebool -P httpd_can_network_connect 1
Check your SELinux audit log file for things being blocked.