I actually just had a chance to run through the process and noticed the following issue. Seems we’re using an outdated way of installing JDK8, so I’m going to need to update the setup script.
[stderr]
Warning: apt-key output should not be parsed (stdout is not a terminal)
gpg: key B1998361219BD9C9: public key "Azul Systems, Inc. (Package signing key.) <pki-signing@azulsystems.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
E: Unable to locate package zulu-8
"
I also noticed that we’re using an outdated URL for the WAR file so I’ll fix that as well.
I’m continuing to run into issues trying to get the vm-setup script to install Java 8. I’ll keep playing around with it tomorrow but just wanted to let you know that some progress has been made.
IMPORTANT: FYI, this is going to deploy a development version of OpenBoxes. This version is not ready for production. If you’re looking for a production-ready version I’d recommend looking at the DigitalOcean deployment option.
Here’s the error if you’re interested.
Enable failed: failed to execute command: command terminated with exit status=100
[stdout]
amd64 Packages [2717 kB]
Get:7 http://azure.archive.ubuntu.com/ubuntu bionic-security/main Translation-en [467 kB]
Get:8 http://azure.archive.ubuntu.com/ubuntu bionic-security/restricted amd64 Packages [1317 kB]
Get:9 http://azure.archive.ubuntu.com/ubuntu bionic-security/restricted Translation-en [182 kB]
Get:10 http://azure.archive.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [1303 kB]
Get:11 http://azure.archive.ubuntu.com/ubuntu bionic-security/universe Translation-en [308 kB]
Get:12 http://azure.archive.ubuntu.com/ubuntu bionic-security/multiverse amd64 Packages [19.8 kB]
Get:13 http://azure.archive.ubuntu.com/ubuntu bionic-security/multiverse Translation-en [3928 B]
Get:14 https://repos.azul.com/zulu/deb stable/main amd64 Packages [242 kB]
Get:15 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:16 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [83.3 kB]
Get:17 http://archive.canonical.com/ubuntu bionic/partner Sources [1280 B]
Get:18 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages [2717 kB]
Get:19 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages [1019 kB]
Get:20 http://archive.ubuntu.com/ubuntu bionic/main Translation-en [516 kB]
Get:21 http://archive.ubuntu.com/ubuntu bionic/restricted amd64 Packages [9184 B]
Get:22 http://archive.ubuntu.com/ubuntu bionic/restricted Translation-en [3584 B]
Get:23 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages [8570 kB]
Get:24 http://security.ubuntu.com/ubuntu bionic-security/main Translation-en [467 kB]
Get:25 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 Packages [1317 kB]
Get:26 http://security.ubuntu.com/ubuntu bionic-security/restricted Translation-en [182 kB]
Get:27 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 Packages [1303 kB]
Get:28 http://security.ubuntu.com/ubuntu bionic-security/universe Translation-en [308 kB]
Get:29 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 Packages [19.8 kB]
Get:30 http://security.ubuntu.com/ubuntu bionic-security/multiverse Translation-en [3928 B]
Get:31 http://archive.ubuntu.com/ubuntu bionic/universe Translation-en [4941 kB]
Get:32 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [151 kB]
Get:33 http://archive.ubuntu.com/ubuntu bionic/multiverse Translation-en [108 kB]
Get:34 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages [3045 kB]
Get:35 http://archive.ubuntu.com/ubuntu bionic-updates/main Translation-en [553 kB]
Get:36 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 Packages [1347 kB]
Get:37 http://archive.ubuntu.com/ubuntu bionic-updates/restricted Translation-en [187 kB]
Get:38 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages [1914 kB]
Get:39 http://archive.ubuntu.com/ubuntu bionic-updates/universe Translation-en [420 kB]
Get:40 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 Packages [25.6 kB]
Get:41 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse Translation-en [6088 B]
Get:42 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages [53.3 kB]
Get:43 http://archive.ubuntu.com/ubuntu bionic-backports/main Translation-en [14.6 kB]
Get:44 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 Packages [18.2 kB]
Get:45 http://archive.ubuntu.com/ubuntu bionic-backports/universe Translation-en [8668 B]
Fetched 36.4 MB in 7s (5578 kB/s)
Reading package lists...
Building dependency tree...
Reading state information...
7 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
zulu-8 : Depends: zulu8 but it is not going to be installed
[stderr]
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
E: Unable to correct problems, you have held broken packages.
As I explained you already, I was trying to deploy the Openboxes to Azure portal. However, I was not able to find a solution with the DigitalOcean deployment yet…
Unfortunately, there’s a bug in the application that’s preventing it from starting. Hypotehtically, you could use the Deploy to Azure feature to create all of the Azure resources needed to run OpenBoxes and then just wait for us to fix the bug. But that might be a waste of money, so I’d recommend waiting.
I have created a bug ticket for that issue and will try to work on it next week. OBGM-626.pdf (95.3 KB)
As mentioned in an earlier reply, the Deploy to Azure feature will deploy a pre-release version (v0.9.0-SNAPSHOT) of OpenBoxes to Azure. This is a very buggy version of the application, so it is not recommended for production use. We are hoping to release v0.9.0 in the Autumn.
The Deploy to DigitalOcean feature will install a production-ready version (v0.8.20-hotfix1) of the application to DigitalOcean.
Here’s the Deploy to DigitalOcean button.
… along with a link with complete instructions on how to deploy OpenBoxes to a DigitalOcean droplet.
@jmiranda Thanks for your help. However, we need to deploy the Openboxes to Azure, but not DigitalOcean.
By the way, why can’t we use the production-ready version (v0.8.20-hotfix1) for Azure?
Hypothetically, you could. Someone with devops expertise just needs to modify a few of the dependencies in the script that gets executed on the Azure VM in order to create a production environment that is suitable for the v0.8.x release. And then someone else needs to test the heck out of the feature.
The original author of the Deploy to Azure button is no longer working on OpenBoxes so we don’t have anyone (other than myself) to support this feature. I can certainly investigate when I get a chance but I can’t promise anything at the moment given my capacity as a paid consultant.
A Little Backstory
The Deploy to Azure feature was part of a larger “Shelf Readiness” project funded by Digital Square in 2020.
The hope was that once the Deploy to Azure feature was working, we’d also be close to releasing OpenBoxes v0.9.0 (which would include a large migration from Grails 1 to Grails 3). I wanted to future-proof the Azure deployment process so we didn’t have to migrate the Deploy to Azure feature once we were done with v0.9.0.
Unfortunately, we didn’t anticipate how long it would take to get the Grails 3 migration funded. After a three-year hiatus, we finally restarted the project in May 2023 and we are hoping to be done in the Fall 2023.
As with everything open-source we either have to find funding for the work we want to do or find someone willing to work for free. I do a little of both, but priority usually goes to the work being funded.
By the way, if you just want to get the latest production-ready version (it looks like the latest unpublished version is v0.8.22-hotfix2) deployed to Azure I can do that without the Deploy to Azure feature.
Just schedule a call with me and we can work through the details.
And that goes for anyone looking to deploy OpenBoxes to their favorite platform. Until we can develop and support automated deployments to any of the flavor of the day IaaS platforms (e.g. AWS, Azure, DigitalOcean, GCP, Linode, RimuHosting, Vultr, etc) we are available to perform these deployments manually (for a nominal fee). Just schedule a call with me to discuss the details.
[unpaid-advertisement]
It just occurred to me that while I praise them daily viva voce, I don’t think I’ve ever mentioned RimuHosting on this website before. So let me take a moment to say that Rimu is by far my favorite hosting provider. And there’s no competition. I started using them in 2007 on the recommendation of a client of mine and I would 1000% recommend Rimu over any other hosting provider if you’re in the market for virtual machines or dedicated servers. The support alone is worth every penny and their VPSs are usually cheaper than any other provider.
but the underlying bug has not been completely fixed yet.
And it probably won’t be fixed for the next few weeks as I have been (and will continue to be) on leave for most of August. I have limited availability this week, then I will be traveling again next week and won’t be back until the school year starts for the kids on September 5th.
While I have limited availability this week, that means I’ll only be working on paid projects.
I can’t promise any miracles but as I stated in a previous comment, if you don’t mind paying for the time to do the installation, then we can set up an OpenBoxes production environment in your Azure account with just a few hours of work.
If it’s urgent, I can try to free up some time this week to make that happen. If not, then I’ll let you know when/if I get it fixed after I return in September.
Hey Justin, thanks for getting back to me. Can we use the Azure CLI to deploy the Openboxes to Azure?
If so, just let me know how to do briefly. And also, we’re willing to pay you for the installation. Thanks so much!
Can we use the Azure CLI to deploy the Openboxes to Azure?
I have not personally used Azure CLI much, but I assume you could manually convert the ARM template JSON file (that is used by Deploy to Azure process) to az CLI commands.
Here’s a link to the ARM template we use.
Fwiw, I just decompiled the ARM JSON file to bicep (see attachment below) in case that’s useful.
Once the resources are provisioned, we can manually run through the setup script that installs OpenBoxes and its dependencies.
NOTE: I would hold off on this until we discuss your intentions (see questions in the next section) as you’ll need to modify the installation process depending on whether you want the latest stable version or a pre-release version). The script above installs the buggy pre-release version.
And also, we’re willing to pay you for the installation. Thanks so much!
Are you ok with the pre-release version (0.9.x) or do you want a stable production-ready release (0.8.22)? The pre-release (0.9.x) is going through a thorough testing procedure right now, so it’s buggy but more stable. It is nearing alpha but probably won’t be production-ready until December.
If you’re ok with the stable release, I think the best way forward would be to go through Steps 1 through 4 to create the infrastructure components needed. And then you just need to add my public key to the VM so I can jump on the server to deploy the application and fix any deployment issues.