Jump to content

TechGeek01

Members
  • Posts

    29
  • Joined

  • Last visited

Posts posted by TechGeek01

  1. So it was working on Unraid, as was sabnzbdvpn. I was attempting to get a second instance up and running (testing with my login, but setting up for a friend), and after running into these same issues, I changed the password, and updated the containers on Unraid. The only thing changed was the password. It's alphanumeric with no special characters, and 64 characters. Does it maybe need to be shortened a bit?

  2. So I'm having issues connecting with NordVPN UDP. Logs show the following repeated constantly:

     

    2021-09-27 22:21:47,937 DEBG 'start-script' stdout output:
    2021-09-27 22:21:47 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
    
    2021-09-27 22:21:47,938 DEBG 'start-script' stdout output:
    2021-09-27 22:21:47 WARNING: file 'credentials.conf' is group or others accessible
    2021-09-27 22:21:47 OpenVPN 2.5.1 [git:makepkg/f186691b32e68362+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 24 2021
    2021-09-27 22:21:47 library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.10
    
    2021-09-27 22:21:47,939 DEBG 'start-script' stdout output:
    2021-09-27 22:21:47 WARNING: --ping should normally be used with --ping-restart or --ping-exit
    2021-09-27 22:21:47 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    
    2021-09-27 22:21:47,940 DEBG 'start-script' stdout output:
    2021-09-27 22:21:47 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
    2021-09-27 22:21:47 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
    
    2021-09-27 22:21:47,940 DEBG 'start-script' stdout output:
    2021-09-27 22:21:47 TCP/UDP: Preserving recently used remote address: [AF_INET]89.187.182.71:1194
    2021-09-27 22:21:47 Socket Buffers: R=[212992->212992] S=[212992->212992]
    2021-09-27 22:21:47 UDP link local: (not bound)
    2021-09-27 22:21:47 UDP link remote: [AF_INET]89.187.182.71:1194
    
    2021-09-27 22:21:47,954 DEBG 'start-script' stdout output:
    2021-09-27 22:21:47 TLS: Initial packet from [AF_INET]89.187.182.71:1194, sid=df5141ca 49f1b7f1
    
    2021-09-27 22:21:47,988 DEBG 'start-script' stdout output:
    2021-09-27 22:21:47 VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA
    
    2021-09-27 22:21:47,988 DEBG 'start-script' stdout output:
    2021-09-27 22:21:47 VERIFY OK: depth=1, C=PA, O=NordVPN, CN=NordVPN CA6
    
    2021-09-27 22:21:47,989 DEBG 'start-script' stdout output:
    2021-09-27 22:21:47 VERIFY KU OK
    2021-09-27 22:21:47 Validating certificate extended key usage
    2021-09-27 22:21:47 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
    2021-09-27 22:21:47 VERIFY EKU OK
    2021-09-27 22:21:47 VERIFY OK: depth=0, CN=us6722.nordvpn.com
    
    2021-09-27 22:21:50,007 DEBG 'start-script' stdout output:
    2021-09-27 22:21:50 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
    2021-09-27 22:21:50 [us6722.nordvpn.com] Peer Connection Initiated with [AF_INET]89.187.182.71:1194
    
    2021-09-27 22:21:50,007 DEBG 'start-script' stdout output:
    2021-09-27 22:21:50 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA
    2021-09-27 22:21:50 [us6722.nordvpn.com] Peer Connection Initiated with [AF_INET]89.187.182.71:1194
    
    2021-09-27 22:21:51,157 DEBG 'start-script' stdout output:
    2021-09-27 22:21:51 SENT CONTROL [us6722.nordvpn.com]: 'PUSH_REQUEST' (status=1)
    
    2021-09-27 22:21:51,171 DEBG 'start-script' stdout output:
    2021-09-27 22:21:51 AUTH: Received control message: AUTH_FAILED
    
    2021-09-27 22:21:51,172 DEBG 'start-script' stdout output:
    2021-09-27 22:21:51 SIGTERM[soft,auth-failure] received, process exiting

     

    Debug is enabled, credentials are recently changed, have no special characters, and have been verified to work in browser. openvpn directory contains the UDP .ovpn file, as well as the cert files for the associated server. Both delugevpn and Unraid are up to date at the time of writing this. Any ideas here?

  3. 5 hours ago, zspearmint said:

    In the display settings I use a banner image, have a dark gray header background color of #333333, and white text of #ffffff

    Yeah, that's what I'm doing currently now as well. Only difference is before, I didn't have the custom header color, so the header was default white, while my text was also white.

     

    Maybe you could add a check for other users that have the same deal I did (dark custom header image, but default color), and make it so that if the custom text color, and the header color are too close together, provided they're not both user-set (I didn't have a custom header color before, just the theme default), have it change the unset one to contrast? That is, if I had white text, but an unset header color, it would see they're both close together, and change the color the menu uses to something darker and readable.

     

    Not sure if this is the most elegant way to do that while retaining the custom display options, but it would at least help readability in that edge case.

  4. 50 minutes ago, rguinn said:

    Thanks it for sure a issue with the icons on Page 4 only the first 2 work the rest just blank it out 

    Also chiming in, seeing the same thing with the Supermicro 846 icon in the list. No icon for me in the my servers page.

  5. Just wanted to chime in on a coloring issue.

     

    I'm using the "black" color theme, and have a white header. I have a custom header image that's gray, so the tab bar is black text on white, but the header image is gray with some stuff in it. To see text here, I have the custom text color set to white in display settings.

     

    The menus for me are unreadable in this plugin in the header. Seems that after testing, the background of the flyout menu takes the custom text color, and text takes the custom background color. Presumably the correct approach is for the text in the header to take the text color of the tabs, and for the flyout to match this? Without a custom header color set, the default in this theme is white. With my custom text color set to white to see version number and such on a gray header image, this otherwise makes text unreadable. This plugin, since it takes the color of the header, should more than likely do the same thing the tabs do, and ignore the custom text color and just set text to white/black depending on luminance of the header color.

    Screenshot 2021-03-15 23_57_27-helium_DisplaySettings — Mozilla Firefox.png

    Screenshot 2021-03-16 00_04_30-helium_DisplaySettings — Mozilla Firefox.png

  6. 12 hours ago, SimonF said:

    The Nvidia package is also dependent on kernel, it sounds like you cannot download the newer version for the 6.9.0 kernel.

     

    Have you tried removing the plugin and re-installing?

    Just an update, that was indeed the problem. Uninstall and reinstall of the Nvidia Driver plugin worked like a charm!

  7. 1 hour ago, SimonF said:

    The Nvidia package is also dependent on kernel, it sounds like you cannot download the newer version for the 6.9.0 kernel.

     

    Have you tried removing the plugin and re-installing?

    I have not yet, but that will be my next project once it's not 4AM. I will definitely post back with results when I do though!

  8. Updated from rc2, and after rebooting, I get the following on boot at the console, right before the login prompt

     

    main: line 96: ( / 1000 ): syntax error: operand expected (error token is "/ 1000 )")
    modprobe: FATAL: Module nvidia not found in directory /lib/modules/5.10.19-Unraid

     

    My initial thought was that this pertained to the Nvidia Driver plugin, but that was on the latest version before the upgrade. Only thing that changed is from rc2 to 6.9 stable. Googling for that error returns no relevant results, so I'm at a loss here.

     

    As a result, Plex Docker won't start. GPU is visible in system devices, and not bound to VFIO, but the Nvidia Driver plugin doesn't see the card, presumably as a result of the above boot errors. Server boots fine, and everything barring the GPU works fine without halting boot, but I'm at a loss here.

    helium-diagnostics-20210303-0224.zip

  9. In the last couple months, I moved Unraid over from a Dell R510 to a Supermicro build, and since then, I see occasional warnings about machine check errors.

    Dec 19 16:49:16 helium kernel: mce: [Hardware Error]: Machine check events logged
    Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: HANDLING MCE MEMORY ERROR
    Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: CPU 6: Machine Check Event: 0 Bank 10: 8c000046000800c1
    Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: TSC 51ce458bc87a8
    Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: ADDR c5c6ea000
    Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: MISC 900100010000c8c
    Dec 19 16:49:16 helium kernel: EDAC sbridge MC0: PROCESSOR 0:306f2 TIME 1608418156 SOCKET 1 APIC 10
    Dec 19 16:49:16 helium kernel: EDAC MC0: 1 CE memory scrubbing error on CPU_SrcID#1_Ha#0_Chan#1_DIMM#0 (channel:1 slot:0 page:0xc5c6ea offset:0x0 grain:32 syndrome:0x0 -  area:DRAM err_code:0008:00c1 socket:1 ha:0 channel_mask:2 rank:0)

    Current system is a Supermicro X10DRi with dual E5-2620 v3 processors, and 64GB of RAM, configured as 2x16GB per socket.

     

    This obviously is a memory issue, but what exactly causes this, and how do I go about fixing it? I don't know a lot about these sort of logs. Presumably this isn't logging of things like ECC corrections, and this indicates a memory issue where I may have to replace the stick, correct?

    helium-diagnostics-20201219-2044.zip

  10. Let me start out by saying, I realize that this doesn't apply as much in enterprise situations. However, given that Unraid has the ability to add arbitrary drives to the array, it's much more common in the homelab community than something like FreeNAS, which pretty much requires you already have all the drives you're using.

     

    I believe the homelab community, while not all of Unraid, is a large part of the Unraid community, and would benefit here.

     

    A lot of us in this homelab community need, or want, a cheap way to back up data offsite, and probably have other hard drives lying around. The logical conclusion here is to pop a drive into Unraid, format it, and copy data over. And I'm sure a lot of us, myself included, would like to encrypt this data. Given that Unraid uses the key files stored locally to encrypt drives, this makes it dead simple, because you don't have to enter a passkey, or even think. You just mount the drives, and they get decrypted. This is great for security in case these drives fall in the wrong hands if they're being stored elsewhere.

     

    Encryption seems to be most commonly encrypted XFS, to match the XFS typically used in the main array. The current solution for encrypted data here is to modify the cache pool. This involves a bunch of steps:

    1. Stop the array
    2. If you have multiple cache drives in a pool, drop that down to 1
      1. Confirm that you want to start with the missing cache drives, and start the array
      2. Stop the array again
    3. Stop and disable Docker containers and VMs that live on the cache (and can't run with the legitimate cache drives missing)
    4. Change cache filesystem to encrypted XFS (since you can't do XFS on cache with multiple drives)
    5. Swap the "cache" drive to the drive you intend to back up to
    6. Start the array
    7. Format the disk
    8. Stop the array
    9. Put your cache FS back to what it was before
    10. Swap the cache drives back to what they were, in the right order
    11. Start the array again

     

    From there, you can use Unassigned Devices to mount the now encrypted drive, and copy data to it. This works flawlessly if you do it correctly, but it's a seemingly dangerous process, and is at the risk of losing data that lives on cache if you misstep. I think we can all agree that this is a lengthy, and potentially risky process, to obtain a drive formatted with an encrypted filesystem that Unraid knows how to decrypt.

     

    I understand that 6.9 plans to bring multiple pools into the equation, which will help this greatly, but I assume it would be much cleaner to be able to have the option to take an unassigned drive that's not part of the array or cache, and be able to choose a filesystem to format it in. This way, without having to stop the array to reconfigure cache, or another pool (and thus, disrupting Docker, and VMs in the process, as well as any live transfers or work to or from the array itself), we could pop a drive in, and be able to format it as any filesystem Unraid supports.

×
×
  • Create New...