i have react with asp.net core website . it worked fine on localhost but when published on iis remote server the timeout error occurs.
the front-end (react client) and back-end(server) asp.netcore webapi work independently.
before uploading i changed the following in program.cs in webapi.
usUrl("https://localhost:4000")
to useUrl("https://www.virtualcollege.pk:4000")
i also changed the front-end baseurl similarly.
moreover, the connectionstrings in appsettings.json is correct for both databases.
i added migration and updated the databases successfully.
the website is live but timeout error occur :
virtualcollege.pk
i also tried the url with "https://myip-address:4000"
thanks in advance for help.
if i remove port number from url and publish on local folder than upload to remote server . the webapi.exe on local machine runs as follows:
You have to open incoming request for 4000 port. Try some methods below.
Windows Server
Please check this link or this one
Ubuntu/Debian
sudo ufw allow 4000/tcp
sudo ufw status // check status
CentOS
First, you should disable selinux, edit file /etc/sysconfig/selinux so it looks like this:
SELINUX=disabled
SELINUXTYPE=targeted
Save file and restart system.
Then you can add the new rule to iptables:
iptables -A INPUT -m state --state NEW -p tcp --dport 4000 -j ACCEPT
and restart iptables with /etc/init.d/iptables restart
Related
I have installed and run laravel in my windows server(hosted server) with the use of "php artisan serve" command. It worked well with "http:localhost:8000" inside the server but when I try with public url of server like "http:example.com:8000" it doesn't worked for me.
I couldn't understand.Inside the windows server worked fine but outside not working.
Also I checked the firewall with the 8000 port, no issue.
edit hosts file and add domain to local
127.0.0.1 example.com
I get the error "Error occurred while requesting version information: Connection refused" when I test the connection in Jenkins configuration for Artifactory plug-in. I have tried it with Anonymous access enabled in Artifactory, with Anonymous access disabled, and tried all three options (Supported, Unsupported, Required) for Password Encryption in Artifactory. I have Default Deployer Credentials in my Jenkins Artifactory configuration, and I have tested the connection with 'Use Different Resolver Credentials' and without. I consistently get this error.
Any help/ideas would be greatly appreciated
I also ran in a similar problem yesterday.
Problem:
I was running jenkins and artifactory in two different docker containers on my local. I had exposed port 8086 for artifactory and could access it using http://localhost:8086/artifactory in my browser. But giving the same url for artifactory in jenkins produced the above reported error in question.
Solution:
For some unknown reasons, jenkins artifactory plugin couldn't resolve http://localhost:8086/artifactory even though the docker mappings was correct and it was possible to connect to artifactory web based console with the same URL.
Replacing "localhost" with docker container IP did the trick.
Name of my container in which artifactory was running was docker-plgr_artifactory_1
Admins-MacBook-Pro-2:~ prakash.tiwari$ docker exec -it docker-plgr_artifactory_1 cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.18.0.2 08038bc9449b
The IP of container was 172.18.0.2. So I replaced http://localhost:8086/artifactory with http://172.18.0.2:8081/artifactory and jenkins was now able to connect to artifactory. (8081 is the port in docker container at which artifactory was running. You'd have given it at the time of running the container. Alternatively, you can find it by running docker ps and checking the value under PORTS field.)
Credit: https://www.arvinep.com/2016/04/jenkins-docker-container-problem.html
Note: I know this solution doesn't explain the cause and why it works, but I hope it at least helps some people and saves their time.
I see that you asked this question a while ago. I just had to deal with a very similar situation. I had loaded the root and intermediate certificates into the cacerts files found under the 4 version of Java on the build server. The problem was that Jenkins uses it's own cacerts file found in the Jenkins install folder. Once I loaded the certs there I was able to test the connection to artifactory and upload the build artifacts. I hope this helps
I'm using Java but this isn't necessarily a Java question. Google's "java-compat" image is Debian (3.16.7-ckt20-1+deb8u3~bpo70+1 (2016-01-19)).
Here is my Dockerfile:
FROM gcr.io/google_appengine/java-compat
RUN apt-get -qqy update && apt-get qqy install curl xvfb x11vnc
RUN mkdir -p ~/.vnc
RUN x11vnc -storepasswd xxxxxxxx ~/.vnc/passwd
EXPOSE 5900
ADD . /app
And in the Admin Console I created a firewall rule to open up 5900. And lastly I am calling the vnc server itself in the "_ah/start" startup hook with this command:
x11vnc -forever -usepw -create
All seems to be setup correctly but I'm unable to connect with TightVNC. I use the public (ephemeral) IP address for the instance I find in the Admin Console followed by ::5900 (TightVNC requires two colons for some reason). I'm getting a message that the server refused the connection. And indeed when I try to telnet to port 5900 it's blocked.
Next I SSH into the container machine and when I test the port on the container with wget xxx.xxx.xxx.xxx:5900 I get a connection. So it seems to me the container is not accepting connections on port 5900. Am I getting this right? Is it possible to open up ports and route my VNC client into the docker container? Any help appreciated.
Why I can't use Compute Engine. Just to preempt some comments about using google's Compute Engine environment instead of Managed VMs. I make heavy use of the Datastore and Task Queues in my code. I don't think those can run (or run natively/efficiently) on Compute Engine. But I may pose that as a separate question.
Update: Per Paul in the comments... having learned some of the docker terminology: Can I publish a port on the container in Google's environment?
Out of curiosity - why are you trying to VNC into your instances? If it's just for management purposes, you can SSH into Managed VM instances.
That having been said - you can use the network/forwarded_ports config to route traffic from the VM to the application container:
network:
forwarded_ports:
- 5900
instance_tag: vnc
Put that in your app.yaml, and re-deploy your app. You'll also need to open the port in your firewall (if you intend on accessing this from the public internet):
gcloud compute firewall-rules create default-allow-vnc \
--allow tcp:5900 \
--target-tags vnc \
--description "Allow vnc traffic on port 5900"
Hope this helps!
I am trying to run a node.js server and a Redis server on an Amazon AWS Ec2 micro instance .
I have installed Redis Server and the redis-server command runs fine .
I use 'Forever' to keep the Redis-Server running . And it works fine .
But when I start my Node server , it fails to connect to the Redis-Server .
It gives the following error -
Error Error: Redis connection to 127.0.0.1:6379 failed - connect ECONNREFUSED
Doing a 'Forever List' shows that the redis server is running fine .
info: Forever processes running
data: uid command script forever pid logfile uptime
data: [0] _pXw node app.js 26670 26671 /home/ubuntu/.forever/_pXw.log 0:0:0:13.463
data: [1] ylT1 node redis-server 25013 26681
I have verified that when the redis-server starts , it starts at 6379 port .
Can anyone help me explain why this error is happening and how I fix this ?
I use the following code to connect to Redis . I have the client libraries installed for Redis .
var redis = require("redis"),
client = redis.createClient();
Everything runs fine when I run the code on my localhost .
If you are going to use Redis outside of AWS you can try next steps that helped me to connect Redis Server working on AWS from my local Nodejs application:
1) On AWS: sudo cp /etc/redis/redis.conf.backup /etc/redis/redis.conf. Backup saves you a lot of energy figuring out whats wrong :)
2) On AWS: stop redis-server: sudo /etc/init.d/redis-server stop
3) On AWS: open /etc/redis/redis.conf and find a line bind 127.0.0.1. Copy and paste new line below bind 0.0.0.0. So you could have several lines with bind parameter. BTW, port of connection can be changed in redis.conf as well
4) On AWS: start redis-server: sudo /etc/init.d/redis-server start
5) On AWS: type redis-cli ping you should see PONG message if redis-server started ok
6) On AWS: Now open Sequrity Group for your running isntance and add New Rule with "Type" - Custom TCP Rule, Port Range - 6379
7) In your local Nodejs application:
var redis = require("redis");
var redisClient = redis.createClient(redis_port, redis_host);
nodejs redis aws
Have you checked the redis client-server connection on AWS using the ping-pong routine. Next maybe you should try running it without forever, as root.
I've been running nagios for about two years, but recently this problem started appearing with one of my services.
I'm getting
CRITICAL - Socket timeout after 10 seconds
for a check_http -H my.host.com -f follow -u /abc/def check, which used to work fine. No other services are reporting this problem. The remote site is up and healthy, and I can do a wget http://my.host.com/abc/def from the nagios server, and it downloads the response just fine. Also, doing a check_http -H my.host.com -f follow works just fine, i.e. it's only when I use the -u argument that things break. I also tried passing it a different user agent string, no difference. I tried increasing the timeout, no luck. I tried with -v, but all it get is:
GET /abc/def HTTP/1.0
User-Agent: check_http/v1861 (nagios-plugins 1.4.11)
Connection: close
Host: my.host.com
CRITICAL - Socket timeout after 10 seconds
... which does not tell me what's going wrong.
Any ideas how I could resolve this?
Thanks!
Try using the -N option of check_http.
I ran into similar problems, and in my case the web server didn't terminate the connection after sending the response (https was working, http wasn't). check_http tries to read from the open socket until the server closes the connection. If that doesn't happen then the timeout occurs.
The -N option tells check_http to receive only the header, but not the content of the page / document.
I tracked my issue down to an issue with the security providers configured in the most recent version of OpenSUSE.
From summary of other web pages it appears to be an issue with an attempt to use TLSv2 protocol which does not appear to work correctly, or is missing something in the default configurations to allow it to work.
To overcome the problem I commented out the security provider in question from the JRE security configuration file.
#security.provider.10=sun.security.pkcs11.SunPKCS11
The security.provider. value may be different in your configuration, but essentially the SunPKCS11 provider is at issue.
This configuration is normally found in
$JAVA_HOME/lib/security/java.security
of the JRE that you are using.
Fixed with this url in nrpe.cfg: (on Deb 6.0 Squeeze using nagios-nrpe-server)
command[check_http]=/usr/lib/nagios/plugins/check_http -H localhost -p 8080 -N -u /login?from=%2F
For whoever is interested, I stumbled in this problem too and the problem ended up being in mod_itk on the web server.
A patch is available, even if it seems it's not included in the current CentOS or Debian packages:
https://lists.err.no/pipermail/mpm-itk/2015-September/000925.html
In my case /etc/postfix/main.cf file was not good configured.
My mailserverrelay was not defined and was also very restrictive.
I should to add:
relayhost = mailrelay.ext.example.com
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination