Services listening by default, but not explicitly enabled in the web interface

socketbox · 14. April 2024

New to OMV with a relatively new install of OMV7. Trying to establish a baseline for network transfer speeds using iperf3 and I'm not sure of the port that's been configured in the OMV iperf3 plugin. So I run ss -l -n -4 -p to see what's actually listening, thinking that, by enabling the iperf3 plugin via the web interface, it should now be listening on a port as part of the iperf3 client/server duo. It's not, but that's another issue for a different post.

ss -l -n -4 -p gives the following output:

Bash

udp   UNCONN 0      0                    0.0.0.0:5353         0.0.0.0:*     users:(("avahi-daemon",pid=859,fd=12))                                            
udp   UNCONN 0      0                    0.0.0.0:5355         0.0.0.0:*     users:(("systemd-resolve",pid=593,fd=11))                                         
udp   UNCONN 0      0                    0.0.0.0:39461        0.0.0.0:*     users:(("python3",pid=996,fd=8))                                                  
udp   UNCONN 0      0                 127.0.0.54:53           0.0.0.0:*     users:(("systemd-resolve",pid=593,fd=19))                                         
udp   UNCONN 0      0              127.0.0.53%lo:53           0.0.0.0:*     users:(("systemd-resolve",pid=593,fd=17))                                         
udp   UNCONN 0      0       192.168.1.212%enp2s0:68           0.0.0.0:*     users:(("systemd-network",pid=352,fd=18))                                         
udp   UNCONN 0      0                    0.0.0.0:111          0.0.0.0:*     users:(("rpcbind",pid=592,fd=5),("systemd",pid=1,fd=75))                          
udp   UNCONN 0      0                  127.0.0.1:323          0.0.0.0:*     users:(("chronyd",pid=982,fd=5))                                                  
udp   UNCONN 0      0                    0.0.0.0:58011        0.0.0.0:*     users:(("avahi-daemon",pid=859,fd=14))                                            
udp   UNCONN 0      0              192.168.1.212:3702         0.0.0.0:*     users:(("python3",pid=996,fd=9))                                                  
udp   UNCONN 0      0            239.255.255.250:3702         0.0.0.0:*     users:(("python3",pid=996,fd=7))                                                  
tcp   LISTEN 0      50                   0.0.0.0:139          0.0.0.0:*     users:(("smbd",pid=1041,fd=31))                                                   
tcp   LISTEN 0      128                  0.0.0.0:22           0.0.0.0:*     users:(("sshd",pid=977,fd=3))                                                     
tcp   LISTEN 0      511                  0.0.0.0:80           0.0.0.0:*     users:(("nginx",pid=11940,fd=7),("nginx",pid=11939,fd=7),("nginx",pid=11938,fd=7))
tcp   LISTEN 0      4096                 0.0.0.0:111          0.0.0.0:*     users:(("rpcbind",pid=592,fd=4),("systemd",pid=1,fd=74))                          
tcp   LISTEN 0      511                  0.0.0.0:443          0.0.0.0:*     users:(("nginx",pid=11940,fd=8),("nginx",pid=11939,fd=8),("nginx",pid=11938,fd=8))
tcp   LISTEN 0      50                   0.0.0.0:445          0.0.0.0:*     users:(("smbd",pid=1041,fd=30))                                                   
tcp   LISTEN 0      4096              127.0.0.54:53           0.0.0.0:*     users:(("systemd-resolve",pid=593,fd=20))                                         
tcp   LISTEN 0      5                    0.0.0.0:873          0.0.0.0:*     users:(("rsync",pid=968,fd=4))                                                    
tcp   LISTEN 0      4096                 0.0.0.0:5355         0.0.0.0:*     users:(("systemd-resolve",pid=593,fd=12))                                         
tcp   LISTEN 0      4096           127.0.0.53%lo:53           0.0.0.0:*     users:(("systemd-resolve",pid=593,fd=18))                                         
tcp   LISTEN 0      5              192.168.1.212:5357         0.0.0.0:*     users:(("python3",pid=996,fd=10))

Alles anzeigen

Aside from rsync, chronyd, systemd-resolve, I don't understand why services (specifcally smbd and wsdd) are running. I don't use SMB and I certainly haven't enabled it in the web interface.

Also, why is rpcbind listening on all interfaces and not just the loopback? I think salt is being used for manipulating the system via the web UI... is this related?

ryecoaaron · 14. April 2024

iperf3 uses port 5201 by default. Since the plugin is not specifying a port, it will use the default. https://github.com/OpenMediaVa…gined/rpc/iperf3.inc#L137

Zitat von socketbox

I don't understand why services (specifcally smbd and wsdd) are running. I don't use SMB and I certainly haven't enabled it in the web interface.

Have you rebooted? Services are enabled by default when installing the package. But with no config, it isn't sharing anything. You could enable samba and disable it to run the saltstack code or run sudo omv-salt deploy run samba if you are worried about it.

Zitat von socketbox

why is rpcbind listening on all interfaces and not just the loopback?

OMV is not configuring anything with rpcbind's config file. This is the default config from debian. But if rpcbind is only listening on loopback, how would remote clients use nfs?

socketbox · 14. April 2024

Thanks for your response. I realize that decisions regarding default behavior and the initial user experience are a matter of opinion. That said, from my perspective, if this checkbox in the web interface...

...isn't enabled, then the SMB daemon should not be running. Ditto for the "web service discovery daemon" that appears to be SMB-related. I don't think that's an irrational expectation.

Regarding rpcbind: I see (now that I'm receiving errors in the browser) that the PHP application is expecting RPC calls from the front-end.

ryecoaaron · 14. April 2024

Zitat von socketbox

I realize that decisions regarding default behavior and the initial user experience are a matter of opinion. That said, from my perspective, if this checkbox in the web interface...
...isn't enabled, then the SMB daemon should not be running. Ditto for the "web service discovery daemon" that appears to be SMB-related. I don't think that's an irrational expectation.

And that is the goal with OMV. I didn't say it was an irrational expectation. There are just certain situations where a service is enabled by the debian package after OMV's saltstack code to configure it has run. saltstack isn't continuously running and maintaining the config. So, it is possible they can get out of sync. Did you install OMV from the iso? And yes, wsdd is enabled/disabled with samba.

socketbox · 14. April 2024

Yes, I installed via ISO, after having written it to a thumbdrive.

I'll bring the image (7.0.5-1) up in a VM and see what happens.

Services listening by default, but not explicitly enabled in the web interface

ryecoaaron 14. April 2024

Jetzt mitmachen!

Tags