mattkhan

fortunately rebuild consistently fails v quickly Dec 7 09:17:23 zalaga-unraid Parity Check Tuning: Parity Sync/Data Rebuild detected Dec 7 09:19:25 zalaga-unraid kernel: mpt2sas_cm0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303) Dec 7 09:20:02 zalaga-unraid kernel: sd 7:0:7:0: device_block, handle(0x0010) Dec 7 09:20:03 zalaga-unraid kernel: sd 7:0:7:0: device_unblock and setting to running, handle(0x0010) Dec 7 09:20:03 zalaga-unraid kernel: sd 7:0:7:0: [sdi] tag#4840 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=DRIVER_OK cmd_age=48s Dec 7 09:20:03 zalaga-unraid kernel: sd 7:0:7:0: [sdi] tag#4840 CDB: opcode=0x8a 8a 00 00 00 00 00 03 11 95 e8 00 00 04 00 00 00 Dec 7 09:20:03 zalaga-unraid kernel: I/O error, dev sdi, sector 51484136 op 0x1:(WRITE) flags 0x4000 phys_seg 128 prio class 2 Dec 7 09:20:03 zalaga-unraid kernel: md: disk0 write error, sector=51484072 and then reams of errors before it takes the device offline again it's attached to an 8 port pcie card and I've already switched from one port to another on that so I guess this really does mean the drive is dead as the problem follows the drive?

kicked off another attempt to rebuild parity, diagnostics also attached zalaga-unraid-diagnostics-20241207-0915.zip

my parity drive was disabled the other day, checked cables/attempted to rebuild parity and it dropped off with the same error which google might suggest means a drive failure at some particular sectors. As a result I ran an extended smart self test which I thought checks every sector to verify, this passes ok though so now I'm unsure if the drive is really dead or not. Any help appreciated, the smart report is attached parity_smart_report.txt

No comment from them on when they will upgrade openvpn-as to openvpn 2.4 but it seems it is not necessary anyway as the config options to avoid this are available now. They are described in https://sweet32.info/ as either a client side only option reneg-bytes 64000000 Alternatively, if you control the server and client, then you can set on both the server and client config directives (via the Advanced VPN page) cipher AES-256-CBC It doesn't seem there is a way to set this via the cli or in config so I don't suppose there is anything you can do to set this in the container. I suppose you could add something to the setup docs though. FWIW further reading suggests to use a few other directives, namely to set server and client as follows for a reasonably hardened config cipher AES-256-CBC auth SHA512 tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 This seems to work fine for me. The support guy also commented on the possibility of an attack via the embedded twisted web server which I'll just post here for reference

I can't find a public repo for openvpn-as & it seems they use a trac instance on their site instead of github for issues so I logged a support ticket.

I've added this to my setup recently, v easy to get going so thanks for providing it. I'm using a 2.4.3 openvpn client and I notice it complains about WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).' This seems to be https://community.openvpn.net/openvpn/wiki/SWEET32 The container logs indicate this is a 2.3.17 server 2017-08-04 17:14:46+0100 [-] OVPN 0 OUT: 'Fri Aug 4 17:14:46 2017 OpenVPN 2.3.17 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jun 27 2017' https://openvpn.net/index.php/open-source/downloads.html indicates this is the old stable version, 2.4.3 is the current stable and this seems to be the fix (e.g. picking some other random docker openvpn container - https://github.com/kylemanna/docker-openvpn/issues/267) . I notice that your dependency is on https://openvpn.net/index.php/access-server/download-openvpn-as-sw.html for ubuntu 16 and it's not immediately obvious how this relates to the openvpn version. Do you have a plan to close this gap?

bts buffer is the branch trace store buffer, google indicates there was a patch last year to reduce the frequency of such logs & whether it happens or not is a function of memory fragmentation. I would think that seeing this is just a sign that this plugin is working your CPU hard. Any other problems noted or just that warn?

OK thanks, good to have an explanation for the behaviour.

I installed this earlier and it almost immediately triggered the reiser issue described in https://lime-technology.com/forum/index.php?topic=39911.0 which I've never seen before, by "almost immediately" I mean "within a minute or so". emhttp was then hung and wa times were at ~50% or so & it seems this was due to a bs2sum process being stuck in D state (hence unkillable even by kill -9) as it attempted to calculate the hash for some particular file, the offending disk was thus unmountable and a hard reset was the only way out. The system itself was still responsive through all this, just emhttp and that zombie process was the (big) problem. The disk in question has been running solidly for a shade over 2yrs and no other disk issues noted until now on that sata controller. reiserfsck has just finished on the offending disk and no issues noted (some journal replay action but nothing else to report), smart report is also completely clear. It's not obvious how your plugin could trigger this (as opposed to some previously unexploited weakness in my system) but thought I'd mention it anyway.