cybrnook

Opened a PR: https://github.com/binhex/arch-qbittorrentvpn/pull/22

Ah, that makes sense seeing as it's using noVNC, thanks for the reply.

@binhex Is it perhaps a leftover that your template for Krusader comes down with a VNC_PASSWORD default key:

@binhex Thanks for this container, it seems to work great! One bit of additional functionality I would like to see is the ability to use the "remote-random" option in the ovpn file, and specify a handfull of "remote" servers for the pool to pick from. I looked at your git page, and in the install script you mention that you list: # get first matching 'remote' line in ovpn (Ignores any other remote hosts after the first entry) # remove all remote lines as we cannot cope with multi remote lines (strip out all remote lines, wipes any remaining?) # write the single remote line back to the ovpn file on line 1 (write contents of line 1 back into stripped ovpn file, all other remote now wiped out) Out side of coming up with some juggling logic, is there any other reason you would have to not support multiple remote hosts outside of cleaning the entry prior to using it? I could work on submitting a PR to you to try and accommodate this, but wanted your take on it first? EDIT: Or just add the ability to pick from a random .ovpn file that exists in /config/openvpn when defining VPN_CONFIG, if more than one .ovpn file exists. That would be a pretty clean way, and would give the container the ability to bounce around a few different servers on restart. Plus would keep most of your logic as is, since we would only be changing the VPN_CONFIG definition line.

And also Ctrl+F5 to clear cache on the page (Assuming just hitting refresh).

Painless from 6.7.1.

mds=off is for zombieload

Upgraded from 6.7.0 to 6.7.1 without issue. I have 2 x NVME drives as cache in RAID1. Docker settings are set to default /mnt/user/appdata. No issues starting my Plex docker. Using the Plex docker managed by Plex. So far so good.

Thanks for the input. So, in your case for one, you are an AMD system not Intel. So your platform isn't as heavily hit as say my 2011v3 based Intel systems, since Intel is really behind the ball on these patches. As well, I don't want the impression that disabling these is a magic +%30 performance boost across the board on all benchmark suites, that's absolutely not the case. But what we can see, like from @zoggy 's EXCELLENT pre/post test case on an Intel based system, he see's perf boosts across the board, and up to %80 improvement in context switching (almost at the bottom of the page): https://openbenchmarking.org/result/1906037-HV-190603PTS41,1906033-HV-190603PTS92 So the benefits are real, if your use cases are in alignment, and are Intel based. Not to say though that disabling the overhead on an AMD system is not fruitful as well, especially on the OS level. Just don't expect an even +%30 across the board, all platforms, etc.... With that said, I look forward to maybe bouncing some ideas off you when I get my 2970WX system up and running. It's all here, just no time to actually build it out 🙂 Plus the fact we have been battling SLES scheduling issues on IBM Power at work, and it's issues that we faced on incorrect affinity scheduling/assignments to non-optimal numa nodes.... I am taking a little time before hopping right back into that 🙂

@Squid is right. It's a nicer two-fer. Since we are in a world of chips right now that are not immune to these attacks at the HW level, we are getting updates in two channels right now. BIOS level microcode updates, Windows patch level updates, linux kernel level patches and microcode updates. etc.... Okay so more than two channels 🙂 (It's a mess is the easy way). With that, only some vulnerabilities are addressed at the BIOS level with microcode. Others are being handled by patches and updates. To FULLY disable it all, would require not only staying on an older un-patched BIOS (for some, they may have no option as MB vendors and Intel are only retrofitting but so far back), but also applying these mitigations. I don't really recommend staying on an old BIOS as other features come in newer BIOS versions, like AGESA updates and CPU compatibility for newer Chips on older chipsets. As noted in the plugin, there are still a good amount of mitigations we can disable at the kernel level, and users are seeing perf gains in the VM space. As new CPU's are patched at the hardware level, this will be even more confusing since we will have microcode in BIOS updates that apply only to certain CPU's, but not other ones, and then patches at the OS level that will seemingly apply to everyone since we all pay the price at the OS level.

Thanks for sharing @zoggy , great testing

New plugin added to the repo via @Squid

Bravo sir, very much appreciated! Worked great btw.

@TechMed I'm switching it up a bit. I actually installed NUT on my pfsense gateway now, and have all my devices ( 2 x unraid and 1 x Synology) all checking in as clients to the gateway now :-). Figure gateway is nonvolatile, and would likely be the last to go down in my rack.

AMD I am not so sure we will see any large gains vs the Intel side. But thanks for testing it out 🙂 I will have my TR setup going soon and will disable these on it anyways 🙂

Real long names are now being truncated to avoid overlapping. It's in the change log: webgui: Dashboard: fixed wrapping of long lines webgui: Dashboard: wrap long descriptions

You going to add to your Alpha runbook? 🙂

Seems that we will be getting a newer, more simplified, flag we can set to disable mitigation's called: mitigations=off Other options would be: - mitigations=off: Disable all mitigations. - mitigations=auto: [default] Enable all the default mitigations, but leave SMT enabled, even if it's vulnerable. - mitigations=auto,nosmt: Enable all the default mitigations, disabling SMT if needed by a mitigation. In the meantime, we can continue to use the options above until I can test the new options out on unraid with a newer kernel (future releases once unraid upgrades kernel). There seems to be validation of it working in 5.0.16 Kernel. However seems to be a release intended for Kernel 5.2. https://www.phoronix.com/scan.php?page=news_item&px=Spectre-Meltdown-Easy-Switch-52 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.19.43&id=8cb932aca5d6728661a24eaecead9a34329903ff

Figured I would share: https://www.tomshardware.com/news/intel-amd-mitigations-performance-impact,39381.html https://www.phoronix.com/scan.php?page=article&item=mds-zombieload-mit&num=10

On your "Main" tab, click on your "Flash" drive" Then scroll down:

@limetech Thread posted:

UPDATE (010/11/2019) PLUGIN Updated for 6.8.0 RC1 + @Squid was awesome again in keeping with the newer kernel update, and the more simplified syntax now of "mitigations=off". If you already installed the plugin on a lower release and enabled it, nothing is needed prior to upgrading. Squid thought of and accounted for that and the plugin will handle it during boot. UPDATE (06/03/2019) PLUGIN AVAILABLE!!! @Squid was awesome enough to take this work and put it into a plugin, as many have asked for. It's a great start, and covers the basics out of the gate for everyone at the moment. Once the kernel starts rolling higher, we can change the current long string to a shorter variation, but I think that will be later in the future, post 6.8.0+..... Original Post: As many are aware, Intel has had some serious security vulnerabilities released over the past year. "Spectre", "Meltdown", and now one of the strongest dubbed "Zombieload" aka MDS. Intel seems to be having some skeletons coming out of the closet, which saw a CEO resign, and market share loss now to AMD. The mitigation's to these vulnerabilities have all individually come with a performance cost, Spectre/Meltdown in the range of ~%15, and now MDS rumored to need Hyperthreading disabled altogether to mitigate, costing upwards of %30-%40 (sources are based on the internet, so take with a grain of salt). So add them all together, and that's a pretty hefty penalty for users who may not even be a target for this kind of attack. Personally, I have nothing that sensitive at my home running in individual dockers or VM's that I would worry enough about if someone from one area could read data from the other. As well, my local users are myself and my wife 🙂 , so she could just TAKE the money from the bank in person 🙂 Not a threat to me. I don't care if someone is watching me play games on a vm, or is watching that I am encoding or decrypting a movie, big deal, not much going on at my house anyone would work hard enough to watch....... and if someone did make it that far to target me, I got bigger problems than speculative execution, like checking my firewall rules!! So, with that said, this is ALL AT YOUR OWN RISK, I or the community do not assume any responsibility of damage due to the disablement of these mitigation's. As of 6.7.0, we have kernel level 4.19.41 which marks the last kernel to NOT mitigate against MDS. To disable Spectre/Meltdown for release 6.7.0, adjust your syslinux.cfg file as follows (and reboot): pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier As of 6.7.1 RC1, we have kernel level 4.19.43 which marks the first kernel TO mitigate against Spectre/Meltdown AND MDS. To disable Spectre/Meltdown/MDS for release 6.7.1 RC1+, adjust your syslinux.cfg as follows (and reboot): pti=off spectre_v2=off l1tf=off mds=off nospec_store_bypass_disable no_stf_barrier You can validate the mitigation's on the OS before/after by: cat /sys/devices/system/cpu/vulnerabilities/* BEFORE: Should look similar to (notice the Mitigation's): Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable Mitigation: Clear CPU buffers; SMT vulnerable Mitigation: PTI Mitigation: Speculative Store Bypass disabled via prctl and seccomp Mitigation: __user pointer sanitization Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling AFTER: Should look similar to (notice the Vulnerable): Mitigation: PTE Inversion; VMX: vulnerable Vulnerable; SMT vulnerable Vulnerable Vulnerable Mitigation: __user pointer sanitization Vulnerable, IBPB: disabled, STIBP: disabled

Will do, thanks! I will work on working it up a bit nicer and then post once it's super clear.

Updated my post @BRiT and @glennv , got it working