Sunday, August 25, 2019

Add HTTPS to FreeNAS Nextcloud plugin

Using Let's Encrypt and certbot with auto-renewal.

I installed the Nextcloud plugin some time ago in FreeNAS and found it useful, but it had no support for HTTPS at all. Initially I only used it internally so that was okay-ish, but wanted to roam, and even internally certain integrations just won't work at all without it (WebDAV, see my previous post). So I had a working install and didn't want to have to redo it all, I just wanted to add HTTPS. Of course, it is rare to find a straightforward, and complete answer on the Internet to a specific circumstance, even one that seems like it should be common.

If I wasn't time-poor, or was starting from scratch and was aware of this limitation I'd probably have used this automation script or this guide to hardening instead, or even better, a Docker container with configuration as code, but for that to work I'd have to get Docker working again...

My instructions are partly from https://www.ixsystems.com/community/threads/nextcloud-lets-encrypt-nginx.72643/ but I did NOT allow SSH direct to the nextcloud host, I go through the FreeNAS host using jexec. You could also use the shell in the UI but it's painful.

Prerequisites:
  • A domain name which you can point to your FreeNAS host, perhaps with a subdomain using a CNAME record. 
  • Control over port forwarding to FreeNAS - you'll need to enable port 80 for certbot to work (though I am unsure if it needs to be to the Nextcloud instance, actually) 
  • Basic command line knowledge including how to connect to the specific jail 

Brief steps:
  • Connect to your nextcloud host command line - if you don't know how to do that, this guide is too brief for you, sorry :) 
  • Allow installing packages: vi /usr/local/etc/pkg/repos/FreeBSD.conf and change no to yes. (Recommended to change it back later)
  • You may want to install a more preferable editor than vi at this point. 
  • Install certbot: pkg install py27-certbot
  • certbot certonly --webroot -w /usr/local/www/nextcloud -d your-domain-name.com
  • certbot renew --dry-run
  • crontab -e and add this to regularly check and renew if necessary: 
    • 0 0,12 * * * /usr/local/bin/python2.7 -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/certbot renew --quiet
  • Now you have a certificate and all the automation to keep it up to date!
  • Next we add HTTPS listener and redirect from HTTP - this was missing from other instructions I saw. 
  • edit /usr/local/etc/nginx/conf.d/nextcloud.conf
  • There will just be a server entry for port 80. Break it up like this:
    • server {
    •   listen 80;
    •   server_name _;

    •   return 301 https://$host$request_uri;
    • }

    • server {
    •   listen 443 ssl;
    •   ssl on;
    •   ssl_certificate "/usr/local/etc/letsencrypt/live/your-domain-name/fullchain.pem";
    •   ssl_certificate_key "/usr/local/etc/letsencrypt/live/your-domain-name/privkey.pem";

    •   server_name _;

  • service nginx configtest
  • If the above is ok: service nginx reload
  • https://scan.nextcloud.com/ to check your security 
  • Turn off the package repos again to reduce attack surface. 
It's probably a good idea to upgrade Nextcloud while you're there:

$ pkg update
$ pkg upgrade nextcloud-php71
$ cd /usr/local/www/nextcloud
$ su -m www -c "php ./occ upgrade"


Friday, April 19, 2019

Restricted SMB Share writing files as specific user/group

I have a FreeNAS server and had a need to make SMB (Windows) shares which would write files as a particular user on the server, but be available to only certain unix users. 

Specifically, I installed Nextcloud and wanted to be able to access the files and upload in bulk instead of via the web interface, or the integrated Explorer client which is convenient but only works if you want to synchronise files locally (ie keep a copy) and are happy to move everything there. 

Nextcloud writes files as user/group www/www so I had to have the SMB share write files as that user, but be accessible to my user or group. I realise that isn't the best security or auditing model, and I might have achieved the same with a complex group config between FreeNAS and the jail, but it seemed unnecessary for my home server. 

I also created the group nextcloud_files to define the FreeNAS users that could access this share. 

In short, these advanced auxiliary SMB settings worked:
  • valid users = @nextcloud_files
  • force user = www
  • force group = www
I was able to mount the share as the Windows user and copy data into it, and it appeared as the www user. 

Additionally, I tried to set it so that the shares would only be visible to the users who could access them, with either or both of these options:

  • hide unreadable = yes
  • access based share enum = Yes
But that doesn't seem to work and probably requires user-level settings on FreeNAS which is not available in the web interface, and I don't like invisible manual configuration. 

Nextcloud note: it's not a good idea to side-load files into the storage, although they do appear in the web frontend, it hasn't attributed disk usage properly and I'm not sure if this means certain metadata won't be tracked. There just doesn't seem to be a nice way to pre-load it with GBs of photos.

To update the database, there is a server-side command to re-scan all the files, ie: 


root@nextcloud:/ # sudo -u www php /usr/local/www/nextcloud/occ files:scan joel
The process control (PCNTL) extensions are required in case you want to interrupt long running commands - see http://php.net/manual/en/book.pcntl.php
Starting scan for user 1 out of 1 (joel)
+---------+-------+--------------+
| Folders | Files | Elapsed time |
+---------+-------+--------------+
| 305     | 21041 | 00:21:53     |
+---------+-------+--------------+

This is not ideal. 

Turns out there is also a WebDAV address you can alternatively map instead of a windows share, which would solve this problem! 


... but Windows doesn't like it, no matter whether it's internal, external, port included or not. Of course. 

UPDATE: I solved this and described it in another post

Saturday, September 30, 2017

Fix crackling sound with X-Fi on Ubuntu/Mint pulseaudio

May I never lose this link

https://guh.me/solving-creative-sound-blaster-x-fi-titanium-crackling-slash-distortion-on-linux

The trick is disabling PulseAudio’s timer-based scheduling. Fire up the terminal, then type:
su -c "nano /etc/pulse/default.pa"
Look for the line that contains load-module module-udev-detect, and append tsched=0 to it. Now it should look like this:
load-module module-udev-detect tsched=0
Save the buffer and exit the editor, then restart PulseAudio with the following commands:
pulseaudio -k
pulseaudio --start

Sunday, August 6, 2017

Run a Raspberry Pi and USB hub off one power brick

Annoyed by having to take up so many power plug spaces for supposedly low power devices? 


What's going on here?
  • Raspberry Pi needs minimum 700mA 
  • Power goes into USB hub (2A 5V DC) 
  • Hub provides Pi with power via micro-USB (white)
  • Pi's USB connects to hub for devices 
  • It works, trust me :) just don't use lots of USB devices that need power. 
Ignore the bit at the bottom with the ribbon cable; it's a Nordic radio attached to the GPIO pins for a wireless node project. 

This whole thing is then hung on the wall. Blu-tak holds the hub on the front, and the enclosure has slots on the back to slide it onto screw heads. After a while the hub very slowly slides down and then hangs from the cable; I think I'll have to add tape.

Solar power monitoring on Raspberry Pi/Linux

I've had solar panels installed since 2012 after my wife and I bought our first home. I have always been interested in monitoring our power usage as well as solar power production and trying to optimise/minimise use. It was relatively easy to get data from our Power-One Aurora 2kW photovoltaic inverter, and upload that via a Raspberry Pi (v2) to PVoutput.org.

A full day's live output after it was working again

This worked fairly well with only minor hiccups from mid-2014 through to early 2016 when the Pi started having regular issues, and eventually stopped booting altogether in August. The SD card basically just wore out, I used ddrescue to recover it with < 100 kB missing but apparently those were important bytes. I have finally gotten around to recovering it, having to reverse engineer my own setup, so I am documenting it here. I will also cover how to make it more resilient.

I stalled on monitoring the power usage for the house, but recently discovered some progress in this area, which can be a whole other post.

You will need


This guide is for my setup as follows, yours may differ:
  • Aurora PV inverters with either
    • an internal RS485 serial port connection (may void warranty? do your own research) 
    • an external USB port (larger models, probably indoor only) - though I have not used one
  • Relevant hardware to connect
    • in my case I used a long Cat 5 ethernet cable to carry the signals from the inverter
    • an RS485 to USB adapter
  • Raspberry Pi or other Linux-based host you're going to connect it to, ideally low power
    • With an 8GB+ SD card, a good one, not no-name brand
    • Ideally one that does wear-leveling, but I was unable to find any reliable info
    • With Raspbian with desktop installed, configured and updated
  • You aren't afraid to install packages and compile things
  • Posting data to PVoutput.org or wherever, but this part is all software and much easier, plus my setup also logs locally. 
If you wanted to use a Windows host, there are actually more software options for Aurora inverters such as PVBeanCounter, but I don't want to run anything 24/7 that runs Windows.

Caveats


  • The ONLY ready-to-go software I could find which supported Aurora, ran on Linux, and posted to PVoutput.org is called Aurora Monitor which:
    • hasn't been updated in years, but seems rock-solid anyway
    • is open source (GPLv3)
    • requires a desktop! Although all I wanted was to log the data, it has a GUI, so I have to run the desktop which makes this a little more complicated and inefficient :( 
    • however you don't need to connect a monitor permanently 
    • also logs its data to disk, at a rate of about 350 kB per day, so make sure you have spare space or setup log rotation. 
  • The above means you need a desktop Linux distro, I used Raspbian
  • ... and the current Raspbian with Desktop is 4.7GB so you need an 8GB SD card
  • Don't put the Pi anywhere that's hard to get to as you may occasionally need to reboot it or repair the SD card
  • RS485 (multidrop serial) is not the same as regular RS232 (single) serial. You DO need the right USB device, which basically converts it to RS232. On the plus side, if you have multiple inverters, you can daisy chain them on the same line, but I think the unit I have only supports one connection. 
    • Mine is an FTDI idVendor=0403, idProduct=6001 "FT232R USB UART" 
    • The first one I bought was the cheapest possible and didn't last long, get FTDI

Steps


Read all these instructions before you start to make sure you aren't missing or misunderstanding anything!

Connect cable to RS485 USB adapter


Here's a stock photo of the same type of adapter I have, for example search ebay for "USB To TTL RS485 Serial Adapter FTDI FT232RL". It simply has screw terminals for the wires. Keep track of which is which for Rx/Tx.
USB To TTL RS485 Serial Converter Adapter FTDI FT232RL Downloader Module TE661
For more photos of my setup look further down.

Connect to PV Inverter

WARNINGS!
  • You must have an electrician do this! 
  • This may void your warranty! 
  • Follow the manufacturer's instructions to turn off ALL power to the inverter at the meter box and then PV array! 
  • Make sure any entrances to the device are sealed up waterproof and insect-proof!
  • Leave the other end of the cable disconnected from anything and with no wires touching while you do this end! 
  • Do your own research! Don't blame me if any of this breaks or costs you money!
  • If you don't understand exactly what this is about and what all this means, just stop now! 

This photo shows the screw-terminals for the serial connection. 
  1. Run an appropriately weather shielded cable with enough wires from wherever your Pi is going to live, in through the holes in the bottom (replace or retrofit the hole cover as needed)
  2. Ensure it has proper strain relief (simple way: tie a loose knot around a small non-conductive object) so it won't pull out and has enough wire to easily reach, but not fill up the unit
  3. Wire them up, ensure any spare wires are cut off and won't touch anything
  4. The terminator switch is used for multidrop cables, should be enabled only on the last unit. I think it wasn't changed. 
  5. Close up the box
  6. Power on the unit following correct process (power off in reverse) 
  7. Connect up the other end to your RS486 to USB adapter and ensure it works (may have to fiddle around with rx vs tx, etc) - exercise left up to reader
  8. Power off again
  9. Waterproof the cable entrance
  10. Power back on

Compiling Aurora Monitor

These assume you are familiar with Raspberry Pi, Linux (Raspbian), and have that set up already.
  1. Download Aurora Monitor to the Pi and unzip it 
  2. It has binaries for 32 bit and 64 bit but you need to compile it for ARM
    1. run "sudo apt-get install build-essential libwxgtk2.8-0 libwxgtk2.8-dev"
    2. run "cd /src"
    3. run "make"
    4. wait about 15 minutes (no, really)
    5. "auroramon" binary is built, you can move it wherever you want
  3. Run desktop if you haven't already
  4. Run auroramon and ensure it works, but of course it won't have data.

Set up software

This part can only be done when the sun is out and the unit is producing power.

For more help and screenshots see http://auroramonitor.sourceforge.net/ but here is a quick rundown:
  1. Plug in your USB adapter and configure the program:
    1. Serial port to use (check "ls /dev/tty*" it's probably ttyUSB0 if there's only one) 
    2. Location (lat/long) for automatic adjustment to sunrise/sunset and azimuth
    3. Solar panel direction and angle if known (I don't)
    4. Etc etc 
  2. Click Inverter Status in the menu to ensure it's connected, you should also see some numbers in the boxes at the bottom 
  3. After a few minutes there should be some data points on the chart! 
  4. Uploading to PVoutput.org: get a free account and go to Account Settings to get your API key
  5. Wait a few minutes to see your live data appear on your chart online! 

Resiliency

  • Ensure the desktop starts on boot: run "sudo raspi-config" and go through the menus
  • Make auroramonitor start with the desktop: https://raspberrypi.stackexchange.com/a/45554/4226
  • For the SD card: optionally, reduce the root partition size a bit to leave room for remapped bad sectors (not sure if this will actually work); I left 256 MB at the end, using GParted on my PC 

After 3 years my USB adapter was getting a bit dusty, so to protect it from dust, insects or damage I put it in a plastic enclosure:

See my awesome screw-terminal wire protection?

Classy container
Due to the frosted plastic it has a cool glow!

Potential improvements

  • Back up the Pi regularly so you don't get in the same situation I did, making recovery harder
  • If you want things to be tidier, and you don't mind sacrificing your Pi and also making debugging harder, just run the Pi inside your meter box with Wifi. You will need an electrician to install a power point though. 
    • Ensure you don't expose any electronics, in Australia we have big spiders and geckos that love my meter box 
  • A dedicated Arduino with RS485 adapter and ESP8266 wifi would be cheaper, entirely sufficient and maybe even more resilient if all you want to do is send data to PVoutput.org or anywhere else 
  • Link this setup with emonCMS (openenergymonitor.org) and/or home-automation.io 
  • If all your host does is log Solar, it might as well shut down overnight, you could use a shutdown script after dark (don't just power it off!!) and an external timer to turn it off and back on before dawn. 

Wednesday, December 23, 2015

Just putting this here so I never lose it... 
Spider-man brain tumor truck nemesis FAPPO!

Sunday, August 3, 2014

Hidden trick to programming ATTiny with USBasp

Just a quick note, this might have been obvious to other more experienced users, but I thought I had bought some dead ATTiny85 chips on ebay. The first two had worked fine, and then the next three wouldn't respond. Then I got some brand new ATTiny84 chips and couldn't get any of them to work, so I knew there must be a trick.

The short answer it turns out, is that you need to short J3 on the USBasp. Mine didn't even have headers on it, so I had to solder on some pins. This makes it work for 1MHz chips, which takes 8x longer to write. Once the reprogrammable fuses are set for 8MHz you can remove this jumper and write much faster. This is most easily done by writing a program with the Arduino IDE or even just using "Burn Bootloader" which just writes an empty bootloader script and sets the fuses.

The chips should come from the factory preset to 1MHz and all the other defaults, but I guess the first two chips I tried had already been used, as I didn't need the jumper? I worried that the other chips might be dead, or had their fuses set so you couldn't write to them, and looked into devices for fixing them. I decided it was cheaper to just get more chips than such a device. So now I have a surplus!

There was no description of J3 on the USBasp silkscreen and there had been no instructions with the device. I had wondered what it did but assumed it was for special cases or to do with reflashing the device itself (as is J2).

I found this trick buried as a small note in an instructable, http://www.instructables.com/id/The-Idiots-Guide-to-Programming-AVRs-on-the-Chea/step4/Setting-up-your-not-so-micro-computer/

Hope this helps someone like me!