dmacias

You'll need to install a bunch of dev packages like make, guile, gc... I can give you a list of packages I use in a vm of unRAID to compile packages. Sent from my SM-N930P using Tapatalk

Added Sent from my SM-N930P using Tapatalk

I would remove the plugin, delete the ipmi plugin directory on your flash drive then reinstall. If that doesn't fix it then hit Ctrl+Shift+i to bring up Inspect in Firefox or Chrome and go to console. Then hit Ctrl+F5 to clear cache and refresh page. Report any errors in console. Try changing settings and click apply. Report any errors. Maybe try setting up network connection instead of local.

Thanks. Forgot to remove that when I removed speedtest-linux. Sent from my SM-N930P using Tapatalk

I have a few changes I made too. So I'll update in a few when I get home.

Sorry I forgot to update the plugin with the correct python.

You'll need to remove the /boot/config/plugins/dynamix.plg and reboot.

I'm not sure what it is. All my plugins were compliant with the 6.3 csrf hardening even before it was released. I tried several browsers and my phone's browsers with my main server on 6.3.3. Also I booted up a 6.3.3 vm and changed the emhttp to 8088. Installed the plugin and applied settings from all browsers. No errors. Maybe you could give more from the syslog or diagnostics. Also check that you don't have a dynamix.plg in /boot/config/plugins. Try to uninstall and reinstall the plugin.

Should be fixed now.

How to fix this? I updated the python package. The one I included was from slackware current and required ncurses 6.

Yes initially I made assumptions about fan names but have since made a script that is tied to the Configure button that automatically matches the actual fan names. However this only works for the single socket boards till I find time to implement a fix for the dual sockets. There are some discussions not far back about your board and another thread on here too. I see I can find it. Edit here it is https://forums.lime-technology.com/index.php?/topic/46077-ASRock-server-board-(EP2C602-versions-and-any-other-with-IPMI)-and-CPU-Temp

This is the command I use to scan. I take the server ip and exclude it then drop the last number and add 0/24 to the ip to scan the subnet. /usr/bin/nmap -sn -oX /var/log/wakeonlan/scan.xml --exclude 192.168.1.1 192.168.1.0/24 To get it to scan in the plugin right now I think all you would have to do is add this IPADDR[0]="xxx.xxx.xxx.xxx" with your server's ip address to /boot/config/network.cfg. Shouldn't matter if you used automatic dhcp. The plugin is looking for that as it's currently written. While I don't exclude ip addresses from the scan itself (except the server's ip), I do remove saved mac addresses when I build the scan page table. Also once you click to add a mac from the scan list, it is removed and then added to the saved table.

I can get the ip from the unRAID variables instead of network.cfg. I'll have to do some testing. I have dual nics also but second one is br1 just for vm's. Curious if eth1 shows anything under your Vars? If all else fails I can make a settings page and populate it with my best guess and allow it to be changed if the wrong ip or interface is selected. The ip is also critical to nmap and setting the subnet to scan Also I cache the scan at /var/log/wakeonlan/scan.xml. The clear button just empties the file.

Yes that's the problem. I use the ip address to create an exception for nmap and an awk script to get unRAID's interface e.g. eth0. I too have an dhcp reservation but I do have an ip address in the network.cfg. But that may have been set by me, using a static address. I'll have to get the ip a different way. Can you check under the Tools menu and go to Vars. Then search for ipaddr or your ip address?

What variable is your server ip address under in /boot/config/network.cfg?

Which page in particular is giving you that error? Edit. My guess would be a stale browser. I would try closing your browser and opening the webgui again.

There's no permissions on the flash drive since it's fat32 but it might have been corrupted somehow. Are you able to scan now?

Sorry for the late reply. Didn't get the notification. Everything is working fine for me. Just tried on my phone browser too. What version unRAID? Did you try different browsers? What's your unRAID network configuration?

I added both.

The original setup for letsencrypt/fail2ban only monitors the access.log and error.log of the front end nginx of the LE docker. Unless you have something like this in your nextcloud location block which would require users to login first before actually getting to the nextcloud login. auth_basic "Restricted"; auth_basic_user_file /config/nginx/.htpasswd; If not then all nextcloud traffic is proxypass to backend nginx of nextcloud docker. Any failed logins are only seen in nextcloud and nextcloud nginx access/error logs. Fail2ban never sees this unless you add the location of the NC logs to the LE docker and setup a fail2ban filter to monitor those logs. Here's my setup. So for the LE docker I added Container Path: /logs/emby with Host Path: /mnt/user/appdata/emby/logs/ and Container Path: /logs/nc_nginx with Host Path: /mnt/user/appdata/nextcloud/log/nginx/ Container Path: /logs/nextcloud with Host Path: /mnt/user/nextcloud/ My ../appdata/letsencrypt/fail2ban/jail.local looks like this. # This is the custom version of the jail.conf for fail2ban # Feel free to modify this and add additional filters # Then you can drop the new filter conf files into the fail2ban-filters # folder and restart the container [DEFAULT] # "bantime" is the number of seconds that a host is banned. bantime = 600 # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 600 # "maxretry" is the number of failures before a host get banned. maxretry = 5 [ssh] enabled = false [nginx-http-auth] enabled = true filter = nginx-http-auth port = http,https logpath = /config/log/nginx/error.log [nginx-badbots] enabled = true port = http,https filter = nginx-badbots logpath = /config/log/nginx/access.log maxretry = 2 [nginx-botsearch] enabled = true port = http,https filter = nginx-botsearch logpath = /config/log/nginx/access.log [emby] enabled = true port = http,https filter = emby logpath = /logs/emby/server-*.txt [nc-nginx-http-auth] enabled = true filter = nginx-http-auth port = http,https logpath = /logs/nc_nginx/error.log [nc-nginx-badbots] enabled = true port = http,https filter = nginx-badbots logpath = /logs/nc_nginx/access.log maxretry = 2 [nc-nginx-botsearch] enabled = true port = http,https filter = nginx-botsearch logpath = /logs/nc_nginx/access.log [nextcloud] enabled = true port = http,https filter = nextcloud logpath = /logs/nextcloud/nextcloud.log I added ../fail2ban/filter.d/emby.conf # Fail2Ban filter for emby # [INCLUDES] # Read common prefixes. If any customizations available -- read them from # common.local before = common.conf [Definition] _daemon = emby-server failregex = Info HttpServer: HTTP Response 401 to <HOST>.*authenticatebyname Info HttpServer: HTTP Response 500 to <HOST>.*mediabrowser/Users/None ignoreregex = # DEV Notes: # # Matching on http 401 with a trailing url including 'authenticatebyname' to catch incorrect passwords # Matching on http 500 with a trailing url including 'mediabrowser/Users/None' to catch incorrect usernames # # Author: [email protected] I also added ../fail2ban/filter.d/nextcloud from here https://github.com/hailthemelody/nextcloud-fail2ban # Fail2Ban filter for Nextcloud [INCLUDES] before = common.conf [Definition] failregex = Login failed.*Remote IP.*'<HOST>' ignoreregex =

Sorry I'm not sure what you mean.

/config/nginx/proxy.conf in letsencrypt already passes the ip of the remote address. proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; In order to get fail2ban to work with anything other than local auth_basic access, you have to add the path of the logs to the letsencrypt container like Marv did for Emby. (Container path: /emby_logs Host path: /mnt/user/appdata/emby/logs) The problem with nextcloud was that all it sees is the ip of the unRAID docker0 bridge interface. So if there was malicious usage everyone would be banned. So adding this to Nextcloud nginx gets the forwarded ip from the headers instead of the docker0 ip. real_ip_header X-Forwarded-For; set_real_ip_from 172.17.0.0/16; real_ip_recursive on; So now you have the real ip in your nextcloud and nextcloud nginx logs and fail2ban can use that.

You shouldn't change it. The 172.17.0.0/16 covers the docker0 bridge interface. That is the ip range that a nginx docker sees behind a nginx reverse proxy docker. Maybe this should be part of the nextcloud nginx default site. If you include the /config/nginx/proxy.conf in your location block in letsencrypt it forwards the headers.

This works for me. Add the real ip lines to the nginx default site-confs for the nextcloud docker. Then restart the nextcloud docker. server { listen 443 ssl; server_name _; real_ip_header X-Forwarded-For; set_real_ip_from 172.17.0.0/16; real_ip_recursive on;

You should be good to go. You'll need Perl also. Let me know if it works for you.