i'm having a problem when i'm create socket program.
/* Get the port for the WWW service. */
$service_port = getservbyname('www', 'tcp');
/* Get the IP address for the target host. */
$address = gethostbyname('localhost');
/* Create a TCP/IP socket. */
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
------------------
when i'm run a program i'm get the error like this
1
Fatal error: Call to undefined function socket_create() in /opt/local/apache2/htdocs/php/TCPclient.php on line 14
i think that error because i'm not enable extension=php_sockets.dll
but when i try to locate php.ini i don't found php.ini i just found php.ini-development and php.ini-production, i change that file to enable extension=php_sockets.dll but when i'm try again to run my program i'm still get same error,
anyone know what is the problem ?
i'm give the phpinfo of my local, i'm still worried with configuration file in phpinfo that is none , are that is missing?
thanks for your answer.
It looks like you are running PHP on Mac OS. If this was installed using macports, run the following command
sudo port install php5-sockets
I see two different things here:
You think that extensions come in the .dll format. Actually that's windows. You are not running windows.
You are running a UNIXoide system A common thing is next to have a single configuration file to also have folders with more configuration files in there, so that, if scanned recursively through all configuration directories this creates a multiple file based configuration database. Yeah! Rocks! But, the problem is, you have multiple things to check in your phpinfo (if you have not noticed so far):
Configuration File (php.ini) Path - This is the main configuration file configured.
Loaded Configuration File - This is the main configuration file actually loaded.
Scan this dir for additional .ini files - PHP looks here, too.
Additional .ini files parsed - Those have been actually loaded, too.
So take a decent look at all these settings and really, really take care to not mix things. PHP configuration is documented in the PHP Manual.
Check the documentation what an extension is, how you install it etc. pp. This varies depending on your system and software management.
That is a pretty fair assumption. I am certain that because the php.ini is not found on your machine you have an installation problem.
What web server are you using? Are you installing Apache or using IIS for PHP support?
Your snapshot does not include the --enable-sockets option nor does it contain the loaded configuration file (php.ini).
Since you are running on Mac you cannot use dlla. You can compile php with socket support or try Xampp
http://www.apachefriends.org/en/xampp-macosx.html
Related
I think I did quite a good job on installing PDFlib on a system (Ubuntu 18.04) but something's not totally right yet. What I did so far:
Followed the instructions here: https://www.pdflib.com/fileadmin/pdflib/pdf/support/PDFlib-in-PHP-HowTo.pdf
Downloaded the correct php_pdflib.so file and placed it in the extension directory I got through phpinfo()
Added extension=php_pdflib.so in my php.ini
Ran a sudo systemctl restart apache2 to restart Apache and reload extensions
Checked with php -i | grep PDF whether the binary was loaded or not, result seems positive
PDFlib
PDFlib Support => enabled
PDFlib GmbH Binary-Version => 9.2.0
Now, when I run phpinfo(); from the web side through a file, there is no mention of PDFlib at all. When I run it through CLI, everything seems to be okay.
I also tried creating a new PDFlib() instance through CLI and web. CLI works, web doesn't.
Did I miss something in the install process?
I also tried creating a new PDFlib() instance through CLI and web. CLI works, web doesn't.
this is a typical situation. The PHP CLI and the PHP within the web server could have different configuration. So please check the extension_dir as well which the php.ini which was loaded in your web server phpinfo() output. Then you have do the the same configuration. Please check as well the PHP/Webserver log file for any error messages. Maybe it might be NTS/TS (threading) issue as well, but this will be mentioned in the error message.
Being not a good engineer today, I did several things at once, so I can't tell what exactly worked out in the end. Will write down my steps nevertheless, as it works now.
I double checked the configuration file paths and files through php -i and a phpinfo(); to see the differences between CLI and web frontend.
I removed the extension=php_pdflib from both php.ini files
I moved the php_pdflib.so from the extension directory one level up, it now lives in /usr/lib/php directly
I also renamed it to phplib.so (but that was more to break things on purpose and see what happens
I created a 30-pdflib.ini file in /etc/php/7.3/fpm/conf.d and wrote only extension=/usr/lib/php/pdflib.so in it
Added that line to /etc/php/7.3/cli/php.ini to see if there's a difference
I tried restarting Apache2 several times, but phpinfo() did not show any changes for the loaded configuration files or modules
I did a sudo reboot
Checked again and now PDFlib is loaded for CLI as well as for web
So, not sure if a hard reboot really fixed this, but it seems to me like that. Maybe this helps someone else.
I am on a server with multiple domains. I would like to find out which php.ini gets loaded in each domain.
I've got a few different tools at hand. Perhaps they get me closer to what I want.
A simple php -i|grep 'Loaded Configuration File' returns the system php.ini.
find /home/ -xdev -name php.ini 2>/dev/null returns all php.ini belonging to all hosted domains.
virtualmin list-php-directories --domain this.is.a.domain --multiline returns all directories in which a specific version of PHP has been activated.
Some sample output:
1. Returns:
Loaded Configuration File => /etc/php/7.0/cli/php.ini
This is obviously the php.ini which gets loaded by the host OS.
2. Returns:
...
/home/domain.x.com/etc/php5/php.ini
/home/domain.x.com/etc/php7.0/php.ini
/home/domain.x.com/etc/php.ini
/home/domain.y.com/etc/php7.0/php.ini
/home/domain.y.com/etc/php.ini
...
This is a complete list of all php.ini in those domains.
3. Returns:
/home/domain.x.com/public_html
PHP version: 7.0
Full version: 7.0.8
Execution mode: fcgid
Web root directory: Yes
There is always a php.ini in /home/domain.foo.com/etc/. Is that the one that hets loaded? Or do I have to check virtualmin for which version of PHP is loaded to traverse into the appropriate subdir? Is there a completely different way?
Note: I only have the command line at hand and only one user for monitoring purposes. Also, the process should be non-invasive. So I dont' think that I can put some php files in those domains to get my answer through a browser. Is the info perhaps stored in some file I can parse?
From only the command line, you would need to:
Install a command line web browser OR you can use wget to hit the script and save the response in a file.
Have a php file with <?php phpinfo(); in all of the domains
Make sure that all the domains are able to be loaded on the webserver or the webserver has internet access to load the domains directly from web. Best would be to map all the domains to localhost in the hosts file.
Open the phpinfo script from each domain in the command line browser and check the loaded configuration file OR if you have chosen to use wget, just save the output to file and inspect the contents of the file and you would get the loaded config file.
I am using PHP 5.5.25 with Apache 2.4 on Windows 7 x64 and I am unable to activate the cURL module. I have looked around and tried all I could think of. Please assist:
In php.ini, the line extension=php_curl.dll is active and the file php_curl.dll is present in the extensions directory C:\php\ext
In php.ini when I set extension_dir = ext, none of the extensions load. I get several messages when Apache starts, similar to Unable to load dynamic libraryext\php_openssl.dll- The specified module could not be found.
When I use the full path and set extension_dir = C:\php\ext, all the extensions load fine, except for cURL. I get the error: Unable to load dynamic libraryC:\php\ext\php_curl.dll- The specified module could not be found.
I have tried renaming the extension to php_curl.new.dll and adjusting php.ini but I get an error message about the new filename. I have also downloaded a fresh new copy of the DLL from windows.php.net, but that made no difference.
I have checked the file permissions for php_curl.dll (Right-click on the file >> Properties >> Security tab) and they are the same as the permissions for extensions that load successfully
I have copied and pasted libeay32.dll and ssleay32.dll from the PHP bin directory to the System32 and SysWOW64 directories as instructed by a response to this question
I am certain that I am editing the right php.ini since the PHP startup error messages changed when I changed the extension_dir value from ext to C:\php\ext as I explained above.
I have made sure to restart the Apache server between php.ini configuration changes.
If in a PHP script I execute var_dump(file_exists('C:\php\ext\php_curl.dll'));, I get boolean True so PHP can see the file!
What else could explain why the cURL module is not enabled?
I think you'll need libssh2.dll in your PATH too.
Credit goes to #Steven Hilder for pointing me in the right direction.
The problem was that Windows could not see libssh2.dll, another DLL that was in PHP's directory. Copying this file to C:\Windows\SysWOW64 and C:\Windows\System32, along with the other two DLL files from my OP (libeay32.dll and ssleay32.dll) worked.
I am uncomfortable with this solution though because when the time comes to update to a new PHP version I will have a harder time remembering to overwrite these DLLs with the new version.
Therefore, I decided to remove all 3 DLLs from the System32 and SysWOW64 directories. Instead, I just added the PHP bin directory to the Windows' PATH variable, so that the next time the OS is looking for a missing file, it will also look in that directory. This has the added bonus that if a similar problem with another DLL occurs, it will be resolved automatically.
To add the PHP bin to Windows' PATH:
From the Start Menu search bar, search for and select Advanced system settings
Click Environment Variables. Scroll down the list of System variables to select Path and click Edit... to open the current PATH setting
Append ;C:\php or whatever directory has php.exe to the current setting (semi-colon is used to separate paths).
on windows the cURL execution wants SSL certificate. may be because of that others error is showing.
Put the below code before curl_exec(curlHandle) to ignore checking for SSL certificate
//to ignore the SSL certificate in windows
curl_setopt($curlHandle, CURLOPT_SSL_VERIFYPEER,false);
While learning to set up php to be able to send mail I came across the need to edit the php.ini file. The problem is that when I go to <localhost>/~username/phpinfo.php it tells me it is located at /Library/Server/Web/Config/php however the Web directory does not exist on my server. So where is my php.ini file? I have looked at answers to the same question by others and still was not able to find it. If I need to create it, how do I go about doing that?
I am using a macbook pro as my server running Yosemite.
Thanks in advance!
UPDATE:
So it looks like I found my php.ini file but it is not where php says it is looking phpinfo.php says its looking in /Library/Server/Web/Config/php should I copy the file to this location? also my file is actually named php.ini.default, does this need to be named as just php.ini?
execute this command
locate php.ini
This will give you a list of all files with names where 'php.ini' is a part of it.
E.g.
/etc/php.ini
/etc/php.ini.rpmnew
/home/myuser/mywebsite.com/demo/local_php.ini
...
I'd rather do this:
php -i | grep ini
It will give you the info for ini configuration in the php console client. If you are executing apache or nginx you can see all the PHP settings with
<?php
echo phpinfo();
I'm having a weird situation here.
I'm trying create a PDO object, like this:
$dbh = new PDO('mysql:host='.$hostname.';dbname='.$dbname,$username, $password);
I have rewriting ON in my .htaccess file. when I try to run the script using a URL that will trigger a rewrite rule, it shows me the following error:
Fatal error: Class 'PDO' not found
I have a exception rewrite rule for a directory where the script is, named PHP, like this:
RewriteRule ^(php)($|/) - [L]
if I run the scripting directly from the directory, it runs normally with no erros.
I don't know why this is happening. any clues?
Thank you
Edit: Ok, I saw I've misinterpreted your question a bit, but I still think there is something wrong about the php.ini path. Could you check the phpinfo() output of both web calls. The basic idea of the answer keeps the same as stated below (replace CLI with the second web call ;))
OLD ANSWER
Assuming, that you have one of the more common linux distributions (ubuntu, debian, suse, etc), you might have two (or more) php.ini files. One that is pulled when using the webserver module (which seems to be an apache) and one that is used for the cli env. php supports up to one php.ini per SAPI.
In newer debian and ubuntu systems php extensions are linked in the same manner as the sites-available/enabled in the apache config.
If you have a self compiled php look for a php-cli.ini at the common location for the php.ini (which is /usr/local/share/php by default). If a php-cli.ini is present it will be used instead of the php.ini for cli commands.
(Manual Reference: http://de2.php.net/manual/en/configuration.file.php)
How to find out:
Get the phpinfo() output for the INFO_GENERAL section from you webserver. To achieve this, create a simple php file in a web-accessible directory (e.g. the DocumentRoot). Remember to delete it after you got the information you need! Please adjust the '/var/www' to something that matches your config.
$> echo '<?php phpinfo(INFO_GENERAL);' > /var/www/info.php
Now go to your browser and open http://your.host.name/info.php and look for the config property "Configuration File (php.ini) Path". Note this somewhere or just leave the page open for later reference.
On your cli this is also quite easy. The example below is a snip from my shell.
mmueller#bsd ~$ php -i | grep ini
Configuration File (php.ini) Path => /usr/local/etc/php/5.5
Loaded Configuration File => /usr/local/etc/php/5.5/php.ini
[... omitted the tail]
Compare the two paths and see if they are different.
To see why this happens, please take a look at the 'Configure Command' section. You mighty find three important configure arguments. Those three influence where php looks for it's configuration.
'--sysconfdir=/usr/local/etc/php/5.5'
'--with-config-file-path=/usr/local/etc/php/5.5'
'--with-config-file-scan-dir=/usr/local/etc/php/5.5/conf.d'
If you want to ensure the same configuration, you can do one of the following things:
Just add extension=pdo_mysql to the webserver version and see if that is enough
Remove the additional CLI config (if present), this will make php use the php.ini for all SAPIs (make a backup of the file before you do that!). Then you need to merge the rules into the php.ini that you need. (In your case there seems to be an extension=pdo_mysql missing)
Check the webserver php.ini for anything that you do not want to have in the cli version, then copy the webserver php.ini over the CLI php.ini (Do a backup first).
Delete the cli or webserver php.ini, symlink the other php.ini to the place of the deleted one. (not the best way, but I've seen that a lot on customer servers).
Solve it.
There was a empty php.ini in the public_html, I deleted it, and it worked.
thank u all