Apparently it’s been a while since I’ve rebuilt my workstations and things have changed quite a bit with the introduction of WSL. As far as I knew the only way to cleanly isolate different dev environments was to use virtual machines which I never really care for on a laptop. As I’m finding a lot more of my stuff works on Linux seems to make sense to take advantage of WSL containers.
Apparently I have setup enough Azure App Services that use the integrated Azure Active Directory (AD) authentication, that I needed to create a script for it. I got lazy clicking through all the prompts and generating new secrets that I just whipped this up. In order to execute it the only real requirement is having Az CLI installed.
Welcome to the last part of this series on setting up NextCloud. In order to get NextCloud working, there are a few configuration settings that need to be added/changed. This will allow it to run on the App Service and use SSL with the database server.
Welcome to part 4 of the guide to get NextCloud setup. You should have all of the necessary infrastructure setup and now we should be ready to startup the App Serivce and configure NextCloud. Going to just note that since there is a minor lack of full logging, it’s going to be a little bit of a sit and wait game because NextCloud writes a bunch of files and gets a lot of stuff setup.
This installment will talk about the database we’re going to use for NextCloud. There are technically a few options available to you but given how we setup NextCloud on App Service, SQLite is definietly not an option (not that it would even be advisable anyways). Which leaves three (more like 2.5?) options: MySQLMariaDB, and PostgreSQL. Luckily for me Azure offers all three, so lucky, right?
Azure App Service Linux to me has always been very much of a black box. It does some magic behind the scenes to determine what was deployed to it and figure out how to auto startup. It’s even more of a black box when using containers, there is minal logging and (as far as I can tell) it’s not possible to ssh into a container just to check in on things.
Want to run a pretty slow instance of Nextcloud in the cloud? But for cheap-ish?
If you are like me the first thing you do after setting up a new Linux server is setup your ssh keys so you can login with them. Ubuntu has it built into the installer where it will pull it down during setup (which is what gave me the idea). This script pulls down your public keys from your Github profile and puts them on the server for you.
I started running Grafana and InfluxDB on one of my docker hosts at home but quickly realized there would be a problem when my IoT devices were all running on an internet access only network. There wasn’t a great way push data collected back onto my private network. There were a couple of options for running Grafana and InfluxDB in the cloud, each with some pros/cons but the one thing I decided was running it on Azure.
I’ve spent years messing around with different ways to deal with localization and I was never really happy with any solution. Early on in my career (like a lot of developers), I learned the to not ever ever ever ever (enough evers?) use localized datetime values to store in the database and just use UTC. Shockly I still see this all too regularly, with people asking “what do we do now that we’re moving servers from one data center to another?” Relying on the datetime of the server is just trouble waiting to happen.