Orange PI Zero 3 - Initial Set Up, DDNS, and WireGuard Configuration

Intro:

MAJOR EDIT IN PROGRESS!!!!!

This is a multipart article wrapped into one. We'll use the Orange PI Zero 3 as a DDNS update client, Pi-hole server, and as a WireGuard server. This will assume you've read and setup the pi already. (INSERT ARTICLE HERE ABOUT GENERAL SETUP). We'll load some cool tools for administering the network as well.

This entire thing started when you could no longer buy a Raspberry PI for $35.

Usually NVR camera systems will include some sort of dynamic dns service or allow you to use your own update URL. I had the "pleasure" of working on a Speco NVR unit. If you've never heard of them stay away, they're akin with the no name systems sold in big box stores. Five minutes with this thing and you'll want to throw it out a window. There's tons of standard features that are nowhere to be found on these units. I've seen cheaper noname brands that include more functionality.

This particular Speco VX NVR only includes their own ddns service (which does not work) and contains no alternative options. They do not give you the option to use popular services such as "no-ip" or "dyndns". Usually you can get away with using the "dyndns" update url with your own service. Nope, not this time.

In comes the Raspberry PI, great idea but still (10/2023) ridiculously overpriced by scalpers, so this is a no go. Orange PI looks like a viable alternative on paper at a quarter of the cost and is currently in stock.

I'm using the Orange PI Zero 3 for this (tested with 1 & 2gb version). Amazon had them delivered the same day.

Since there are no commercial cases available I have modified another design to include a spot for velcro and or hidden drywall screws. I've also modified it to take the el cheapo Amazon stainless metric socket cap screws that have a splined design on the cap side. My local hardware store has the smooth side version (18-8) which is why they fit easily on the first print.

I can only find two types socket cap screws from McMaster-Carr that fit the bill for this design. One has a smooth side and is labeled " 18-8 Stainless Steel Socket Head Screws" and the other " Super-Corrosion-Resistant 316 Stainless Steel Socket Head Screws" is overkill for this design but I suspect it's what the Chinese have sloppily copied and are reselling on Amazon.

I believe the original designer of this case used the CAD files in Fusion 360 of the 18-8 screws and not a physical measurement of the Amazon specials.

I'm in the process of redesigning this case from the ground up to make the installation easier.

rsync - Syntax for Copying Data Between Two QNAP NAS Devices

 

Intro:

A few weeks ago I had a QNAP box shit the bed. One of the drives in the 8 disk array had a bad sector while another drive was throwing unrecoverable read errors. I needed an immediate way to copy the data to a new QNAP NAS since I could not get access to the SMB shares. When a disk or two fails based on the RAID level, the array falls into what QNAP calls, "Read-Only" mode. The array cannot be written to at this point which poses a problem if this is the first pool and your applications are installed here.

None of the GUI applications like "Hybrid Backup Sync 3" or "File Station" were working. Rsync is now the only option. Thankfully "Hybrid Backup Sync 3" was installed on the source box prior to the drives failing or I don't think the rsync service would have been active (there's a toggle to turn it on in HBS3). There is a way to stop and start all services but not individual ones on these boxes from what I can tell. It really wouldn't have mattered in this case since the applications cannot write temporary data to the pool since it's in a read-only state.

Rsync on QNAP devices seems to be a customized version. They're running "version 3.0.7 protocol version 30" dated 2009. According to rsync's wiki, the current stable version at the time of writing (09/08/23) is 3.2.7. So technically we're using a really outdated copy which may induce errors.

I have a 10Gbps fiber link between these two QNAP boxes using (2) Silicom Intel 82599ES Dual-Port SFP+ cards. (there's an interesting article coming about modifying the 82599 EEPROM of Intel based X520 cards to use any brand fibre transceiver, not just Intel branded ones). The source qnap system is in "Read-Only" mode so the copy operation is being slowed to an average of 150-250 MB/s. There's also other issues with one of the new disks appearing offline which may contribute to this however focusing on getting the data off this box asap is the priority here. If another disk fails I'm screwed.

So far I've copied about 70 TB over this link at those speeds. Painfully slow. At one point while reading and failing on a file, the read speed dropped to around 30 MB/s. Obviously there's an issue on the disk's surface in that area and that drive is destined for the scrap pile since it's out of warranty.

With the exception of that one small file which I had a backup for, everything else copied without incident taking approximately a week at those speeds.

rsync Syntax:

Here's the syntax I used to copy data from a TVS-871 (QTS) to a new TVS-h874 (QuTS hero):

rsync --progress --protect-args -avhro "/share/CACHEDEV1_DATA/<INSERT FOLDER HERE>/" user@172.16.0.3:"/share/ZFS19_DATA/<DESTINATION FOLDER>/"

Dry-Run:

To do a dry-run without copying anything, add an "n" to the beginning or end of "-avhro". This is good for determining the folder size prior to the actual copy operation.

Excluding Folders:

If you need to exclude folders create a file named, "pattern.txt" and add the excluded folders:

1. "vi pattern.txt"
2. Press "Insert" key to begin editing file.
3. Add one folder name per line i.e.,
• @Recycle
• .@__thumb
• .streams
4. ":wq!" to save and exit.
1. ":q!" to exit without saving.

Run the following command to invoke "pattern.txt" along with rsync.

rsync --progress --protect-args -avhro --exclude-from="/root/pattern.txt" "/share/CACHEDEV1_DATA/<INSERT FOLDER HERE>/" bob@172.16.0.3:"/share/ZFS19_DATA/<DESTINATION FOLDER>/"

How to Kill Inactive or Forgotten SSH Sessions in Linux

Intro:

From time to time I'll have a slew of terminal windows already open and I'll randomly open another one to the same host. I usually forget that I'm already logged in to another shell via PuTTY. Normally when I'm done with one instance, I'll exit the session and close PuTTY. Then a few minutes goes by and I'll come across another PuTTY window on the screen still logged in. D'oh.

Problem:

Well, that's where killing inactive SSH sessions comes in. Read on for a quick and easy way to identify other sessions.

Fix:

First off, by typing 'w' at the command prompt you can see who else is logged into said computer. You can learn more about this command here and here. (Basic list of Unix commands on Wiki)

Run the following command:

pstree -p

In the following output look for the line that starts with "sshd(XXX)". This seems rather obvious in the following example but in the real terminal there will be other program instances running and you'll see them above and below the following two lines. "sshd(468) is the process you're looking for in the sea of processes. Yours will have a different number after it.

*If you see a line that has "sftp-server" instead of "bash" just know that this is more than likely a connection via "WinSCP" or the likes.

 ├─sshd(468)─┬─sshd(1696)───sshd(1704)───bash(1705)

 │           └─sshd(1943)───sshd(1958)───bash(1959)───pstree(2251)

In the above example look for "pstree" at the end of the line. PID 1943 refers to your current session. The remaining sshd session with a PID of 1696 (first line) indicates another session. You can have multiple sessions to the same computer via SSH, however if your terminal window is closed accidentally or you have a session that is inactive, you would want to kill this session.

Run the following command to kill existing sessions by PID number (replace 1696 with your PID number):

sudo kill 1696

Recheck with the "w" command. You should only see one session, which is your current one.

Extras:

You can also modify the config files for SSH here using "nano" to either disconnect inactive clients after a timeout period or disable a timeout which isn't suggested in a production environment:

"sudo nano /etc/ssh/sshd_config"

Look for the following lines:

ClientAliveInterval 600

ClientAliveCountMax 3

"ClientAliveInterval" is the number of seconds that the server will wait before sending a null packet to the client (to keep the connection alive). If you set this to zero the server will never send the null packet.

"ClientAliveCountMax" is the number of times the server will send the null packet and wait for a response defined by "ClientAliveInterval" before terminating the session.

Example: If you set "ClientAliveInterval" to 400 seconds and set "ClientAliveCountMax" to a count of 5, then the server will send a null packet (through the encrypted channel) every 400 seconds for a count of 5 times waiting to hear back from the client. If the server receives no response from the client after that, then the server will terminate the session after about 33 minutes in this example.

400 * 5 = 2000

2000/60 (minutes)

33.33 minutes

** Remember, a setting of zero means it's disabled. Therefore you should set these values high enough to avoid the "broken pipe error" which means that the data stopped flowing to and the client/server is unable to start the flow back up.

More information can be found here about the above commands:

https://linux.die.net/man/5/sshd_config

👽