Yes that is what I was concerned with. That this may cause me more grief then needed... as the saying: “if it works, don't touch it”.
For the change of configuration on the ESXi side of things. Yes indeed I can configure the vm as requested to: Other 3.x Linux (64-bit) and that might be a better approach to the issue? I tried and I do not think this configuration will have any ill effect with ESXi since the status of the vm went from warning to normal. For both configuration the vm-tools service is acknowledge as running by ESXi. The only thing that I do not know is if ESXi does any specific type of optimization for a CentOS configuration that might have been beneficiary?
I wish to change the symbolic link:: /etc/centos-release in ClearOS for the following information: CentOS Linux release 7.8.1 (Core)
I am receiving the following log message from ESXi on my setup with the ClearOS current configuration of /etc/centos-release: ClearOS release 7.8.1 (Final)
The configured guest OS (CentOS 4/5/6 (64-bit)) for this virtual machine does not match the guest that is currently running (Other 3.x Linux (64-bit)). You should specify the correct guest OS to allow for guest-specific optimizations.
It appears that this change seems to be relevant for optimizing the performance of ClearOS within an ESXi environment (both being Community Versions). Note that all my ClearOS vm's within my ESXi configuration are all set to CentOS... (which I believe to be the most accurate for ESXi ClearOS combination). I am assuming that vm-tools is providing CLearOS vm the Guest OS version that are set in /etc/centos-release. Having changed the information to the above seems satisfy my ESXI server. Now what I am wondering is if I have created myself future update release issues with CLearOS?
For your information it appears that VMware is only looking at the first digit for the version:
Nick I think you are correct miniUPnP even if it is part of the UPnP Protocol Stack is more involved at the end of the Stack, if port forwarding is required by the device/appliance i.e. TV, receiver, etc...The second issue that I was having has more to do with the Simple Service Discovery Protocol even if SSDP was incorporated in the UPnP Protocol Stack not really related to miniUPnp tasks. In retrospect I confused the two different actions and I should probably have created a second forum entry for my second question.
But all is good with your help I was able to confine miniUPnP port forwarding to the interface of my choice, which is what I wanted. The second issue was to limit the access to my Standalone Server to port 8060 acting as an Emulated Roku device. I think I got that resolved by adding the following two custom rules.
I wish to apologize for the confusion with the interfaces. The interface: ens224 belongs to the Gateway Server HotLan, where the above interface: ens192 belongs to the Standalone server running the emulated Roku device. The first rule is to open the discovery process to the Harmony Hub, this is a standard SSDP process required for the discovery of devices. The second rule is for allowing the Harmony Hub access to the Emulated Roku Device.
For the audience that is wondering how can ClearOS become a Roku device? Well in this particular case it does for my Harmony Hub. The Harmony Remote activities sees the server as a Roku device and triggers Home Assistant events such as controlling lights, motorized curtains, etc... running on the same Standalone ClearOS server.
Thank you again to Nick for all the help.
Nick Howitt wrote:
As far as I am aware, uPnP does not feature in this. I think MiniuPnP's role is to just map external port forwards automatically. I don't know how device discovery works for other devices.
Interesting, I thought it also allowed the devices on your home network to discover each other and access certain services. Thanks for your help in all of this, if I find additional information I will chime in.
Nick Howitt wrote:
Good catch with the loop.
I am lost with the other. Where are the Roku emulator and Harmony Hub (IP's and interfaces)? Have you thought of some packet sniffing with tcpdump?
I agree a little confusing let me try again. For the interface that one is easy, it is all happening on the same my HotLAN: ens224.
The Roku Emulator is the ClearOS Server it run on IP: 192.168.4.26 port 8060 can be accessed with or without the firewall enable via the browser:
The Harmony Hub sits on IP: 192.168.4.205
The Harmony Hub can be asked to discover all appliances and with the help of UPNP it seems to find all the appliances T:V, Receiver etc including the above Emulated Roku 4 on Server 192.168.4.26 when the firewall is disabled. If the firewall is enable all the appliances are found except for the Emulated Roku.
Never used tcpdump, if I can not find the above issue might be a good solution, thanks for the suggestion
I know why it worked and I feel kind of dumb. The LAN loop has no effect on the CUSTOM loop, not exactly my best coding...
In regards to the firewall I used the ClearOS Incoming Firewall configuration before tightening even more the rule set by using a custom rule:
But that does not seem to help my Harmony Hub find the emulated Roku appliance. I will have to do more testing once I am at home
Nick Howitt wrote:
I am not sure why you are iterating over $LANIF. I think this will exclude any $CUSTOM_LAN which is in $HOTIF. Do you just want:Good point, I had the same thought when I was coding this. But it seems that the LAN iteration is including the HotLAN?
I am including my log, ens224 is configures as my HotLAN
I have a standalone server running Home Assistant with a feature that allows me to https://www.home-assistant.io/integrations/emulated_roku/" target="_blank"> emulates a Roku appliance for my Harmony Hub to discover and include in its activities for running customized scripts.
My UPNP discovery needs seem to be covered (Thanks to Nick and MiniUPNP) when I run my server without a firewall. Since this server is running in the HotLan. I would prefer to enable the firewall but I have had some difficulties figuring out what ports below are needed to allow the Harmony Hub to reach the emulated Roku device
I tried to allow in UDP port 1900 but was not successful at penetrating the firewall. Any suggestions to what ports are needed for the discovery to work.and reduce the security vulnerabilities.
I added a few modification to the miniupnp service to fit my customization needs (/etc/miniupnpd/init_clearos.sh)
The customization requires that you add the parameter CUSTOM_LAN to /etc/miniupnpd/miniupnpd_clearos.conf