Hi Terry, > 1. If the nodogsplash webserver is serving the WMT content pages; how > does it manage that? > > The Splash Page is located at /etc/nodogsplash/htdocs, which is the > default location. The WMT content is at /var/www/html, which is the > default location for nginx. The nodogsplash config file points the > webserver at the Splash Page for the initial signin and the redirects > to WMT-Guest.com. > > The nginx config file includes 'sites-enabled' and a file called > WMT-Guest is located in 'sites-available' This is then linked to > 'sites-enabled'. The Pi is set up to be a DNS Server, which simply > says that the page WMT-Guest.com may be found at the IP Address of the > Pi (192.168.0.1). All this has worked well since the Webserver was > installed in March 2017. The only problem has been the Android issue. > > 2. A repeat of question 1. really; when the browser surfs to 192.168.0.1 how > does it know to get the content from nginx and not the nodogsplash web server? > > My understanding is that you can run two webservers at the same IP Address > providing that they use different ports. nodogsplash is using the default > port 2050 and nginx is using port 80. So that ought to work, but I'm still > not sure how the content gets to the browser if the nodogsplash webserver is > serving it since it won't be reading the nginx config file.
Have you read https://nodogsplash.readthedocs.io/en/latest/howitworks.html ? You're right, only one program may listen on a particular TCP socket at a time for incoming connections to accept, and nginx is listening on the port 80, HTTP, with nodogsplash listening on port 2050. The visitor's browser tries to connect to port 80, not knowing nodog exists. `sudo -i lsof -ni' will show what programs are currently listening. It's a variation of «netstat -tl»'s output. An incoming packet passes through the kernel before being arriving at the program listen on the destination port for that packet. Part of the kernel is the packet filter, which can be inspected and manipulated with iptables(8). nodog modifies the filter's configuration as described on its `how it works' page. Packets arriving for port 80 are sometimes passed to port 2050 instead, thus nodog get first dibs. Once it's happy, it arranges for the redirection of future packets to cease and so the approved visitor talks directly to nginx from then on. nginx is unaware of nodog's pilfering. nodog has no part in nginx's serving of the pucker web site. As I said a long time ago, you can let nodog set things up and should then me able to peer at what it's done with `sudo -i iptables -vL'. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2018-07-17 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:[email protected] / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
