Unless you’ve been living under a rock, you will know there have been a load of software patches and updates released recently. As a result I’ve been constantly updating my Vagrant and Docker builds as each one has dropped. With the release of ORDS 21.1, the main push for this quarter is done.
This is just a heads-up of what’s been happening.
Packer : My Packer builds of OL7 and OL8 Vagrant boxes have been updated and pushed to Vagrant Cloud. This ended up happening twice due to the quick release of VirtualBox 6.1.22 a few days after 6.1.20.
Vagrant : All relevant builds now have the latest Java 11, Tomcat 9, ORDS 12.1 and SQLcl 21.1 versions. Where necessary the database patches are included. I mostly try to do builds with stock releases, so people without a support contract can still use them, but some things require the patches to function properly. If you follow the blog you will already know the Oracle Enterprise Manager Cloud Control 13.5 builds have now been included.
Docker/Containers : Similar to Vagrant, all relevant builds now have the latest Java 11, Tomcat 9, ORDS 12.1 and SQLcl 21.1 versions. Database patches are updated where necessary.
There is still some stuff on the horizon though. With the new version of APEX dropping on the apex.oracle.com, I expect a new on-prem release soon (see update). There is also the on-prem release of Oracle database 21c, which I’m hoping drops soon. Once it does I will be adding those builds…
Update: APEX 21.1 dropped today (12-May-2021) just after publishing this post. It’s been added to all the builds now. 🙂
The January Oracle quarterly patches were released yesterday, which prompted me to do some new builds.
We got Oracle REST Data Services (ORDS) 20.4 and SQLcl 20.4, which I use in a number of my Vagrant and Docker builds, so I updated them and ran some builds.
The Vagrant database builds, which include ORDS, can be found here.
The Docker ORDS builds can be found here.
I also updated Tomcat to 9.0.41 and OpenJDK to 11.0.10_9 from AdoptOpenJDK.
Once I finished those I decided to try out the Oracle database 19c (19.10) OJVM+DB combo patch on a single instance build. That went fine. You can see that build here.
Since that went OK, I figured it was worth trying to update my OL8 19c RAC build with the 19.10 OJVM+GI combo patch. That also went fine. You can see that build there.
I wasn’t really expecting to cover so much ground so quickly, but that’s the great thing about automation. 🙂
Tomorrow I’ve got to start putting together all the patch scripts for work. It’s always a bit tedious because I have to deal with a lot more products and variations, and I have to make sure I don’t screw up. Happy patching… 🙂
PS. If you are interesting in ORDS, SQLcl, Vagrant or Docker, these might help.
I can understand Oracle charging for support and product upgrades, like 9i to 10g. I can even see the point of charging for releases upgrades, like 10gR1 to 10gR2. What I think is a little cheeky is to charge people for regular patchsets.
This line of thought came about because of a post on the Dizwell Forum, where someone mentioned they were running a production system without support. This person is working with 188.8.131.52.0 because they don’t have access to 184.108.40.206.0 as a result of not having a support and updates contract. Personally, I think this is more than a little mean of Oracle. Afterall, these patchsets are only fixing bugs in the product that was bought in good faith. Even Microsoft don’t charge for basic Windows Updates, only for version upgrades.
Personally, I believe patchsets on an existing product should be free to those who have a product license. Access to new releases and new product versions could still be restricted.
I just hope I’m never put in th same position as this guy!