Category: Uncategorized

After a coworker mentioned Vixen Lights, I looked into it and decided it would be a fun hobby to program a lights display. I was also in dismay after looking at the cost of christmas lights which appeared to be expensive, even when they were on sale, and they couldn’t be programmed. So when I found out that LED strips of fully addressable RGB lights on amazon cost around $25 per 5m, I decided the cost was worth being able to program the lights.

I’m using Vixen on my PC to set up the light sequences. I initially used this to control the teensy directly via USB but decided I didn’t want a full sized computer dedicated to feeding the teensy a sequence. Therefore, I set up a raspberry pi zero wireless (rpi0w) with Falcon Player (FPP) in order to control the teensy via usb. I still use my desktop to run Vixen and to create the sequence. When I’m finished, I export it as an FPP sequence. Then I run the sequence inside FPP on the rpi0w.

There is also the option to have Vixen feed to FPP directly, but then I would be stuck running the software on my desktop while the lights were operating. The prior method allows me to limit the use of the desktop to be just for designing the sequences, and the rpi0w is responsible for feeding sequencing data to the teensy.

The setup

FPP on a rpi0w with OTG cable connecting via USB to

Teensy with an Octo shield connected to

Ethernet cable split (bought separately) and soldered to JST connectors (included with led strips) connected to

The led strips. These are powered by 5v power supplies.

The setup of FPP was super easy on an rpi0w. I went with the WiFi tethering option because it requires no cables to work and I didn’t have to plug the rpi0w into my desktop. Flash the FPP image onto the uSD card and then power on the rpi0w. After its powered on, connect to the FPP wifi network and perform initial setup.

https://falconchristmas.com/forum/index.php/board,8.0.html

In addition to setting up the rpi0w with FPP, I had to configure the teensy to use it. Luckily someone else did all the hard work and created an FPP to teensy sketch.

I had to change the value in the teensy script for MAX_PIXELS_PER_STRIP to be 150. I also added a function that turns the LEDs all blue for 5 seconds upon startup.

https://github.com/tonsit/fpp-to-teenserial-ws2813/blob/master/fpp-to-teensy-serial/fpp-to-teensy-serial.ino

Per docs, 150 * 8 * 3 gives me total number of channels: 3600.

I had to set up FPP channel for Other – Generic Serial for this.

Active – Generic Serial – Start channel: 1, Channel Count: 3600 Port: ttyACM0, Speed: 9600, Headers – Start: <>

https://user-images.githubusercontent.com/25712519/98431018-e2075980-207f-11eb-9595-4b39ca62f515.PNG

When I finished with the proof of concept, I moved it downstairs and plugged it in. When I ran the sequence on FPP the lights didn’t respond. I eventually discovered that the adapter that was included with the UPS had burnt out. I have reached out to the company for assistance. I think using two strands together drew too much amperage for the connector. Most connectors online list 5A max. I do not know why they would provide a 5A connector with a 10A power supply. I’ve resorted to electrical tape to get the power supply connected to the lights.

Parts

Software

https://falconchristmas.com/forum/index.php/board,8.0.html

https://github.com/ShadowLight8/fpp-to-teensy-serial-ws2813/blob/master/fpp-to-teensy-serial/fpp-to-teensy-serial.ino

If you’re using LetsEncrypt SSL certs, the following command will create the required file:

cat /etc/letsencrypt/live/example.org/{privkey,cert,chain}.pem > znc.pem

ALL CREDIT TO: https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

However, to save space and explanations.

issue this command in your command prompt:

cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096

Then edit the config for each nginx site:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_dhparam /etc/ssl/certs/dhparam.pem;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
add_header X-Frame-Options "DENY";

 

FULL CREDIT TO: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-14-04

Copied here in case that site ever goes down, I use this for my own reference.

Let’s Encrypt certificates are valid for 90 days, but it’s recommended that you renew the certificates every 60 days to allow a margin of error. At the time of this writing, automatic renewal is still not available as a feature of the client itself, but you can manually renew your certificates by running the Let’s Encrypt client again.

A practical way to ensure your certificates won’t get outdated is to create a cron job that will automatically handle the renewal process for you. In order to avoid the interactive, menu-driven process that we used earlier, we will use different parameters when calling the Let’s Encrypt client in the cron job.

We will use Webroot plugin, instead of the Standalone plugin used earlier, because it allows your server to validate your domain without stopping your web server. The Webroot plugin adds a hidden file to your web server’s document root, which the Let’s Encrypt CA can read to verify your domain.

How To Use the Webroot Plugin

The Webroot plugin works by placing a special file in the ./well-known directory within your document root, which can be opened (through your web server) by the Let’s Encrypt service for validation. Depending on your configuration, you may need to explicitly allow access to the /.well-known directory. To ensure that the directory is accessible to Let’s Encrypt for validation, let’s make a quick change to our Nginx configuration. Open it for editing:

• sudo nano /etc/nginx/sites-enabled/default

Under the ssl server block, add this location block:

        location ~ /.well-known {
                allow all;
        }

You will also want look up what your document root is set to by searching for the root directive, as the path is required to use the Webroot plugin. If you’re using the default configuration file, the root will be/usr/share/nginx/html.

Save and exit.

Now that we know our webroot-path, we can use the Webroot plugin to renew our certificate with this commands. Here, we are also specifying our domain names with the -d option. Note that you should replace the highlighted parts with the appropriate webroot path and domain names:

• cd /opt/letsencrypt
• ./letsencrypt-auto certonly -a webroot –agree-tos –renew-by-default –webroot-path=/usr/share/nginx/html -d example.com -d www.example.com

Once that succeeds, you will need to reload your Nginx service to use the renewed certificate:

• sudo service nginx reload

Now that we know the commands that we need to renew our certificate, we can automate this process using scripts and a cron job.

Create a Let’s Encrypt Configuration File

Before moving on, let’s simplify our renewal process by creating a Let’s Encrypt configuration file at/usr/local/etc/le-renew-webroot.ini.

• sudo cp /opt/letsencrypt/examples/cli.ini /usr/local/etc/le-renew-webroot.ini

Now open the file for editing;

• sudo nano /usr/local/etc/le-renew-webroot.ini

Next, uncomment the email, domains, and webroot-path lines, and update them with your own information. When you are done, the file (with comments removed) should look something like this:

rsa-key-size = 4096

email = [email protected]

domains = example.com, www.example.com

webroot-path = /usr/share/nginx/html

Now, instead of specifying the webroot path and domain names in the command, we can use the Let’s Encrypt configuration file to fill in the blanks. Assuming your configuration file is correct, this command can be used to renew your certificate:

cd /opt/letsencrypt
./letsencrypt-auto certonly -a webroot --renew-by-default --config /usr/local/etc/le-renew-webroot.ini

Now let’s create a script that we can use to renew our certificate.

Create a Renewal Script

To automate the renewal process, we will use a shell script that will verify the certificate expiration date for the provided domain and request a renewal when the expiration is less than 30 days away. This script will be scheduled to run once a week. This way, even if a cron job fails, there’s a 30-day window to try again every week.

First, download the script and make it executable. Feel free to review the contents of the script before downloading it.

• sudo curl -L -o /usr/local/sbin/le-renew-webroot https://gist.githubusercontent.com/thisismitch/e1b603165523df66d5cc/raw/fbffbf358e96110d5566f13677d9bd5f4f65794c/le-renew-webroot
• sudo chmod +x /usr/local/sbin/le-renew-webroot

The le-renew-webroot script takes as argument the domain name whose certificate you want to check for renewal. When the renewal is not yet necessary, it will simply output how many days are left until the given certificate expiration.

Note: The script will not run if the /usr/local/etc/le-renew-webroot.ini file does not exist. Also, be sure that the first domain that is specified in the configuration file is the same as the first domain you specified when you originally created the certificate.

If you run the script now, you will be able to see how many days are left for this certificate to expire:

• sudo le-renew-webroot

Checking expiration date for example.com...
The certificate is up to date, no need for renewal (89 days left).

Next, we will edit the crontab to create a new job that will run this command every week. To edit the crontab for the root user, run:

• sudo crontab -e

Include the following content, all in one line:

30 2 * * 1 /usr/local/sbin/le-renew-webroot >> /var/log/le-renewal.log

Save and exit. This will create a new cron job that will execute the le-renew-webroot command every Monday at 2:30 am. The output produced by the command will be piped to a log file located at/var/log/le-renewal.log.

Conclusion

That’s it! Your web server is now using a free Let’s Encrypt TLS/SSL certificate to securely serve HTTPS content.

FULL CREDIT TO: https://gablaxian.com/blog/installing-letsencrypt

Copied here in case that site ever goes down, I use this for my own reference.

 

At the moment, Letsencrypt has an auto installer for Apache only. I actually have no idea what that does, as the other option is to create the certificate files and link to them in your site’s conf file manually, which is all I’ve ever done anyway. I don’t think I’d want anything doing that step for me. But, I digress.

I’m assuming that you’ve installed git and nginx, and both as packages with apt-get.

You may also need to use the sudo command if you are not logged in as root.

Install Letsencrypt

There is no letsencrypt package for Ubuntu yet, so we install via git

cd ~
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Stop nginx. I had issues when I didn’t, so I recommend it.

service nginx stop

Generate the certificates. This command skips the horrific installer interface. Add -d for each domain name the site uses. Usually it’s just the one domain name as we, by default, redirect from www to non-www anyway.

./letsencrypt-auto certonly --standalone --email [email protected] -d example.com -d www.example.com

This puts the certificates, and other related files, in

/etc/letsencrypt/live/[example.com]

The two we need are fullchain.pem and privkey.pem.

In the site’s .conf file, in the server directive, add the following:

listen [::]:80;
listen 80;

listen 443 ssl;

ssl_certificate /etc/letsencrypt/live/[example.com]/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/[example.com]/privkey.pem;

This will allow the site to be accessed from both http and https. To make the site https only, you need a preceding server directive to redirect all domain names to https, like:

server {
    listen [::]:80;
    listen 80;

    # listen on the www and non-www host
    server_name www.[example.com] [example.com];

    # and redirect to the https host (declared below)
    return 301 https://[example.com]$request_uri;
}

Then the second server needs only:

listen [::]:443 ssl;
listen 443 ssl;

ssl_certificate /etc/letsencrypt/live/[example.com]/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/[example.com]/privkey.pem;

Start that server back up

service nginx start

Aaaaand done.