do you know any alternative port number for zend server ?
because my port 80 is already occupied by xampp
<?php echo "help me install"; ?>
Usually Zend Server Administration runs on port 10081 by default and localhost on port 80. If you don't like this or another port, choose any free port you like :). Here is how you check what ports are used, open, closed, etc.
Windows
netstat -a -n
Linux
netstat -nap
As hakre commented, Zend writes the following about Zend Server and ports:
Q: What is my port number?
In most cases, your Web server's port number will be 80. If your port number is 80, you can omit the parameter from your URL when browsing to your Web pages (i.e. you can browse to http://localhost/ without specifying a port number).
In the following circumstances, your port number will be different:
You are running Zend Server on Mac OS X. In this case, the default port number will be 10088.
You installed Zend Server using the Generic Tarball package on Linux. In this case, the default port number will be 10088.
You modified the port number on which Zend Server listens, during or after installation.
Related
I am on windows 10 using chrome but I have tested in edge/firefox as well.
I have installed the latest version of xampp and myphp. When I go to http://localhost/phpmyadmin/ all I get is a blank page... with nothing at all on it.
Also in an unrelated note Apache wont start and complains about port 80 being blocked or unavailable. I don't think that's related but other than what comes with windows 10 I don't have any real extra security installed on the machine.
I'm terrible at this stuff so use small words D: well... at least simple steps :D
You can change your Apache port in its config file or you need to stop the services that use port 80.
The common services that use port 80 is Skype or IIS.
Quit your Skype and restart XAMP if your Skype is on.
To completely solve this conflict,
Go to Skype and click on Tools
Then click on Options
Under advanced tab click on connection and then remove the check mark from Use port 80 and 443 for additional incoming connections
I want to use PHP 7 when it comes out, but my server admin refuses to upgrade past PHP 5.3.3 and I don't have root privileges. I can run a webserver on port 1024 or higher, but I need it to be available on ports 80 and 443.
I am considering connecting to this userland webserver via a local SOCKS client in PHP. Can I effectively run a PHP 7 webserver on port 80 and 443 this way, and will it be possible to handle PHP requests and sessions correctly?
No. Port 80 is a privileged port.
I have a application in nodejs and PHP. For now i am using different both.
Can i run node and apache both on same port 8080
Is, there is any way to run any application both on 8080
Thanks
An port is usually connected only to one application. So you have to use different ports.
Proxy -
But you could for example create an virtual host in apache and configure this host as proxy. In this configuration you could access the node.js server on the same port. The node.js server would run on another port.
For TCP based applications, no. You can have only one application listening on a single port at time. If you had 2 network cards, you could have one application listen on the first IP and the second one on the second IP, both using port 8080.... but I doubt that is your case.
I guess you can run them on UDP protocol, which could allow you to have two applications listen to the same port, but as UDP is unreliable and it doesn't establish connection, just sends/receives packets. You might experience big packet loss on UDP.
So, short answer - no.
Actually, there might be a way using iptables. Add a rule of this nature
iptables -A INPUT \
-p tcp \
-m bpf --bytecode "14,0 0 0 20,177"
-j redirect .. Port 80
Check the first few bytes of the connection, and redirect the connection. Then you can accept both http and node.js on the same port, but have the servers running on separate ports.
The syntax above is incorrect, and I have not tried it, but I know people who have used this strategy successfully.
I have XAMPP 1.7.3a running on an "Amazon Linux" (Centos-derived) 32-bit instance in the Amazon EC2 cloud. I downloaded/built/installed XDEBUG 2.1.0. The relevant items in phpinfo() output look like this:
Directive Local Value Master Value
xdebug.idekey ECLIPSE_DBGP ECLIPSE_DBGP
xdebug.default_enable On On
xdebug.remote_autostart On On
xdebug.remote_connect_back Off Off
xdebug.remote_cookie_expire_time 3600 3600
xdebug.remote_enable On On
xdebug.remote_handler dbgp dbgp
xdebug.remote_host 127.0.0.1 127.0.0.1
xdebug.remote_mode req req
xdebug.remote_port 9000 9000
xdebug.remote_log /opt/lampp/logs/xdebug_log
/opt/lampp/logs/xdebug_log
I access the Linux box from a Windows laptop running XP SP3, using the SSH client in PuTTY version 0.60. Also on the laptop I've installed Eclipse PDT (Helios Service Release 1 Build id: 20100917-0705), and I think I've got it configured correctly to do XDEBUG remote debugging using port 9000. I say I think, because I've had difficulty figuring out how to do that, and how to use Eclipse PDT in general. But I did manage to get it configured and working for "remote" debugging of PHP code run by web pages served using XAMPP for Windows 1.7.3 on localhost (127.0.0.1), using port 9000. The phpinfo() output for the server on the laptop which PDT is able to debug is the same as above, except for:
xdebug.idekey my_username no value
xdebug.remote_host localhost localhost
xdebug.remote_log no value no value
I'm pretty sure these differences are not related to the problem. In fact, xdebug.idekey was originally "root novalue" on Linux, which I then changed to ECLIPSE_DBGP by both editing php.ini and setting environment variable DBGP_IDEKEY in the sudo-ed script that starts apache, in vain hope of getting things working.
I've got firewalls and a NAT router between the laptop and the Linux box. So I am trying to use port forwarding through a PuTTY ssh tunnel to get the Linux XDEBUG talking to the Windows PDT. I've been using X11 forwarding with PuTTY for a couple of months with no problems at all. I set up the tunnel in PuTTY with local port 9000 forwarded to port 9000 on the Linux box, and port 9000 on the Linux box forwarded to port 9000 on 127.0.0.1, the PuTTY tunnel panel showing:
L9000 host...amazonaws.com:9000
R9000 127.0.0.1:9000
Looking at the PuTTY Event Log when the tunnel is set up, there appear to be no problems:
2010-11-16 18:07:59 Local port 9000 forwarding to host...amazonaws.com:9000
2010-11-16 18:07:59 Requesting remote port 9000 forward to 127.0.0.1:9000
2010-11-16 18:07:59 Remote port forwarding from 9000 enabled
But then when I go to PDT and click Debug on a configuration that specifies the remote web server, PDT shows background activity in the lower right corner that gets stuck at 57%, and if I click the icon to go to Progress view, that shows "Launching: waiting for XDebug session".
When this happens, the PuTTY Event Log shows:
2010-11-16 19:05:42 Received remote port 9000 open request from 127.0.0.1:54474
2010-11-16 19:05:42 Attempting to forward remote port to 127.0.0.1:9000
2010-11-16 19:05:42 Forwarded port opened successfully
2010-11-16 19:05:42 Opening forwarded connection to host...amazonaws.com:9000
2010-11-16 19:05:42 Forwarded connection refused by server: Connect failed [Connection refused]
2010-11-16 19:05:42 Forwarded port closed
On the Linux box, /var/log/secure just shows:
Nov 16 19:01:51 ip-10-194-9-67 sshd[14555]: error: connect_to host...amazonaws.com port 9000: failed.
I've checked my /etc/ssh/sshd_config, and I think it's okay, even changing it explicitly to "AllowTcpForwarding yes", even though that is supposed to be the default. In my web searches for a solution, I did come across one linuxquestions posting where the final reply says something rather cryptic about sshd needing to resolve a hostname:
this seemed to fix it:
The hostname has always been domain-serv, since I always
thought of my router as being domain.com...so after running
hostname domain.com...bam! It finally works...
I guess sometimes it is too simple. sshd had to be resolving domain.com
to my router, ergo the connection failed.
I sounds like this might be related to my problem, but it makes no sense to me, and since it's pretty old, and the author didn't seem to understand it, either, I thought I would ask here rather than there...
I did notice that a similar question was asked in this forum almost a year ago that got just one 0-value response, presumably because the question was so lacking in detail as to be unanswerable. I hope this one has enough information, and isn't so long, so that somebody can steer me right. After reading the faqs and how to ask a question, it wasn't entirely obvious to me whether the correct use of the forum was to post something under that original poorly-asked but content-identical question, or to post this new one - I'm sure someone will let me know what was the right choice on that :-)
I've been going nuts with this thing, and I suspect it's something pretty obvious to someone with experience. I'm a noob to most of this stuff (PHP, web programming, network admin, and this forum), though not to old-fashioned C programming and user-level Linux and Windows setup.
How embarrassing, apparently my port forwarding setup was something only a network noob would do? I guess I had decided that since the Xdebug running on the web server needs to talk to the PDT debugger client on the laptop, and the PDT debugger client on the laptop also needs to talk to Xdebug on the server, and there's only one port number (9000), that therefore I needed to forward local port 9000 to remote port 9000, and also forward remote port 9000 to local port 9000; I was confusing the direction of traffic with which side is the client initiating a (bi-directional) connection to a specific port that the server side is listening to.
What seemed to be happening was that the PDT debugger running on the laptop got stuck waiting for Xdebug running on Linux to make a connection. Since I couldn't really think of a situation where Xdebug would need to be listening to port 9000, waiting for the PDT debugger to initiate a connection (rather it would be waiting for the PDT debugger to send it a command over a connection that had already been established by its opening port 9000 when it saw the XDEBUG_SESSION parameter in the request), I decided just to get rid of the forwarding of local port 9000 to remote port 9000. I did that, and all of a sudden PDT was receiving the connection sent from the Linux server, and debugging proceeded normally from there.
But what's still not clear in my mind is why having the additional forwarding actually caused a problem. Couldn't it be possible for a pair of programs on different hosts to operate such that, depending on state, sometimes one was the listener and sometimes the other was? As long as the forwarding doesn't cause them both try to listen on the same port at the same time, I'd expect that to be okay.
Bottom line is that things seem to be working now because of a simplification I made, but I'd like to understand why the unneeded complexity actually caused a problem. I've read a lot of stuff, including the excellent explanation of ssh and tunneling in the O'Reilly book, but I still don't get it.
Lets us consider a case, there are 2 apache server running, and one domain is available.
if we make a request like this, http://domain1.com/example1.php it should request one
apache server where actual domain is present. When http://domain1:8000/example1.php it should point to a application in a another server (other machine) under a same domain group.
Now a question is, if http://domain1:8000/example1.php is requested, then it will run in which server? which server will interpret it? which server will execute those files, either apache server in domain1 system or, a apache server that domain1:8000 (this is other machine, to which request is port forwarded) points?
A server will listen on a specific port, so if you are using different ports, it will go to whatever server is listening on that port, regardless of the domain.
Since you're using port forwarding, then it can only be processed by where ever you forward the ports to. So, port 80 is being forwarded to your main server and port 8000 to the other server. If you didn't forward, and all were going to the first server, then you would get an error if the first server were not also listening on port 8000.