Not really. I always adhere to KIS rule, the simpler - the better, and this especially applies to the criteria of a general fresh install vanilla config.
Adding a new element to complicate the equation, whose management is btw far away from being simple, in order to manage a conflict of two elements which can be easily settled by reconfiguring the local port of the non-standard one of them, just adds clutter without hitting the target.
Btw, why is the IP:port security constraint wished for general webserver not also applied for pywwetha? Instead of getting across other services, it shoud just listen on requests *specifically* made on 127.0.0.86, thing which at the moment does not happen, thus generating this mess. Clearly, it's this python server poor on config side, but introducing iptables to fix its poor design would be too much.
The real solution to this problem, as already filed by musca
http://bugs.siduction.org/issues/1800 (funny that we came to the same conclusion independently in the same days!), is changing pywwetha default port and making sidu-manual point to it, or, at least, obliging pywwetha to somehow (no iptables) listen just on 127.0.0.86 without interferring with other IPs. This would be benefitting universally all users.
Should this not happen, alternatives would be:
- editing nginx.conf every time addresses change on interfaces
- apt-get purge sidu-manual pywwetha
Guess which one I would choose.