week of 10 september

10 Sep 2018

10 sep

I FIGURED IT OUT, Y’ALL.

Turns out, I needed to use ENTRYPOINT [ "npm", "start" ] instead of CMD [ "npm", "start" ]. Now when I build the image and run it, it creates a new board, initializes a REPL, calibrates the sensor, and starts counting without closing the board. It’s a true miracle.

So tomorrow:

:tada::tada::tada:

11 sep

After thinking about my next steps, I decided to try out environment variables before pushing all of the updates to git/docker hub.

Environment variables will help keep this project as automated as possible. The LibInsight API uses different tokens for each stream of data (in our case, each counter or each door), so we need a way to update that auth token for each device without opening individual files. After some research (and talking with Scott), environment variables are the best option because they can be set in the Dockerfile but then overwritten via run command.

Unfortunately, I’ve hit yet another brick wall. I set up my ENV variable in the Dockerfile, but for whatever reason, my app won’t read it. Even when I overwrite it in the run command:

docker run -it -e WORLD="world" --cap-add=ALL --privileged -v /lib/modules:/lib/modules caryl/counter

My node app has a line with the process.env.WORLD variable in a log:

console.log('Hello ' + process.env.WORLD);

But when I run the program, I get Hello undefined. Frustrating. Even when I go in through exec /bin/bash, I can’t get it to respond with hello world. I tried setting const WORLD = process.env.WORLD; and having the log read from ${WORLD} variable, but no dice. I tried to get the REPL to tell me what WORLD was set to, but it returned WORLD is not defined. :sob::sleepy:

I’m thinking maybe I’ll take this thing home and see if Scott can figure it out. I’m out of my depth here. I’ve googled ALL THE THINGS but keep getting the same stack overflows. I watched youtube videos and it looks like I’m doing the exact same thing as them, so it might be something I just can’t see. sigh…

Update! Took this thing home and worked with Scott for a bit. We troubleshot until we realized the variable just needed to be set higher in the javascript doc… womp womp. But yay!

12 sep

Now that I’ve got the environment variables working, I tested it on the libinsight API, and everything worked! :tada:

So now… do all the updates? Or move to writing the bash script?

Went back and read my log. Looks like I wanted to fix the board closing (did it!) and figure out unattended upgrades/bash script before moving on to pushing/flashing anything else. Here goes.

unattended upgrades

Reading through the log, I definitely tweaked some stuff not mentioned in the 5 basic security tips article, but I couldn’t figure out how I knew what to edit. I found a stack overflow about it, so I can at least confirm that what I did was legit: Configuring unattended upgrades on Raspbian Stretch. Thing is, I’m using Stretch on the pi but Jessie in the docker container. I don’t think I need to worry about the docker container since it’s isolated. BUT good news is that the curly brace varibles in this answer mean it will work with any distro. So win-win.

Now to figure out how to email me when upgrades happen… I know there’s a line in the config file, but it’s set to Mail:'root', which I probably don’t want since I deleted the root user. Hmmm…

13 sep

Updated the /etc/crontab line for cron.daily to run at hour 23 instaed of hour 6. (This file is only writable by root - which you may recall is a user I deleted - so make sure you sudo vim /etc/crontab)

Decided to follow the rest of the manual/docs on the debian wiki for unattended-upgrades. I was wondering how unattneded-upgrades is called, well it turns out you have to activate it. Also turns out the file it says to add lines to/create were already in place when I opened them, so done and done! I made the changes to the apt-listchanges.conf file, though. Definitely wondering about the email address being set to root, so I changed that to my ivy tech email.

Next up: making sure I have an email situation set up. I decided to follow the instructions in How to setup automatic security updates on ubuntu 16.04 and install sendmail. … This did not work out. So now I’m installing heirloom-mailx and following some instructions from sending email via gmail in linux. Had to set up a dedicated gmail account. :unamused: Went with ivytechpeoplecounter@gmail.com. Followed all instructions on the blog post but had to include the -r flag with the new gmail address. Checked the sent folder, and there was my email! :tada:

Now… how to make sure my mail is going through this setup when the pi runs unattended-upgrades?

Okay, listen. I don’t know if this is set up correctly AT ALL. I think I need to move on, because I can’t figure it out right now and my brain is all twisted around this. I need to step away and leave my obsessive googling/stack overflowing for another day. For future reference, my main confusion is that heirloom-mailx won’t run using the mailx command. After installing bsd-mailx, the mailx command is working. But how does this all relate to the ~/.mailrc file? What does the sendmail package have to do with it? How do any of these connect with the bit from the unattended-upgrades config file /50unattended-upgrades.conf? And how does any of this mail stuff relate to the apt-listchanges package that the debian wiki (above) suggested installing after unattended-upgrades?

I couldn’t help myself, so I googled some more. After I RTFM via man mailx I learned I have BSD installed as my primary mailx pacakge, so that should help something when I decide to come back to this. Maybe find some youtubes?

Last thing: