by jailbird » Wed Oct 11, 2017 12:20 pm
Sorry for the delay guys. I was out of town for the day job, and then had a hell of a time getting caught up when I got back. I'm finally able to get back to work on this.
I just mention that my 2 Zero's (non-W model) are connected via Ethernet, but WiFi on the W should work. I have a spare W laying around I'll double check it on.
I'm sure NuTech will want me to reverse some of the changes I made first. I'll email them and double check. The changes off of the top of my head are:
- Things that make no sense to have installed (dmidecode, video4linux, etc) are removed
- I don't like swapping to MicroSD, so I replaced dphys-swapfile with a port of Ubuntu's zram-config package to enable ZRAM support. The idea is that idle processes get their memory compressed instead of swapped out. While compressed memory is slower then normal memory, it has to be a lot faster than writing/reading back from MicroSD!
- Since alarmdecoder doesn't normally use the system MTA always (unless you tell it to use 127.0.0.1), and since sendmail is kind of heavy, I replaced it with ssmtp, which is lighter and much easier to configure, especially for Gmail. This only affects local system mail and doesn't affect the app at all.
- I replaced OpenSSH by TinySSH as part of my effort to lower RAM usage. Since TinySSH only supports SSH keys, the image comes with TinySSH disabled and Dropbear enabled. You login, add your key, enable TinySSH and remove Dropbear. [This is one thing I'm sure NuTech will want backed out]
- Since I'm a purist, I moved ser2sock to /usr/local/etc/ser2sock and /usr/local/bin/ser2sock. I updated the alarmdecoder-webapp code for this, and I also symlinked /usr/local/etc/ser2sock -> /etc/ser2sock for people used to the old location. [I'm sure they'll want this backed out too]
- Because of the various botnets trying to bruteforce 'pi' accounts, one of the first things I do on a Raspbian install is login, create a new user for me, and remove the 'pi' user. The stock alarmdecoder images, however, have the stack run under 'pi' which makes this harder. In my image I moved the stack to run under a dedicated 'alarmdecoder' user, as to me that is cleaner and makes it more obvious which running processes are part of the stack and which are user-ran. But that's a personal thing [They'll probably want this backed out too]
- config.txt disables all things that aren't normally needed (i2c, i2s, spi, audio, camera), sets GPU RAM to minimal to free up system RAM, and has the settings to swap the UARTs on a Pi3/Zero W ready (but commented-out).
- One rare case where I added something. Under heavy load of HTTPS traffic or encrypted ser2sock traffic, it's possible to run the entropy pool behind /dev/random out, which will cause traffic to block until the pool can be built back up. I installed the 'rng-tools' package and enabled the 'rngd' service. What happens is if the entropy gets too low, rngd will feed data from the HW RNG built into the Broadcom CPU on the Pi into the kernel's PRNG. The PRNG will take that data and 'stir' it into the entropy pool, allowing it to rebuild the pool faster.
That's all off of the top of my head. I'll get with support to see what they want changed.
.
