I've set up an ejabberd install locally on my Windows box, where I also have Apache, PHP and MySQL. I've also confirmed that it works great using Digsby, and have kicked the tires a bit by creating some users, sending some messages, etc. All good.
However, PHP can't open a stream using stream_socket_client to port 5222. Even at its simplest level:
stream_socket_client("tcp://localhost:5222", $errno, $errstr, 30, STREAM_CLIENT_CONNECT);
Returns a timeout error. However, again, connecting with an IM client to localhost on port 5222 works fine. (Using stream_socket_client to open a simple connection to localhost on port 80 also works.)
Any ideas? I'm stuck!
selinux needs to be off, or allow apache to talk to xmpp
Many servers don't listen on the loopback device by default, or only listen on ::1 or 127.0.0.1 and have localhost pointing to the other. Check by doing:
% netstat -an | grep 5222
and checking the output for a LISTEN line that shows where your server is listening.
Finally, try using the IP address of your box explicitly as the connection hostname.
Sometimes you just need to peek on the line to see exactly what is going on. Windump(tcpdump) is your friend in these cases.
Related
I am currently using WAMP server on my Windows XP SP2 system. I just want to know why do I need to use localhost:8080 instead of just localhost to connect to my server-WAMP? I'm not that interested in this :8080 stuff.
So if you guys know why this happens, or how to exclude :8080 from the address, just help me through. Thank you very much by the way. Have a nice day.
Notice: Please don't tell me to switch to XAMPP. I know it works well.
This happens because your server is listening on port 8080, and not on port 80 which is the default (so when you type localhost you mean localhost:80).
So, you need to change your configuration to make WAMP listening on port 80. You find here how to do this: How to change port number for apache in WAMP.
OS: CentOS 6.4
I am trying to connect to the RabitMQ server using the php client as follows,
$connection = new AMQPConnection('10.1.150.109', 5672, 'guest', 'guest');
$channel = $connection->channel();
But when I ran the script from the browser, it gives me this,
exception 'PhpAmqpLib\Exception\AMQPRuntimeException' with message 'Error Connecting to server(13): Permission denied ' in /var/www/html/event/vendor/videlalvaro/php-amqplib/PhpAmqpLib/Wire/IO/StreamIO.php:27
netstat show this,
tcp 0 0 :::5672 :::* LISTEN 10776/beam
In this post, this guy gives the answer implicitly, Client can't connect to RabbitMQ server on localhost. But he has not described the procedure which he followed to fix the issue.
I thank you in advanced for anyone who can help me in this regard.
Since I don't like the accepted answer, here's one I think is better.
Disabling SELinux is a hack. It may work but it's probably not a good idea. What isn't immediately obvious from the question (or the other question it references) is HOW the php client is being run. I.e. from the command line or via a browser.
SELinux by default won't allow httpd (i.e. apache) to connect to port 5672.
In my case, running the php script from the command line works - the connection is accepted. However, running it from a browser fails because of this SELinux policy.
I imagine that "reconfiguring the listen address from 0.0.0.0 to 127.0.0.1" is a reference to the hostname parameter, which in my case is set to "localhost" rather than an explicit IP address. (For sure 0.0.0.0 is going to fail!)
You can enable httpd to access port 5672 in SELinux: https://serverfault.com/questions/563872/selinux-allow-httpd-to-connect-to-a-specific-port
what happens if you
telnet 10.1.150.109 5672
We send some files across to a third party with a PHP cron job via FTP.
However sometimes we get the following error:
ErrorException [ 2 ]: ftp_put(): php_connect_nonb() failed: Operation
now in progress (115) ~ MODPATH/fileop/classes/Drivers/Fileop/Ftp.php [ 37 ]
When I say "sometimes" I mean exactly that; most times it goes across fine but about 1 in 5 times we get that error. It's not to do with the files themselves, because they will go happily if we try again.
We've found similar issues online - relating to a bug in PHP with NAT devices or to do with firewall configuration but again the implication is that if this were the case it would never work.
So, why would this work some times and not others?
ftp_set_option($ftpconn, FTP_USEPASVADDRESS, false);
This line of code before setting passivity of the connection ftp_pasv($ftpconn, true);
Solved my problem
FTP(S) uses random ports to set up data connections; an intermittent success rate indicates that not all ports are allowed by a firewall on the client and/or server machines. The port range for incoming (PASV) data connections can be set in the FTP server.
This page has a nice summary:
The easy way is to simply allow FTP servers and clients unlimited
access through your firewall, but if you like to limit their access to
"known" ports, you have to understand the 4 different scenarios.
1) The FTP server should be allowed to accept TCP connections to port
21, and to make TCP connections from port 20 to any (remote ephemeral)
port.
2) The FTP server should be allowed to accept TCP connections to port
21, AND to accept TCP connections to any ephemeral port as well!
3) The FTP client should be allowed to make TCP connections to port
21, and to accept TCP connections from port 20 to any ephemeral port.
4) The FTP client should be allowed to make TCP connections to port
21, and to make TCP connections to any other (remote ephemeral) port
as well!
So, I'm writing this answer after doing some investigation on my FTP server and reading the link you provided elitehosts.com.
I'm using FileZilla FTP server, and there is a specific setting that I had to enter to make it work. Going into the server settings, there is an area titled "Passive mode settings". In that dialog, there is an area titled "IPv4 specific", and within that area there is a setting labeled "External Server IP Address for passive mode transfers:". It's a radio button selection set, and it was on "Default", but since the FTP server is NAT'ed, I changed that radio selection from "Default" to "Use the following IP:" and entered in the external-facing IP address of my gateway provided by my ISP.
After I set this up, it worked! Not terribly sure if your FTP server is NAT'ed, but I thought I would provide the answer on this thread because it seems related.
In addition to Cees answer, I am running vsftp on ec2 and had to comment out the listen_ipv6=YES, listen=YES then "service vsftpd restart".
Although documentation says it will listen on ipv4 as well it wasn't and this resolved the issue.
For me all I had to do was to remove the ftp_pasv( $ftpconn, true ); and everything worked perfectly. I'm not yet sure why but I am trying to find out and I will surely come back when I do get the reason behind it.
This should be a comment under jj_dev2 comment, but I cannot add one due to reputation. But maybe it will be helpful for someone, so I post it here.
We had the same issue as described in the original post. In our case it worked with many customers - except one.
The solution in jj_dev2 comment did work for us. So we investigated what does ftp_set_option($conn, FTP_USEPASVADDRESS, false) actually do. And based on that we found out that in fact customer's FTPS server was configured incorrectly.
In response to PASV command (ftp_pasv($conn, true)) FTP server returns an IP address which the PHP FTP client then will use for data transfers. In our case the FTP server was returning an internal IP address and not the public IP address that we connect to. Customer had to fix their FTP server settings so FTP server would send external IP address in the PASV command response.
I am getting a bit desperate after hours of research:
A Windows 7 computer with a local PHP application that listens to port 12345 with a socket.
From the same Windows 7:
If I do telnet localhost 12345, the php code sees the connection.
If I do telnet 127.0.0.1 12345, the php code sees the connection.
If I do telnet <local_ip_address> 12345, the php code DOES NOT see the connection.
If I do telnet <dns_name> 12345, the php code DOES NOT see the connection.
From another machine I don't have any connection at all when I use the ip or the dns address.
Doing a telnet from another machine with the same address but on ports 80 or 21 work perfectly.
Even with the local firewall / antivirus disabled I get the same result.
I am using a standard Apple TimeCapsule as access point, but not configured specially, not sure if that can influence for ports > 1024...
Would you have any idea for me ?
Thanks !
There are really 2 options to get this behavior that I can see;
Your firewall is enabled (which you tested)
Your socket is binding to 127.0.0.1 instead of your public IP.
I'd have a look at your local binding, aka the address you give to socket_bind().
If it says "127.0.0.1", change it to 0.
telnet 12345 is trying to connect to a machine whose IP is 12345 decimal, aka 0.0.4.210 in dotted quad format. You cannot use telnet like that - the argument cannot be simply a port number. It'll be interpreted as an IP.
I'm developing website for my school. In that school we authenticate users via LDAP, so there was an idea to do the same via school-site. On that site everything is working perfectly, but during developing I need very often to test if such solution works, of not. In order not to commit my changes so often I want to test this site on my local computer, but for connecting with LDAP i want to use ssh tunnel. In school network we have one server through witch we are connecting with inside of our school network. It's address is phoenix.lo5.bielsko.pl. Inside this network we have LDAP server with opened 389 and 636 ports. It's address is auth.lo5. I don't have access to auth.lo5 via SSH, I can only connect with it to get some LDAP entries. So, I've tried to run SSH tunnel by running:
ssh -L 636:auth.lo5:636 hfaua#phoenix.lo5.bielsko.pl
Then, I've set in my /etc/hosts that auth.lo5 is pointing to 127.0.0.1. I'm connecting to LDAP in PHP in such a way:
ldap_connect('ldaps://auth.lo5', 636);
But I'm getting error Can't contact LDAP server. I think, that problem might be on phoenix.lo5.bielsko.pl in its SSH daemon config or in arguments passed to ldap_connect() function. Can you tell me, what should I set in sshd_config or in arguments passed to ldap_connect to get it working?
I posted the same question in similar thread, but no one has answered my question.
P.S. In my /etc/ssh/sshd_config I have line AllowTcpForwarding yes
If I got it right phoenix.lo5 and auth.lo5 are 2 different machines.
If so you have to create a tunnel to the ssh machine, and then send the ldap queries to the right machine.
Your command: ssh -L 636:auth.lo5:636 hfaua#phoenix.lo5.bielsko.pl is right if phoenix.lo5.bielsko.pl can resolve auth.lo5 via DNS or /etc/hosts, if not you need to use its internal ip address.
Also if you want to use port 636 on your pc, you need to run your command as superuser (root or with sudo) else you need to use an high port (above 1024) as stated by Borealid
Once the tunnel is up you have to point to localhost to do the queries
I ran into this same issue. Running with -d1 showed me this error:
TLS: hostname (mylaptop.local) does not match common name in certificate (*.mydomain.com).
TLS reverse lookup of 'localhost' is 'mylaptop.local', checking if that matches the certificate common name
Could be you're hitting a similar problem.
I was able to fake it out by running:
sudo hostname someserver.mydomain.com
which caused SSL to assume it was talking to the right host.
I was also getting the error hostname (mylaptop.local) does not match common name in certificate (*.mydomain.com). However I did not want to edit the hostname of my machine to match that of the LDAP server. Instead I edited the hosts file (etc/hosts on linux) file to add a line that would intercept requests to the LDAP server eg:
127.0.0.1 ldap.server.com
This has the added benefit of not requiring you to change which server name you are trying to connect to in your code, you only need to change the port number if you chose a different port.
Try replacing all instances of auth.lo5 with localhost:
ssh -L 636:localhost:636 hfaua#phoenix.lo5.bielsko.pl
and
ldap_connect('ldaps://localhost', 636);
If that doesn't work, try turning off SSL to see if that works:
ssh -L 389:localhost:389 hfaua#phoenix.lo5.bielsko.pl
and
ldap_connect('localhost', 389);