This question already has answers here:
How do I install Composer on a shared hosting?
(7 answers)
Closed 1 year ago.
Background:
It was reported on 27 April 2021 that Composer has a vulnerability that impacts PHP.
https://blog.packagist.com/composer-command-injection-vulnerability/
https://portswigger.net/daily-swig/php-package-manager-flaw-left-millions-of-web-apps-open-to-abuse
Recommended action: Update to Composer 2.0.13
Composer - https://getcomposer.org/
Server Environment:
Linux
Shared web hosting
These are the steps I took:
Step 1: Log on to Terminal and find out the composer version I am using
composer -vvv about
Result:
Running 2.0.6 (2020-11-07 11:21:17) with PHP 7.3.27 on Linux / 4.19.150-76.ELK.el6.x86_64
Step 2: Run command to update Composer
composer self-update
Result: Error Message
Upgrading to version 2.0.13 (stable channel).
[Composer\Downloader\FilesystemException]
Filesystem exception:
Composer update failed: "/opt/cpanel/composer/bin/composer" could not be written.
rename(/opt/cpanel/composer/bin/composer): failed to open stream: Read-only file system
self-update [-r|--rollback] [--clean-backups] [--no-progress] [--update-keys] [--stable] [--preview] [--snapshot] [--1] [--2] [--set-channel-only] [--] [< version>]
Step 3: Find out the permissions for /opt/cpanel/composer/bin/composer
ls -l /opt/cpanel/composer/bin/composer
Result:
-rwxr-xr-x 1 bin bin 2192976 Nov 10 13:37 /opt/cpanel/composer/bin/composer*
stat /opt/cpanel/composer/bin/composer
Result:
File: `/opt/cpanel/composer/bin/composer'
Size: 2192976 Blocks: 4288 IO Block: 4096 regular file
Device: 801h/2049d Inode: 266192 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 1/ bin) Gid: ( 1/ bin)
Access: 2021-05-02 02:40:36.937400521 -0600
Modify: 2020-11-10 13:37:13.000000000 -0700
Change: 2021-04-14 16:25:27.129945713 -0600
You cannot upgrade composer on a shared hosting environment. You could download an entirely new instance of composer to another folder but you may run into restrictions. You should contact the hosting provider and let them know. Alternatively since you are on cPanel you can contact cPanel.
Additionally you should read the exploit more carefully. Do you have Mercurial? This exploit might not even apply to you.
The second exploit link you listed is not related to you, as you are on a higher version than the exploited one.
For a little while now, I've been looking how to try a connection to AS400 with Laravel 7.
I use this package : https://github.com/cooperl22/laravel-ibmi
I add laravel-ibmi to your composer.json file:
"require": {
"cooperl/laravel-ibmi": "^7.0"
}
Use composer to install this package.
$ composer update
Run on the command line from the root of my project:
$ php artisan vendor:publish
And set credentials in .env
DB_CONNECTION=ibmi
DB_HOST=********
DB_PORT=********
DB_DATABASE=********
DB_USERNAME=********
DB_PASSWORD=********
I try a connection with tinket but i have this message :
Psy Shell v0.10.4 (PHP 7.2.24-0ubuntu0.18.04.4 — cli) by Justin Hileman
>>> DB::connection();
PDOException with message 'could not find driver
I should set my credentials in app/config/db2.php, not in .env ?
UPDATE
I install the unixODBC
odbcinst -j
unixODBC 2.3.4
DRIVERS............: /etc/odbcinst.ini
SYSTEM DATA SOURCES: /etc/odbc.ini
FILE DATA SOURCES..: /etc/ODBCDataSources
USER DATA SOURCES..: /home/za/.odbc.ini
SQLULEN Size.......: 8
SQLLEN Size........: 8
SQLSETPOSIROW Size.: 8
Download ibm_data_server_driver_for_odbc_cli_linux390x64_v11.5.tar.gz
tar -xavf ibm_data_server_driver_for_odbc_cli_linux390x64_v11.5.tar.gz
cd odbc_cli
sudo mkdir -p /opt/ibm/clidriver
sudo cp -r clidriver/* /opt/ibm/clidriver
Edit the odbcinst.ini
[Db2]
Description=Db2 Driver
Driver=/opt/ibm/clidriver/lib/libdb2o.so
fileusage=1
dontdlclose=1
Edit odbc.ini for the test
[sample]
Description = Test to DB2
Driver = Db2
but when i try i got this message
export DB2INSTANCE=db2inst1
isql -v sample db2inst1 ibmdb2
[01000][unixODBC][Driver Manager]Can't open lib '/opt/ibm/clidriver/lib/libdb2o.so' : file not found
[ISQL]ERROR: Could not SQLConnect
UPDATE 2
I go to https://www.ibm.com/support/pages/node/633843
Click Downloads for IBM i Access Client Solutions
When prompted, log in with my IBMid
Scroll down, and next to ACS Linux App Pkg, select Download now
After that i have installed ibm-iaccess-1.1.0.13-1.0.x86_64.rpm, i see it automatically adds the IBM i Access ODBC Driver to odbcinst.ini.
Edit odbc.ini for the test
[sample]
Description = Test to DB2
Driver = IBM i Access ODBC Driver
But it's the bug is repeated (Whereas /opt/ibm/iaccess/lib64/libcwbodbc.so exist).
isql -v sample
[01000][unixODBC][Driver Manager]Can't open lib '/opt/ibm/iaccess/lib64/libcwbodbc.so' : file not found
[ISQL]ERROR: Could not SQLConnect
UPDATE 3
I enter this command
ldd /opt/ibm/iaccess/lib64/libcwbodbc.so
linux-vdso.so.1 (0x00007ffe4830e000)
libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 (0x00007f1fdc97e000)
libcwbcore.so => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1fdc5f5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1fdc257000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1fdc03f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1fdbc4e000)
libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f1fdba44000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1fdb825000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1fdce6c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1fdb621000)
I did that afterwards.
cp /opt/ibm/iaccess/lib64/libcwbcore.so /usr/lib/x86_64-linux-gnu/
isql -v sample
[S1000][unixODBC][IBM][Pilote ODBC System i Access]Le nom de syst�me requis pour la connexion est manquant.
[ISQL]ERROR: Could not SQLConnect
For PHP and Laravel it is wise to get the unixODBC working at the command line before trying to get it working with PHP. The reason is that troubleshooting is easier when you have fewer components to test. It also helps with separation of responsibilities.
The solution was to download and install
a suitable Db2-driver for ODBC/CLI on Linux specifically to work with i-series (AS/400) from IBM website at this link.
The other small footprint clidriver (supplied by IBM) cannot communicate with i-series unless you go via a Db2-connect gateway or have a Db2-connect licence (separate purchase). So it is usually more effective to use the IBM i access product instead. The clidriver works correctly without needing a license or Db2-connect, only when the target Db2-server runs on Linux or Unix variant or Microsoft Windows.
This IBM i access client product has a PDF document included "Installation and Usage Guide" which has helpful information, and several links to useful resources.
After installation, it is necessary to properly configure both the odbcjinst.ini (which details the driver) and the odbc.ini(which details the data soruces) (or .odbc.ini for user DSNs) for use with the driver supplied by the IBM i access client product.
Instructions for completing the odbcinst.ini and odbc.ini are available on the unixODBC website.
Test the connection to the i series with the isql tool, to verify that unixODBC is able to connect and use SQL queries.
The IBM i access product also has troubleshooting tools that includes cwbping and cwbtrc commands among others, which exercise the Db2-driver independently of unixODBC.
Once isql successfully connects to the i series database, you are now ready to configure PHP to use the driver in the normal way. You can then test with Laravel.
Remember to ensure that your linux shell sets the correct LANG environment variable to match your country and your character encoding before accessing the database (which require the relevant locale to be installed), otherwise codepage conversion may give unexpected results.
I'm using the latest PHP packages available from https://launchpad.net/~ondrej/+archive/ubuntu/php .
When I build and install the OCI8 extension, everything appears to be in order, but despite enabling the extension in the PHP-FPM configuration, its presence is not reflected in the output from phpinfo().
The following Gist details the exact process that I'm using to configure, build, and install the OCI8 PHP extension:
https://gist.github.com/cbj4074/fa761f60b6f8db431539d76ebfba828e
The very same process and configuration work perfectly well on Ubuntu 16.04 LTS, so it seems that there is some fundamental difference on Ubuntu 18.04 LTS, whether with the operating system or the PHP packages in question.
As a bit of important (and I suspect relevant to this issue) background information, on Ubuntu 18.04 LTS, the extension fails to load in the CLI environment out-of-the-box, with the error:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20160303/oci8.so' - libmql1.so: cannot open shared object file: No such file or directory in Unknown on line 0
I resolved the issue like so:
# echo 'LD_LIBRARY_PATH="/opt/oracle/instantclient_12_2"' >> /etc/environment
I thought that perhaps adding the LD_LIBRARY_PATH to the PHP-FPM environment configuration might resolve the equivalent issue there:
# echo "env['LD_LIBRARY_PATH'] = /opt/oracle/instantclient_12_2" >> /etc/php/7.2/fpm/pool.d/www.conf
# systemctl restart php7.2-fpm
This does indeed cause the LD_LIBRARY_PATH value, as specified, to be reflected in both the Environment section of phpinfo() (when rendered via PHP-FPM + NGINX and requested from a browser) and the PHP Variables section, as $_SERVER['LD_LIBRARY_PATH'].
Oddly, even with PHP-FPM's logging set to debug, I don't see any trace of the libmql1.so error that I experience with the CLI. The OCI8 extension simply fails to load, silently. display_startup_errors = On in PHP-FPM's effective php.ini, too.
I elected to see if the OCI8 extension works in Apache, on the same server, and it does, provided I add export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 to /etc/apache2/envvars; in its absense, Apache complains on startup:
PHP Warning: PHP Startup: Unable to load dynamic library 'oci8.so' (tried: /usr/lib/php/20170718/oci8.so (libmql1.so: cannot open shared object file: No such file or directory), /usr/lib/php/20170718/oci8.so.so (/usr/lib/php/20170718/oci8.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
None of this business with the LD_LIBRARY_PATH is necessary on Ubuntu 16.04 LTS, and based on my observations herein and the comments regarding https://stackoverflow.com/a/45242468/1772379 , that changed in Ubuntu 17.10 and Ubuntu 18.04 LTS.
Has anybody else tried this, on Ubuntu 18.04 LTS, specifically?
I've tried this on two different Vagrant VMs, laravel/homestead box 6.0.0, and ubuntu/bionic64 box v20180509.0.0, and the behavior is the same in both.
Any other ideas would be most appreciated!
EDIT 1:
I asked about this issue on the package maintainer's GitHub tracker and he suggested that the problem stems from failing to set an appropriate RPATH at compile time.
I explain in my reply that I am setting an appropriate value, but the issue remains closed.
I do notice an interesting detail, however, which is that the compiled extension on Ubuntu 18.04 uses RUNPATH (and not RPATH, which is used in Ubuntu 16.04). If PHP-FPM ignores RUNPATH, and looks only for RPATH, it would explain this behavior.
EDIT 2:
This still-open report looks like an excellent candidate for having introduced the observed behavior:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732
(discovered through comments on use RPATH but not RUNPATH? )
EDIT 3:
On a commenter's advice, I reexamined updating the ld configuration before building the extension and that resolved the issue! I had tried this before, but must have overlooked something between build attempts:
# echo /opt/oracle/instantclient_12_2 > /etc/ld.so.conf.d/oracle-instantclient.conf
# ldconfig
I still don't know why LD_LIBRARY_PATH doesn't work as it should in this instance, but adding the Instant Client library path to the linker configuration seems a better approach besides.
EDIT 4:
I stated in my previous edit that modifying the ldconfig constitutes a better approach, but came to realize (on a commenter's good advice) that doing so can cause undesirable library conflicts, because the effects are system-wide.
In hindsight, it makes sense to minimize the "collateral damage" from runtime library linkage modifications by limiting them to the execution environment via the LD_LIBRARY_PATH. Accordingly, I am motivated to determine why this does not work on Ubuntu 18.04 LTS.
I feel that I have established definitively that the PHP-FPM daemon ignores LD_LIBRARY_PATH on Ubuntu (and has since at least Ubuntu 16.04 LTS; see Comments for explanation).
The ld.so(8) manpage states (in relation to the order in which runtime library paths are searched):
Using the environment variable LD_LIBRARY_PATH (unless the executable is being run in secure-execution mode; see below). [sic] in which case it is ignored.
As yet, I cannot think of any other reason for which the path would be ignored. Of secure-execution mode, the same document says:
Secure-execution mode
For security reasons, the effects of some environment variables are voided or modified if the dynamic linker determines that the binary
should be run in secure-execution mode. (For details, see the discussion of individual environment variables below.) A binary is exe‐
cuted in secure-execution mode if the AT_SECURE entry in the auxiliary vector (see getauxval(3)) has a nonzero value. This entry may
have a nonzero value for various reasons, including:
* The process's real and effective user IDs differ, or the real and effective group IDs differ. This typically occurs as a result of
executing a set-user-ID or set-group-ID program.
* A process with a non-root user ID executed a binary that conferred capabilities to the process.
* A nonzero value may have been set by a Linux Security Module.
Firstly, Secure-Execution Mode seems not to be in effect, as the PHP executables don't exhibit this flag (AT_SECURE is 0):
LD_SHOW_AUXV=1 /usr/sbin/php-fpm7.1 -daemonize --fpm-config /etc/php/7.1/fpm/php-fpm.conf
AT_SYSINFO_EHDR: 0x7ffc569e1000
AT_HWCAP: 178bfbff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x55ceab0c4040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0x7f823c77f000
AT_FLAGS: 0x0
AT_ENTRY: 0x55ceab19e360
AT_UID: 0
AT_EUID: 0
AT_GID: 0
AT_EGID: 0
AT_SECURE: 0
AT_RANDOM: 0x7ffc56962349
AT_HWCAP2: 0x0
AT_EXECFN: /usr/sbin/php-fpm7.1
AT_PLATFORM: x86_64
It occurred to me that the child FPM pool processes might exhibit different AT_SECURE values, but the output is identical for the PHP-FPM daemon itself, as well as any child processes. The parent and the children all have the following values:
# od -t d8 /proc/851/auxv
0000000 33 140722944548864
0000020 16 395049983
0000040 6 4096
0000060 17 100
0000100 3 93903778242624
0000120 4 56
0000140 5 9
0000160 7 140365152313344
0000200 8 0
0000220 9 93903779136352
0000240 11 0
0000260 12 0
0000300 13 0
0000320 14 0
0000340 23 0
0000360 25 140722944193929
0000400 26 0
0000420 31 140722944196579
0000440 15 140722944193945
0000460 0 0
Secondly, none of these reasons seem to apply, given the following:
1) There is no indication that PHP-FPM or its child processes have real and effective user or group IDs that differ (thanks to https://unix.stackexchange.com/a/202359 for this command):
# ps -e -o user= -o ruser= | awk '$1 != $2'
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
# ps -e -o group= -o rgroup= | awk '$1 != $2'
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
2) The binaries in question do not have any capabilities (the following commands produce no output):
# getcap /usr/lib/php/20170718/oci8.so
# getcap -r /opt/oracle/instantclient_12_2/
3) I have ensured that AppArmor is disabled (it doesn't have a policy that should affect PHP-FPM, anyway):
# systemctl disable apparmor
Synchronizing state of apparmor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable apparmor
# reboot
# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
So, why does PHP-FPM ignore LD_LIBRARY_PATH, if not for any of the aforementioned reasons?
EDIT 5 (Solution):
An astute commenter, #vinc17 , points-out that on systems running systemd, environment variables, such as LD_LIBRARY_PATH, are not necessarily propagated to processes that are started via a systemd Unit.
In other words, PHP-FPM isn't "ignoring" LD_LIBRARY_PATH, but rather, it is not being conveyed to the process. And attempts to set LD_LIBRARY_PATH within the PHP-FPM configuration are futile, because it's too late to do anything useful with the value.
On this advice, it occurred to me to set LD_LIBRARY_PATH in the systemd context, namely, in the Unit file(s) that start the PHP-FPM daemon(s), in which case PHP-FPM loads the OCI8 extension successfully.
Needless to say, we want to avoid editing the package maintainer's file (to avoid conflicts during future upgrades), so we extend it instead:
# mkdir /etc/systemd/system/php7.1-fpm.service.d
# touch /etc/systemd/system/php7.1-fpm.service.d/environment.conf
To this file we add the following:
[Service]
Environment=LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2
And to make the change effective:
# systemctl daemon-reload
# systemctl restart php7.1-fpm
For a more complete example, which addresses multiple co-installed PHP versions, please see my post at https://github.com/oerdnj/deb.sury.org/issues/865#issuecomment-395441936 .
First, Debian bug 859732 is a completely different issue (I would even say an opposite issue): for this bug, several versions of the library are present in the search path (one in some directory specified by LD_LIBRARY_PATH and a different one in some directory specified by the run path), but the wrong one is chosen by the dynamic linker.
In your case, the problem is that the requested library is not found anywhere in the search path. Note also that in your case, it is PHP that seems to try to open the library (via dlopen?), since the message starts with "PHP Warning:". However, it seems that the mechanisms are the same as with usual dynamic linking.
After installing the library, what you need is at least one of:
Nothing special if the library has been installed in a directory that is searched by default. Since you get an error, this is not your case.
Providing the directory in a run path, which must be specified at compile time of the software that will need the library. The problem is that under Linux, this is not done in standard by the build tools, and it may be complex to do it right without breaking other things. However, in the context of dlopen, the software (here, PHP) may have set up what one can call a "plugin search path", where you can put your libraries.
Providing the directory in LD_LIBRARY_PATH. This is what you tried, but your LD_LIBRARY_PATH seems incorrect. Libraries are usually installed in subdirectories named lib (or lib32 or lib64 in specific cases). So, export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 seems wrong. Search for the full pathname of the library oci8.so, and just take the directory part of this pathname for LD_LIBRARY_PATH.
Note: strace may be useful to see what directories are considered to search for the libraries. EDIT: ldd and objdump -p are other useful tools to find what's going on with the search paths.
EDIT 2: Another point to note when choosing to use a run path is that indirect library dependencies are found when RPATH is used, but not when RUNPATH is used (so, in this latter case, all dependencies also need to have a run path if they depend on other libraries so that all libraries can be found without resorting to LD_LIBRARY_PATH). This is documented in recent versions of the ld.so(8) man page:
Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present. Such directories are searched only to find those objects required by DT_NEEDED (direct dependencies) entries and do not apply to those objects' children, which must themselves have their own DT_RUNPATH entries. This is unlike DT_RPATH, which is applied to searches for all children in the dependency tree.
This is probably why, without using LD_LIBRARY_PATH, this was working with 16.04 (where RPATH is used) but not with 18.04 (where RUNPATH is used).
I downloaded the Google App Engine SDK for PHP but I am having problems with the installation of the PHP interpreter. I downloaded the source code from the link given but when I try to compile php the command make terminates with this error:
/bin/bash /home/david/Google/appengine-php-master/php-src/libtool --silent --preserve-dup-deps --mode=compile cc -Iext/jsonc/ -I/home/david/Google/appengine-php-master/php-src/ext/jsonc/ -DPHP_ATOM_INC -I/home/david/Google/appengine-php-master/php-src/include -I/home/david/Google/appengine-php-master/php-src/main -I/home/david/Google/appengine-php-master/php-src -I/home/david/Google/appengine-php-master/php-src/ext/date/lib -I/home/david/Google/appengine-php-master/php-src/ext/ereg/regex -I/libxml2 -I/home/david/Google/appengine-php-master/php-src/ext/sqlite3/libsqlite -I/home/david/Google/appengine-php-master/php-src/TSRM -I/home/david/Google/appengine-php-master/php-src/Zend -I/include -g -O2 -fvisibility=hidden -c /home/david/Google/appengine-php-master/php-src/ext/jsonc/json.c -o ext/jsonc/json.lo
In file included from ext/jsonc/json-c/json_inttypes.h:5:0,
from ext/jsonc/json-c/json_object.h:16,
from ext/jsonc/json-c/linkhash.h:16,
from ext/jsonc/json-c/json.h:22,
from /home/david/Google/appengine-php-master/php-src/ext/jsonc/json.c:34:
ext/jsonc/json-c/json_config.h:2:23: fatal error: ../config.h: No such file or directory
#include "../config.h"
^
compilation terminated.
Makefile:725: recipe for target 'ext/jsonc/json.lo' failed
make: *** [ext/jsonc/json.lo] Error 1
In fact there is no such config.h file in that directory so I can't understand how to solve this problem.
So I decided to search online the source code of PHP 5.4.19 and I compiled and installed it and everything worked. I followed all the other installation steps and everything worked.
Now if I start the server with the command
google_appengine/dev_appserver.py --php_executable_path=/usr/local/bin/php-cgi --php_gae_extension_path=/home/david/Google/appengine-php-extension-master/modules/gae_runtime_module.so my_app/
I get:
INFO 2016-03-25 15:04:19,209 sdk_update_checker.py:229] Checking for updates to the SDK.
INFO 2016-03-25 15:04:19,797 sdk_update_checker.py:257] The SDK is up to date.
INFO 2016-03-25 15:04:19,901 api_server.py:205] Starting API server at: http://localhost:51913
INFO 2016-03-25 15:04:19,907 dispatcher.py:197] Starting module "default" running at: http://localhost:8080
INFO 2016-03-25 15:04:19,909 admin_server.py:116] Starting admin server at: http://localhost:8000
ERROR 2016-03-25 15:04:21,270 php_runtime.py:348] The PHP runtime is not available
Traceback (most recent call last):
File "/home/david/Google/google_appengine/google/appengine/tools/devappserver2/php_runtime.py", line 344, in new_instance
self._check_binaries(php_executable_path, gae_extension_path)
File "/home/david/Google/google_appengine/google/appengine/tools/devappserver2/php_runtime.py", line 286, in _check_binaries
cls._check_gae_extension(php_executable_path, gae_extension_path, env)
File "/home/david/Google/google_appengine/google/appengine/tools/devappserver2/php_runtime.py", line 241, in _check_gae_extension
ext_stdout))
_PHPEnvironmentError: "/usr/local/bin/php-cgi -m" returned an error [-6]
[libprotobuf FATAL google/protobuf/stubs/common.cc:61] This program requires version 3.0.0 of the Protocol Buffer runtime library, but the installed version is 2.6.1. Please update your library. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/home/david/Google/appengine-php-extension-master/remote_api.pb.cc".)
terminate called after throwing an instance of 'google::protobuf::FatalException'
what(): This program requires version 3.0.0 of the Protocol Buffer runtime library, but the installed version is 2.6.1. Please update your library. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/home/david/Google/appengine-php-extension-master/remote_api.pb.cc".)
Accordingly to the message the problem should be in the version of libprotobuf9 library. I have that library installed in my system (ubuntu 15.04) and in fact the version is 2.6.1. But by following the installation steps I installed protoc-3.0.0-beta-2-linux-x86_64 and protobuf-3.0.0-beta-2 in /usr. So, why does appengine use the wrong version of the library?
I thought about removing libprotobuf9 from my system but if I run sudo apt-get remove libprotobuf9 the list of packages that need to be removed is very big and contains things like
gnome-bluetooth gnome-calculator gnome-contacts
gnome-disk-utility gnome-font-viewer gnome-keyring gnome-mahjongg gnome-mines gnome-orca gnome-power-manager gnome-screensaver
gnome-screenshot gnome-session-bin gnome-session-canberra gnome-sudoku gnome-system-log gnome-system-monitor gnome-terminal
to me it doesn't seem a good idea to remove them. What's the solution to my problem?
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.