I'm currently developing a Wolkenkit application which is run on my local machine.
I want to upload a file from the Wolkenkit app to the blob server (as documented here).
When sending a POST request from the server to https://local.wolkenkit.io:3001/, Node.js gives me the error ECONNREFUSED.
I've tested the POST-Request with another program and it works there. Any idea why it doesn't work from the wolkenkit application itself?
Thanks!
The Storing files sample you linked to shows code that is to be run in the browser, not in the backend itself. Of course, both should work, but there are a few minor differences you need to watch out for.
Fixing the host name
First, I suppose that local.wolkenkit.io in your case maps to 127.0.0.1, which is the default for wolkenkit. That means that when you try to connect to this domain from within a Docker container, the container does not try to call out to the blog storage container, but it stays within itself. So, the first thing that needs to be fixed is the host name.
Basically, there are two options for this: You can either setup local.wolkenkit.io so that it resolves to the external IP address of your machine. This would work, but is pretty cumbersome. The other option is to directly address the appropriate container that is responsible for blob storage, by its internal name. The internal name is <name-of-your-app>-depot-file. So you need to replace https://local.wolkenkit.io:3001/ by https://<...>-depot-file.wolkenkit.io:3001/.
Fixing the port
Second, the port is wrong. This is because the blob storage service is internally running on port 3000, externally on 3001. So instead of https://<...>-depot-file.wolkenkit.io:3001/ you need to use https://<...>-depot-file.wolkenkit.io:3000/.
Once you have done this you should not get any more errors like ECONNREFUSED, since now the service can be found.
Fixing SSL issues
Third, since you are now connecting to the blob storage service using a different domain name, the SSL certificate doesn't match any more, since it was issued for local.wolkenkit.io. As a result, you will get SSL errors when trying to connect.
The simplest way to get around this is to disable any SSL checks (albeit this is also the most insecure way to handle this!). How to do this depends on the HTTP client module you are using. E.g., in request there is an option called strictSSL that you can set to false.
Of course, what you actually should do is to either use a custom certificate which includes this domain name as well, or to write a function that handles the certificate check and accepts the presented one, especially in this case.
If you do all of this, things should work :-)
PS: I am one of the authors of wolkenkit. Thanks a lot for bringing up this issue, and we will take care of this in the future, to make storing blobs easier.
Related
I'm searching now for hours threw the internet but found nothing what would suit my case.
I have a mailu docker installed on my server and I want to send emails from my meteor application threw this container.
I set my MAIL_URL variable like process.env.MAIL_URL = 'smtps://USERNAME:PASSWORD#DOCKER-IP:465'; and this is working when I use also the global variable NODE_TLS_REJECT_UNAUTHORIZED = 0 but I don't want to use it, because of security reasons.
When I send emails from my meteor app on my laptop and using my email server mail.foo.com instead of the docker-id like smtps://USERNAME:PASSWORD#mail.foo.com:465 then it also works. So from outside I have no problem but when I'm on the server I can't use localhost like smtps://USERNAME:PASSWORD#localhost:465 or smtps://USERNAME:PASSWORD#mail.foo.com:465.
As #natevw said in Node.js Hostname/IP doesn't match certificate's altnames:
It would be better to first diagnose why the certificate is not authorizing and see if that could be fixed instead.
I would say my problem is that the internal docker-ip address is not in the certificate included.
So in my view I would say I have two options:
I could add somehow the ip address to the certificate
I could use somehow the localhost or domain name instead of the internal container id
But I sadly don't know how to achieve one of them.
If you need some configs or something like that please comment and I will edit this post.
Thanks in advance,
Michael
I am working with a Synology NAS type aDS716+II, DSM 6.1.4-15217 Update 2 on wich runs Docker with a Jira container.
So now what I want to do I'm assinged to get to work is to access Jira's webinterface with let's say jira.synology.local with synology being the servername.
I read a lot about nginx and how it's built in since DSM 6.X but I don't seem to get it to work properly at all.
I can access Jira's webinterface from another machine within the LAN via IP_OF_SYNOLGY:PORT so when setting up a reverse proxy on the server it should be pointing to LOCALHOST:PORT right? I have also tried using the actual IP instead of LOCALHOST but without success.
I can access the interface of Synology itself not only via IP_OF_SYNOLGY:PORT but also via DOMAINNAME.LOCAL if I set the domain name.
I really don't know what I'm missing and I tried everything I could think of. Does someone has experience with this?
If some information is missing, I'll gladly provide it. I'm fairly new to synology I have to admit. Thanks in advance!
So this has gotten zero response but I figured probably someone will have a similar "problem" in the future, so I will answer anyway.
I solved everything, when I setup Active Directory. When installing AD, the DNS-Server will automatically be installed too.
So we have JIRA running in a Docker container (on port, let's say, 12345) and I want to access it via the LAN on jira.domainname.
To do so we need to have installed DSM6.X or higher (for nginx) and the DNS-Server. That's it.
In the DNS-Server you will have to create a new master zone
and apply the following settings, whereas you can freely choose the domain name and Master DNS server must be the IP of your synology station, since it functions as a DNS
Then you want to edit the Resource Record
There you want to add an A Record Resource
and an CNAME Record Resource
So your Resource Records will look like this
Now the last step for setting up the DNS server is to tell it what to do if there is no specific record for a query. So for example if you want to open jira.domainname in your browser, there is a specific record for that and the DNS server knows how to direct it. But if you want to open up for example google.com the DNS server has no information on that and does now know what to do. So what we do now is to to tell the DNS server to forward the request, if it has no records for a request. To do so, enable the forwarders and put in the IP of your gateway/ managed switch as primary and some public DNS server (8.8.8.8 for one of google's DNS server) as secondary.
Please remember that jira.domainname shall always be the domainname you choose and 192.168.0.200 shall always be the IP of your synology station.
So now the DNS server is completely setup. Now we want to take advantage of the built-in reverse proxy (which runs on nginx in the background). To do so we navigate as seen here
and create a new reverse proxy rule
So now that the URL's can point to the same destination (your synology, 192.168.0.200) but on different Port. That comes in very handy for some applications running in docker.
So now if you are running this in an home setup or small office, you probably are working with standard issue commercial router such as for example a FritzBox by AVM. Those are pretty good but beware that some prohibit the so called DNS Rebinding which means that DNS requests pointing to a local IP will be not allowed. Since in this setup the DNS server (your synology) and the destination JIRA (also your synology) are in the same LAN, we have to create an exception. Probably other routers don't suppress those requests, but if so exceptions are necessary.
So the next step, it to tell your Gateway or managed switch that it has to use the newly setup DNS server as the primary DNS server. For FritzBox' you can do so here
put in the IP of your DNS server and an secondary DNS server. This is important as a fallback solution if your DNS server probably stops working at some point.
Now that everything is setup I would recommend to restart the router/ managed switch, synology and the workstation you are working on, to flush all caches. After that you can simply open your browser and type in jira.domainname and JIRA should open up. You can also open a terminal/ cmd and type in nslookup jira.domainname to see if it is being resolved correctly.
I really hope this will help someone at some point and if there are any additional questions, please feel free to comment this or write me directly!
We've got a mirrored SQL server 2012 database setup on Azure VM's - two servers plus a witness, all using client certificates, with SQL logins with the same SID set.
When testing our app from a different VM, everything works as expected when we manually failover the database, there's a one second wait and then it continues to operate quite happily.
If we then do another manual failover, ie moving the principal back to the original server, the app errors and throws a 'no such host in known' error. Recycling the app pool fixes the issue, but this clearly isn't workable in production when one of the servers is updated followed by the other at some later point (both are in an availability set).
The host not known error is somewhat baffling as it was communicating with it happily before the initial failover, and will again after the app pool recycle.
Here's the connection string as it is right now, after a lot of faffing around:
"Data Source=server1,1433;Failover Partner=server2,1433;Initial
Catalog=;MultipleActiveResultSets=True;User Id=user;
Password=password; Network=dbmssocn;Connect Timeout=60; async = true;"
providerName="System.Data.SqlClient"
The app is running on .net 4.5.2, so should be up to date with hotfixes, and we're out of ideas after much Googling with Bing.
I've just solved a problem that I had that looks very similar to your problem. I'd get the host not known error whenever the database switched from the first one listed in the web.config file to the failover one. It was fine switching from the failover to the primary.
The problem that I had was that I set up the database mirroring using server names but my web server did not know the database servers by name. Once I fixed this, I was able to get the failover working smoothly both ways.
This is what I think was happening:
I set up the mirroring using the names SQL1 and SQL2 as the principal and mirror servers
I have their ip addresses in my connection string: 10.1.1.5 and 10.1.1.6
The application tries to get to the first server 10.1.1.5 and succeeds and is then told that the mirror server is SQL2
SQL1 goes down and the database is successfully switched to the mirror server.
The web application attempts to connect, fails and determines that it should try the second server.
It tries to connect to SQL2, which it doesn't know, and fails with the message that the host is unknown.
This answer would only apply to your situation if you actually put ip addresses in your web.config and that server1,1433 and server2,1433 were actually masking place-holders for the ip addresses that you actually used.
I haven't really solved the naming issue though. I just added the two database server names to the HOSTS file which isn't an acceptable situation but does prove my theory on what my problem was.
I am researching a setup just like you have and upon reading this and the response by Steve Kaye, I'm wondering if you have SQL browser running. Take a look at this article for how SQL browser comes into play:
http://blogs.msdn.com/b/spike/archive/2010/12/15/running-a-database-mirror-setup-with-the-sqlbrowser-service-off-may-produce-unexpected-results.aspx
I have a program in which checks a php file on a web server to see if the user is verified. The php files runs through the DB and checks and echos "verified" if they are.
Now, people are now easily bypassing the verification system by installing Xampp, routing my server to 127.0.0.1 in their hosts file, and then setting a script that echos verified.
I want to be able to check the IP address of my domain to check if it is routing to 127.0.0.1.
How would I go about resolving the IP address of a domain through delphi?
I used to use a similar hack to get around ICQ server-side verifications. Very convenient when I wanted to test alpha/beta builds that I was not invited to :-)
Indy, which ships with Delphi, has a TIdStack.ResolveHost() function, and a separate TIdDNSResolver component, which can both be used to get the domain's IP(s). It also has a TIdStack.LocalAddresses property to retreive the local IPv4 addresses. Or you can just use the socket API gethostbyname() or getaddrinfo() functions directly, along with platform-specific APIs to enumerate the local IPs, like the GetAdaptersAddresses() function on Windows.
However, rather than having the PHP script simply echo plain-text back to your app, a much more secure option that does not require you to verify IPs is to have your app create a dynamically generated nonce value and send it to the PHP script, then have the script process it, hash it, whatever as needed using an algorithm that only you know, and then send it back to the app. The app can perform the same algorithm and compare the results. Unless someone takes the time to reverse engineer your app, they will not be able to reproduce your algorithm or fake its results with their custom Xampp scripts.
Even better, use SSL/TLS to encrypt your connection to your domain server, and give your domain server an SSL certificate that your app can verify before it exchanges any data with your PHP script. If you do just this much, you can continue using the plain-text echo since SSL/TLS will verify you are connected to your domain for you.
I have a very basic doubt regarding web application url.
Suppose a web application is running locally on my machine.
Will there be any difference in the response time if I access the application using below two url ?
http://localhost:8080/SomeApplicationContext
http://hello:8080/SomeApplicationContext -- Assuming my machine name is hello
depends on whether or not you have hello in your hosts file. (same place where localhost is defined) if its not, then yes because your computer will have to check with DNS before it can access the resource, in which case the difference will close to the round trip latency of that request.
No difference, You can run the script/coding using http://localhost:8080/SomeApplicationContext from your own machine only, if you like to run this program from other pc/system you can use the http://hello:8080/SomeApplicationContext url ( you can run this url from your own machine also).
I hope this is perfect.
no. Why would that be? Response time depends on servers ability to serve the content -- that is latency in processing teh request and the other is network latency. In your case both are the same. So, no difference.
localhost or hello, both of them must be defined in your hosts file. Your OS looks to hosts file (such as /etc/hosts in many Linuxes or %windir%/system32/drivers/etc in some Windowses) if it cannot find it in there, OS asks a DNS server for server ip.
In your situation, both must be defined in your hosts file. No change in network latency.
But if you mean different domains pointing same IP, then it depends on how your server application (apache, nginx, IIS etc.) handles different domain names.