In my home environment, I was already using letsencrypt certs on my local webserver. I also have a QNAP NAS device that I wanted to use the cert on. Since letsencrypt certs have such a short valid period, it would be highly inconvenient to update the certs via the web UI by hand every time they expired.
My webserver is exposed to the internet, which makes it easier to just group in the NAS’s domain name with the certs that get renewed from the webserver due to the way letsencrypt renewals work.
After a bit of research, I found a way to remotely update the certs on the QNAP device via scp and ssh. The script below is what I came up with for my own use. With minor modifications, I hope that others may find it useful as well. In order to use it, you need to already have the server it runs on (not your NAS device itself) setup for letsencrypt and have already registered a cert. It will not update the NAS by default if the cert isn’t within 48 hours of expiration. You can override this by passing the –force option. It still won’t renew the cert, but it will restart the local httpd and update the NAS device’s cert. You should only normally need to do this the first time. I symlinked it into /etc/cron.daily so that it is completely hands off.
Sometimes having programming skills comes in very handy, particularly when you’re trying to be as lazy as you can possibly be.
I have a MythTV DVR system setup in my apartment. One of the features of this system is that any of the Linux systems (Which is all 5 of my home computers) on my LAN can connect to the backend server and be used to watch live TV or shows that I have recorded on the backend.
In my home office, I’ve got two PC’s setup. This allows me to use one as a TV while I’m working on the other.
This setup suits my needs nicely, but there was one minor annoyance. I had to move from computer to computer any time I wanted to adjust the volume, change channels, skip commercials, etc.
Most people would just accept it as is (well, most people wouldn’t have built their own DVR either, heh), but being a geek it was time to flex some creative mental muscle.
Continue reading “I just love being a geek sometimes”
One of my co-workers came to me today for some help with a Windows laptop. He had just nuked and paved (aka reinstalled) the OS on it, and was having a horrible time finding the correct drivers for several devices on the system. After using a Fedora live USB stick to identify what the hardware actually was (which I couldn’t readily find out in Windows), I finally managed to get everything working except for the audio. This wasn’t some obscure audio chipset, it was just one of the normal Intel ones based on the AC97 codec. I eventually got sick of banging my head against it and handed it off to one of our more Windows fluent people who finally managed to get it working.
I had completely forgotten how much of a chore it could be to get everything working on a Windows box after the OS install. I’ve been spoiled by recent versions of the Linux desktop distros (Fedora in particular). As long as your hardware isn’t extremely bleeding edge or exotic it usually “Just Works” under Linux these days. The only thing I’ve had a hard time with at all in the last few years was that after the PulseAudio transition it was hard to get sound working in apps running under wine (which allows you to run Windows apps under Linux), though even this has been sorted out now. Most native apps never had any problems at all.
Continue reading “Windows, Linux, and false perceptions”