127.0.0.1 www.whatever.com
111.1.1.1 www.whatever.com
127.0.0.1 www.whatever.com
The 111.1.1.1 in the second line can be any non-127.0.0.1-address.
Under Windows XP, Firefox/Chrome.
Why is it that this configuration will crash a browser?
Without reference to any specific operating system or browser environment, it seems reasonable to assume that it's not valid to have multiple entries for the same IP spanning multiple lines in your particular environment.
Related
I have to access simultaneously multiple NAS DSM on a remote Network with Firefox. They are reachable over the Routers-IP and a dedicated port each, like: https:\xxx.xxx.xxx.xxx:5000 and https:\xxx.xxx.xxx.xxx:5100 and https:\xxx.xxx.xxx.xxx:5200. The problem is that Firefox loses the connection to the first NAS as soon as I connect to the next NAS. Multiple simultaneous connections are only possible with multiple browsers, why? How can I manage to connect to all NAS simultaneously, only with one browser?
I found a workaround.
You can start several separate FireFox profiles in such a way that no instance notices something of the other.
To do this, you have to call FireFox with "-p" and create as many profiles as you need:
Standard-User001
Standard-User002
...
And store them in separate folders:
D:\FirefoxProfile\Standard-User001\
D:\FirefoxProfile\Standard-User002\
...
Then you can create links on your desktop:
"C:\Program Files\Mozilla Firefox\Firefox.exe" -p "Standard-User001" -no-remote
"C:\Program Files\Mozilla Firefox\Firefox.exe" -p "Standard-User002" -no-remote
...
Now you have several completely separate FireFox installations.
with Synology NAS, when you login to DSM, the generated PHPSESSID cookie is the same if the domain name is the same, no matter if the specified port in the URL is different. So there is, as far as i know, no way to circumvent this mecanism (needless to say that it is actually a good thing for security in most case).
So the most simple solution i found is to setup CNAMEs on a dynDNS entry, assuming you fullfil the following requirements:
have your own domain name.
each DSM is configured to use a different port.
port forwarding on your router is setup (optional).
Now let's say you have two servers: nas1 reachable on port 5001, nas2 on port 5002 and a dynDNS, for instance nas-is-like.synology.me ( in DSM, check the "DDNS" tab in "External access" settings from the configuration panel if you need to setup this first ).
Then simply add wanted aliases in your DNS zone:
NAME TYPE TARGET
--------------------------------------------------
nas1.youdomain.tk CNAME nas-is-like.synology.me.
nas2.youdomain.tk CNAME nas-is-like.synology.me.
Then you will be able to login on both DSM interfaces ( nas1.youdomain.tk:5001 and nas2.youdomain.tk:5002 ) in the same brower and the same profile.
I have just started using Parallels for Mac, and am attempting to debug a locally running web application on my host MacOS machine.
I have figured out that I can connect to the my host via 10.211.55.2 in the browser in my virtual windows machine.
What I'd like to do is to instead connect via localhost and have this routed through to the 10.211.55.2 ip instead.
I tried editing my windows hosts file with an 10.211.55.2 localhost entry but this made no difference.
Is this possible to do?
localhost is hardcoded in many libraries. In theory it should be possible, but it would break a lot of things, including not being able to boot up the system. Connections to localhost are used frequently for interprocess communication throughout the system, so there's more to it then you using it for testing websites. Just go with another name.
I've followed several articles about how to configure virtual hosts on Mac using MAMP (such as this post) which involve editing three files:
/etc/hosts
Applications/MAMP/conf/apache/httpd.conf
Applications/MAMP/conf/apache/extra/httpd-vhosts.conf
That all works fine for one host at a time, but if I configure a second local site (such as mysite.loc), the second site doesn't work: it redirects to which ever one I've pointed the directory to in MAMP free. I know that in XAMPP it would be fine to have several different virtual hosts, but shouldn't this also work with MAMP free? If so, how?
you can try to change the port number for all the virtual hosts in the httpd-vhosts.conf file to the one your apache server is currently using. so those virtual hosts can start utilizing the directories you specified, instead of using the default one that can only be changed in the app.
I've installed Postgresql 9.4 on a windows server 2008. I am writing an application that will access this server from our Windows 7 machines. I also installed PGAdminIII on one workstation where I am developing.
I am not able to connect from the workstations. I get a "Server doesn't listen" message. I've looked online for some solutions but none seemed to help me.
On the Server where the service is running. I've tried and change the values through paAdminIII for the files pg_hba.conf and
It looks like pg_hba.conf was setup to listen to the loopback and then a range of ip addresses on the same computer. When I change the "host" key value of the ip_address range from 127.0.0.1/32 to 192.168.2.1/128 (and keep the other values the same -> all, all, md5) the service starts and then stop immediately.
If I leave it with 127.0.0.1/32 then it starts fine but I can not connect from the workstation.
I left the listen_addresses on the postgresql.conf file as the default "*" which is trying to listen to all addresses.
I am trying to develop a client/server app before moving it to the cloud and this is step 0.
I did install on my Windows 7 machine an "add_on" the VisualStudio to help me get a connect string down the line but I am only using the PostgreSql "tools" at this time.
I did some search to see if this question was asked before in this client/server scenario and did not find one. If it has already been answered I'd appreciate some pointers directing me to the correct way to configure server access, if not, then an answer on how to do it would be great.
I can ping the server with no problems from the workstation(s).
The IP address/CIDR mask specification of 192.168.2.1/128 is wrong. The last value indicates the number of bits to be masked, not an IP address range. If you want (most of) the range 192.168.2.1 - 192.168.2.128, the entry in pg_hba.conf should be 192.168.2.0/25 (meaning: take the three highest bytes 192.128.2 (24 bits), plus the highest order bit 0 of the last byte and let the 7 remaining bits vary (values 0 to 127).
Note that this includes 192.168.2.0 and excludes 192.168.2.128, but that is just how bit masking of IP addresses works. You could add 192.168.2.128 with a separate entry in pg_hba.conf, but you cannot get 192.168.2.0 out.
Here's what I've done:
I wrote a minimal web server (using Qt, but I don't think it's relevant here).
I'm running it on a legal Windows 7 32-bit.
The problem:
If I make a request with Firefox, IE, Chrome or Safari it takes takes about one second before my server sees that there is a new connection to be accepted.
Clues:
Using other clients (wget, own test client that just opens a socket) than Firefox, IE, Chrome, Safari seeing the new connection is matter of milliseconds.
I installed Apache and tried the clients mentioned above. Serving the request takes ~50ms as expected.
The problem isn't reproducible when running Windows XP (or compiling and running the same code under Linux)
The problem seems to present itself only when connecting to localhost. A friend connected over the Internet and serving the connection was a matter of milliseconds.
Running the server in different ports has no effect on the 1 second latency
Here's what I've tried without luck:
Stopped the Windows Defender service
Stopped the Windows Firewall service
Any ideas? Is this some clever 'security feature' in Windows 7? Why isn't Apache affected? Why are only the browsers affected?
If you're saying "localhost" instead of "127.0.0.1", you're forcing a name lookup before the actual connection attempt, adding delay.
In addition, some browsers, like Firefox 3.5+, don't use the operating system's DNS lookup mechanism, which is why it can have different performance than, say, wget.
You may be running into some automatic proxy discovery problem. In Firefox, you can disable this in Options | Advanced | Network | Settings; select either "No proxy" or give it explicit values. There's also the Internet Properties control panel, which is IE's network settings, but other browsers on Windows may obey settings here, too. Again, disable auto-proxy discovery. This can speed connections outside localhost, too.
For some reason Windows 7 takes 1 second to resolve address localhost regardless of it being in hosts file.
Adding localhost1 to hosts file and using that works around the problem.
When connecting to localhost on a IPv4/IPv6 dual stack host:
A DNS lookup is performed for localhost.
The DNS server (whether IPv6 enabled or not - this doesn't matter) returns both the AAAA record ::1, and the A record 127.0.0.1.
The client first attempts to connect to ::1.
We assume your server program is not IPv6-capable, which is a common case - due to historical reasons, many servers bind their socket to 0.0.0.0 by default rather than [::].
Here an ECONNREFUSED error would be raised for the client. This happens immediately on most platforms; on Windows however, a single call to connect() would try 3 times in 500ms intervals before giving up, hence taking a bit more than one second (See http://stackoverflow.com/q/19440364 for more details).
The client then creates a connection to 127.0.0.1 instead.
This would explain all your clues above:
If you make a request with Firefox, IE, Chrome, Safari or any other IPv6-capable clients, it takes takes about one second trying for ::1 before connecting to 127.0.0.1.
Your own test client just opens a INET socket, so it won't try ::1 at all.
Using a dual-stack server such as Apache, the clients will connect to ::1 happily.
The problem isn't reproducible on Windows XP, of which IPv6 support is not enabled by default.
The problem seems to present itself only when connecting to localhost, as your friend connected with an IPv4-only network.
Running the server in different ports has no effect on the 1 second latency.