fluisterben

I just installed rsync using some nerd-pack. Way easier.. Entire docker engines plus its dependencies for just rsync is way overkill. Plus you have to work around the fact that the actual server is not the actual server, but behind a bridge/vnode with translated ports etc.

How are you starting/persistently running autossh in unraid? I have it running in debian as a service under systemd, but no idea how this is done for unraid's slackware version.. [Unit] Description=AutoSSH tunnel After=network.target network-online.target sshd.service [Service] Environment="AUTOSSH_GATETIME=0" RestartSec=40 Restart=always ExecStart=/usr/bin/autossh -M 0 -o ExitOnForwardFailure=yes -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -p 65022 -N -R 65422:127.0.0.1:65422 root@remote-server-ip TimeoutStopSec=20 [Install] WantedBy=multi-user.target

Well, could have fooled me, because it says;

I don't get it, you ignore bash history, and then want to have nice history?

This is still not working. I have just updated to 6.10.3 and the ssl is not loaded in nginx. Here's what I run after booting; #!/bin/bash cp -af /mnt/user/nxt/live/somename.org/fullchain.pem /boot/config/ssl/certs/somename_unraid_bundle.pem cat /mnt/user/nxt/live/somename.org/privkey.pem >> /boot/config/ssl/certs/somename_unraid_bundle.pem /etc/rc.d/rc.nginx reload /etc/rc.d/rc.php-fpm reload This runs without errors, it starts nginx, but after this (and after rebooting the entire server as well), it still does not load the new cert. Honestly, this entire concept is broken in your config, as far as I would say. People create their own certs now, and there's no way I can properly work that into unraid's OS setup. Please allow us to have it use a custom location for the cert(s), and NOT recreate one every time we update the OS. Simply allow that to skip all your ssl coding, and let the user put in a replacement for the /etc/nginx/conf.d/servers.conf ssl path in the UI and you'd be done with this time-wasting support on ssl certs..

This tmpfs /var/log tmpfs rw,size=128m,mode=0755 0 0 is just insanely small for a server my size. It's constantly filling up to 100%. I have loads of free RAM available. I would like to set this to 1024m or thereabouts. TIA!

What does the SYSNICS="1" mean or do in the /boot/config/network.cfg file? My unraid server uses LACP bond mode 4 with two physical NICs, apparently it works, but I'd like to finetune where possible. Shouldn't it be SYSNICS="2" then? I use bonding on a remote debian server with this config: auto lo iface lo inet loopback auto bond0 iface bond0 inet manual bond-slaves enp1s0 enp2s0 bond-mode 802.3ad bond-miimon 100 bond-updelay 200 bond-downdelay 200 bond-lacp-rate 0 bond-xmit_hash_policy layer3+4 auto br0 iface br0 inet static address 192.168.1.9 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 127.0.0.1 bridge_ports bond0 bridge_waitport 0 bridge_fd 0 And I would like to have my unraid server use the same settings for its bond mode 4. Currently it's: # Generated settings: IFNAME[0]="br0" BONDNAME[0]="bond0" BONDING_MIIMON[0]="100" BRNAME[0]="br0" BRSTP[0]="no" BRFD[0]="0" BONDING_MODE[0]="4" BONDNICS[0]="eth0 eth1" BRNICS[0]="bond0" PROTOCOL[0]="ipv4" USE_DHCP[0]="no" IPADDR[0]="192.168.1.11" NETMASK[0]="255.255.255.0" GATEWAY[0]="192.168.1.1" DNS_SERVER1="192.168.1.9" DNS_SERVER2="1.0.0.2" USE_DHCP6[0]="no" SYSNICS="1" The bonding seems to work: # ifconfig bond0: flags=5443<UP,BROADCAST,RUNNING,PROMISC,MASTER,MULTICAST> mtu 1500 ether d0:50:99:d1:8f:47 txqueuelen 1000 (Ethernet) RX packets 370606 bytes 60409014 (57.6 MiB) RX errors 0 dropped 191 overruns 0 frame 0 TX packets 2881873 bytes 4333925543 (4.0 GiB) TX errors 0 dropped 170 overruns 0 carrier 0 collisions 0 br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.11 netmask 255.255.255.0 broadcast 0.0.0.0 ether d0:50:99:d1:8f:47 txqueuelen 1000 (Ethernet) RX packets 338185 bytes 15248343 (14.5 MiB) RX errors 0 dropped 53 overruns 0 frame 0 TX packets 86837 bytes 4182443853 (3.8 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:3d:e5:d5:ce txqueuelen 0 (Ethernet) RX packets 650 bytes 75489 (73.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 497 bytes 124616 (121.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether d0:50:99:d1:8f:47 txqueuelen 1000 (Ethernet) RX packets 351441 bytes 57287347 (54.6 MiB) RX errors 0 dropped 4 overruns 0 frame 0 TX packets 53320 bytes 69543800 (66.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0x91300000-9137ffff eth1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether d0:50:99:d1:8f:47 txqueuelen 1000 (Ethernet) RX packets 14203 bytes 2002583 (1.9 MiB) RX errors 0 dropped 3 overruns 0 frame 0 TX packets 2824329 bytes 4262089349 (3.9 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0x91400000-9147ffff lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 loop txqueuelen 1000 (Local Loopback) RX packets 5309 bytes 378075 (369.2 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 5309 bytes 378075 (369.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vethadea463: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 76:af:3b:7e:14:8d txqueuelen 0 (Ethernet) RX packets 650 bytes 84589 (82.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 497 bytes 124616 (121.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether fe:54:00:57:cb:d9 txqueuelen 1000 (Ethernet) RX packets 6067 bytes 738073 (720.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 12127 bytes 36184105 (34.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 So that looks OK now, but is there a way to set bond-lacp-rate 0 bond-xmit_hash_policy layer3+4 in unraid network config?

Apparently this messes up 802.3ad / LACP bond mode 4, when you have that in use. I have 2 NICs on my unraid server that I have bonded to link aggregate.

This is still an issue. My disks keep spinning up almost immediately after spinning them down, which, barely any even do when asked. This used to not be the case, with the exact same hardware and software config. Something is waking them up, and it costs us a ridiculous amount of power. In fact, the reason I noticed this issue, is because we wanted to know what changed in our power consumption. Turned out it was the unraid server.

I agree, unbelievably complex. This procedure should at the very least be scripted/automatable, I think. It is in most other NAS systems, like Drobo, Synology, OMV, etc.

~# powertop --auto-tune modprobe cpufreq_stats failedLoaded 0 prior measurements RAPL device for cpu 0 RAPL device for cpu 0 Devfreq not enabled glob returned GLOB_ABORTED the port is sda the port is sdb the port is sdc the port is sdd the port is sde the port is sdf the port is sdg the port is sdh the port is sdi the port is sdj the port is sdk the port is sdl the port is sdm the port is sdn the port is sdo Leaving PowerTOP OK, I'm new to this. What do those failed and aborted mentions mean? I suppose I need to take my old monitor to the crawlspace and change BIOS settings for this machine, no?

What exactly do you mean by this? You have posted 5 commandlines. Rather confusing. The sdparm command does not state anything about drives being spun down or not, or at least I don't see it..

OK, ssds added to the cache pool and ran ~# btrfs balance start -dconvert=raid10 -mconvert=raid10 /mnt/cache -v Dumping filters: flags 0x7, state 0x0, force is off DATA (flags 0x100): converting, target=64, soft is off METADATA (flags 0x100): converting, target=64, soft is off SYSTEM (flags 0x100): converting, target=64, soft is off which I'll have to wait and see if it works, but it looks good thus far. ~# btrfs fi show Label: none uuid: f18f37c9-5244-4567-b88f-0bdcaa32e693 Total devices 7 FS bytes used 937.73GiB devid 2 size 894.25GiB used 893.54GiB path /dev/nvme0n1p1 devid 3 size 894.25GiB used 894.25GiB path /dev/sdp1 devid 4 size 894.25GiB used 894.25GiB path /dev/sdn1 devid 6 size 953.87GiB used 781.50MiB path /dev/sdj1 devid 7 size 953.87GiB used 781.50MiB path /dev/sdl1 *** Some devices missing Label: none uuid: dfa50f2a-9787-4d7a-88a5-7760f6b2e8a6 Total devices 1 FS bytes used 1.62GiB devid 1 size 20.00GiB used 5.02GiB path /dev/loop2 Label: none uuid: df5fea13-a625-4b37-b7c2-7fcc3328bc65 Total devices 1 FS bytes used 604.00KiB devid 1 size 1.00GiB used 398.38MiB path /dev/loop3 I still need to do a new config to move into ghost devices 1 and 5, I guess, but there's no hurry for that, is there?

Why is it bad to wipe the new devices? There's nothing on them. So, here's what I've done so far; - I've (successfully) changed the 5 SSD btrfs to a raid6 cache (coming from raid10). - Took out 2 of the 5 SSDs and connected the 2 new SSDs. - Fired up unRAID again. The array started, but I can't do anything regarding disks, because it says; "Disabled -- BTRFS operation is running" so I cannot stop the Array and/or format the new SSDs. and under the Cache it says "Cache not installed" and then shows the Cache2 Cache3 Cache4 ssds as normal (because they *are* installed). Is there a way to see the BTRFS operation's status? It shouldn't take too long since they're fast ssds, so they should be able to rebuild their raid6 with the 2 ssds missing, not?

Can I use ddrescue just for cloning (cache)disks as well (so without having to recover anything)? I need to move data from 2 old SSDs to 2 new SSDs (where the 2 old SSDs are part of a 5 disk SSD RAID10 array..).

Thus far no issues or errors, everything in the green and VMs are very responsive. Did not have proper performance tests beforehand, but VMs definitely slower and lagging before I pinned the cores, which is all gone now.

Just wanted to add how I expanded on this a little; Here's my /boot/syslinux/syslinux.cfg default menu.c32 menu title Lime Technology, Inc. prompt 0 timeout 30 label Unraid OS menu default kernel /bzimage append tpcie_acs_override=downstream,multifunction isolcpus=2,8,4,10 nohz_full=2,8,4,10 rcu_nocbs=2,8,4,10 initrd=/bzroot label Unraid OS GUI Mode kernel /bzimage append pcie_acs_override=downstream,multifunction initrd=/bzroot,/bzroot-gui label Unraid OS Safe Mode (no plugins, no GUI) kernel /bzimage append initrd=/bzroot unraidsafemode label Unraid OS GUI Safe Mode (no plugins) kernel /bzimage append initrd=/bzroot,/bzroot-gui unraidsafemode label Memtest86+ kernel /memtest so, as you can see, I added; isolcpus=2,8,4,10 nohz_full=2,8,4,10 rcu_nocbs=2,8,4,10 in order to have VMs use two hyperthreaded pairs, 2,8 and 4,10 (of the 11 cores total in the Xeon used by me) First booting after I'd set this showed me a nice GUI dialog I didn't know existed in unRAID, warning me some docker was pinned on one of the cores that was in use by a VM.

Not the right person to ask. I'm very much biased towards VM over docker instances. I have to work a lot with docker containers with devs and dev-ops stuff for work that I make money with. But I assure you; VM is easier to maintain in the long run. I always let out a sigh of relief when there's some issue with a VM, and not a docker container, containers are a PITA to fix problems for. Half the containers out there have missing access to parts of them. Half of those who are using containers don't know which parts that are mapped outside of the container will or will not be erased when an update of the container occurs. People that prefer dockers are usually making a spaghetti-code setup of dependencies, and forget to take notes, up to the level where they don't remember which container is the 'live' one. So many points of failure. So many ways to not being able to change config. Dockers are good for those who run software while developing what is on that docker, not for production level services, or set-it-and-forget-it apps like here with unraid.

You could try and install a debian minimal VM, then install ZeroTier on that. For me that works, I can remotely access router, and all that resides in the same LAN, from the zerotier instance on that VM, as long as I have it allow access to and from ZeroTier on the VM's firewall..

I'm not really understanding why you would want to permanently use cache? The main reason I picked cache here is because it is able to write faster and doesn't need to wake up and spin up all drives of the array when something is uploaded via ftp. So yes, I want it to be moved to the array (and stay there), I only want ProFTPd to use cache when files get uploaded. How does one achieve that? I'm not entirely understanding how unraid uses the phrase "share" here. What gets shared between what? Never mind, I think I get it now. unraid uses cache for the writes either way, so I set the homeroot for this ftpuser to be under /mnt/user and under Shares set the dir to use cache [Yes]. Thanks itimpi.

Another thing, I have set /mnt/cache/somefolderforftp as an ftpuser's homeroot, but this dir is disappearing after unraid moves it to the array, it seems, and then ftp fails, because the user's home folder is gone. Something I've missed? How do I make the dir persistent on cache ?

Just do as I do, run piwigo, mariadb, php, nginx in a debian 9 VM. So much easier to maintain. You use the VM shares unraid offers for the data and you're done. Plus, if you want nextcloud, just add it alongside in the same VM, uses a lot of the same resources, easy to maintain. nginx hosts like a normal webserver, no proxying, easy to route IP to/from the VM IP. Performance is superb in this household and beyond. And if it tends to slow down, I just give extra resources to the VM. I installed nginx from source, which allowed me to use the fancyindex extension and several other cutting edge security and performance stuff. Another advantage is mysql access is local for both piwigo and nextcloud. No fussing about with virtual networks for db access. Doing this with docker is just a PITA in the end. They're doing this where I work, but honestly, I'm failing to see the advantages. It costs way more time to maintain. The only time gained is during (first) install. docker is nice for testing purposes, not for production level serving of piwigo/nextcloud.

It seems the default is set as to allow only 1 instance per user to be logged in. Did not expect that. Never seen that used before, not even in vsftpd. I think you should change that. Allow more logins per username.

Since you run it on a VM, I'm assuming it's a linux VM? If so, you can install CSF/LFD on it and use that to only allow access to your gateway (and WAN). For those looking into installing OpenVPN on a VM, try this on a minimal debian server VM; https://github.com/Nyr/openvpn-install