Monthly Archives: December 2024

QNAP NAS

Posted on by

I replaced my ancient (but working) DLink NAS with a much newer and faster QNAP NAS (Model TS-464-8G). The QNAP hardware is nice: a compact package supports 4 SATA drives in a variety of RAID configurations, 2x NVMe drives, 2x 2.5GbE ports with option to add a 10GbE card, has a slick web-based user interface, and consumes relatively little power. It runs a custom linux on an a Celeron N5095.
I don’t like the custom linux.

UPS Support

Naturally, I want my data storage to be protected by a UPS and to automatically and safely shut down before the UPS battery is exhausted if there is an extended power outage. I use a CyberPower CP1500PFCLCD UPS (which I am very happy with so far) to protect several NUC servers, an L2 switch, and the NAS. The UPS is connected to one of the NUC proxmox servers via USB. I run NUT on that server, including the nut-server that allows other machines (such as the NAS) to access the UPS over the network as nut-clients. The problem is that QNAP makes this more difficult than it has to be. They support nut (which is nice), but they seem to have done so mainly to allow one QNAP NAS to access another QNAP NAS connected to the UPS.

This is what I had to do to get the QNAP NAS to run as a generic nut client:

  • Control Panel -> External Device -> UPS Tab
  • Select Network UPS Slave
  • Enter the IP address of your nut server
  • Apply changes
  • Reset the NAS to start the upsutil (nut-client daemon) running

How did the NAS get the NUT UPS name, user name, and password used on the nut-server? It didn’t; the NUT support from QNAP hard-coded them as ‘qnapups’, ‘admin’, ‘123456’. And folks wonder why QNAP has had security issues.

You can change the user name and password by enabling the admin user, logging into the NAS via ssh as the admin user, and editing /etc/config/ups/upsmon.conf (make a .orig copy first). Find the line that reads:
MONITOR qnapups@myNutServerIp 1 admin 123456 slave
and replace ‘admin’ and ‘123456’ with the user name and password you have assigned for slave devices on your nut server in /etc/nut/upsd.users

Unfortunately, QNAP doesn’t let you change the UPS name; it *must* be qnapups
Fortunately, NUT provides a workaround for this that doesn’t require changing all the other nut clients. On your nut server, edit your /etc/nut/ups.conf file and add a new dummy UPS named qnapups that points back to your real UPS. For example, my ups.conf ends with:

[cp1500]
    driver = usbhid-ups
    port = auto
    desc = "CyberPower CP1500PFCLCDa"
    vendorid = 0704
    productid = 0601

[qnapups]
    driver = dummy-ups
    port = cp1500@myNutServerIpAddress
    desc = "Proxy UPS for QNAP NAS"

Restart the nut-server (sudo service nut-server restart) and voila your QNAP can then see the UPS:

Ubiquiti UISP

Posted on by

Ubiqiuti is a well known manufacturer of pro-sumer/small-business networking gear. They make two main lines of equipment: UniFi and UISP. The former aims for centralized control only (you can only manage devices through their management software); the latter is more traditional and allows for both direct device management (via command line and web interface) as well as centralized management through their free network management software UNMS. I’m old fashioned so I use the latter.

I use three primary types of gear: an EdgeRouter-X serves as the primary gateway into my network, a variety of EdgeMAX intelligent (layer 2) switches form the wired backbone of the network, and AirCubes provide wireless access.

The EdgeRouter is a particularly remarkable value; at $59, it provides a very full-featured comprehensive router + 4-port GbE switch. With hardware acceleration enabled, it delivers roughly 107MB/s (i.e. it routes at full gigabit speeds) while providing extensive support for features like VLAN, ipsec, dhcp management, NAT routing, etc. It has many more advanced features that I don’t presently use.

The EdgeMax switches work well and although they cost more than some other layer 2 switches, they work well and are fully supported by UNMS. One of the main advantages of this is managing firmware updates which is handled for all of the UI devices from the UNMS management console.

The UNMS network management package can be run locally (that’s how I use it) or, if you have at least 10 Ubiquiti devices, can be run on Ubiquiti’s cloud NMS. Although I have more than 10 Ubiquiti devices, I run UNMS locally (on a proxmox VM) for better security/control.