oracle21c-xe-vagrant: package oracle-database-xe-21c-1.0-1.x86_64 does not verify
ole-tange opened this issue · 9 comments
Describe the issue
Thanks for making these vagrant images available.
I am developing GNU sql and building support for Oracle DB. For this I need an Oracle DB to connect to and earlier Oracle-XE has been useful for that.
My installation, however, broke, so it was nice to learn of these vagrant images.
Unfortunately, I cannot get oracle21c-xe-vagrant to work.
I have tried thrice:
vagrant destroy
git pull
vagrant up
I get the following as the last output every time:
oracle21c-xe-vagrant: INSTALLER: Oracle preinstall and openssl complete
oracle21c-xe-vagrant: INSTALLER: Environment variables set
oracle21c-xe-vagrant: Last metadata expiration check: 2:21:33 ago on Tue 16 Jul 2024 04:47:04 PM +02.
oracle21c-xe-vagrant: Dependencies resolved.
oracle21c-xe-vagrant: ================================================================================
oracle21c-xe-vagrant: Package Architecture Version Repository Size
oracle21c-xe-vagrant: ================================================================================
oracle21c-xe-vagrant: Installing:
oracle21c-xe-vagrant: oracle-database-xe-21c x86_64 1.0-1 @commandline 1.9 G
oracle21c-xe-vagrant:
oracle21c-xe-vagrant: Transaction Summary
oracle21c-xe-vagrant: ================================================================================
oracle21c-xe-vagrant: Install 1 Package
oracle21c-xe-vagrant:
oracle21c-xe-vagrant: Total size: 1.9 G
oracle21c-xe-vagrant: Installed size: 5.8 G
oracle21c-xe-vagrant: Downloading Packages:
oracle21c-xe-vagrant: Running transaction check
oracle21c-xe-vagrant: Transaction check succeeded.
oracle21c-xe-vagrant: Running transaction test
oracle21c-xe-vagrant: Error: Transaction test error:
oracle21c-xe-vagrant: package oracle-database-xe-21c-1.0-1.x86_64 does not verify: Payload SHA256 digest: BAD (Expected 51f7ec54dc0d7505bce25cca34795a541f6bc965c470098ee619897ba3116e45 != aadfbb0a61a0c71525eec1ed3218b6e41fae2c8cbbac2df0c8a5f97142e4ae7f)
oracle21c-xe-vagrant:
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
Environment (please complete the following information):
- Host OS: Ubuntu 24.04
- Kernel version (for Linux host): Linux travel 6.8.0-36-generic 36-Ubuntu SMP PREEMPT_DYNAMIC Mon Jun 10 10:49:14 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
- Vagrant version: 2.3.7
- Vagrant provider:
- For VirtualBox: 7.0.16_Ubuntur162802
- Vagrant project: OracleDatabase/21.3.0-XE
Additional information
N/A
Thanks for your report.
I can't reproduce the issue here...
From your logfile above, I don't see the
oracle21c-xe-vagrant: INSTALLER: Downloading Oracle Database software
message, which probably means it uses the already downloaded package. Should that one be faulty, it will fail for any further attempts.
Can you check the signature of your DB package? I have:
$ ls -l oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm
-rw-r--r--. 1 pvanhaes pvanhaes 2339651768 Jul 17 09:55 oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm
$ sha256sum oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm
f8357b432de33478549a76557e8c5220ec243710ed86115c65b0c2bc00a848db oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm
Yes, exactly. The provisioning script won't download the database installer rpm file if it's already present in the project directory. So, if the downloaded rpm is bad, the installation will fail every time.
If you find that the sha256sum for the oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm file is wrong, then delete the file before running vagrant up again. The provisioning script will download the file again, hopefully with better results.
In your other issue, you mentioned that you frequently destroy and rebuild your Vagrant VMs. By default, the provisioning script for the OracleDatabase/21.3.0-XE project deletes the database installer after a successful installation. If you plan to rebuild the VM regularly, you probably don't want to have to download the database installer each time. This behavior is configurable.
The easiest way to prevent the provisioning script from deleting the database installer rpm after a successful installation is:
- Install the vagrant-env plugin (
vagrant plugin install vagrant-env). - Copy the
.envfile to.env.localand set the parameter called VM_KEEP_DB_INSTALLER to true in.env.local. You can do this in one step bycding to the OracleDatabase/21.3.0-XE directory and running the following command:
sed -e 's/# VM_KEEP_DB_INSTALLER=false/VM_KEEP_DB_INSTALLER=true/' .env > .env.localYou can configure other parameters in the .env.local file, too. See the README.md file for details.
$ ls -l oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm
-rw-r--r--. 1 pvanhaes pvanhaes 2339651768 Jul 17 09:55 oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm
$ sha256sum oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm
f8357b432de33478549a76557e8c5220ec243710ed86115c65b0c2bc00a848db oracle-database-xe-21c-1.0-1.ol8.x86_64.rpm
That is precisely the issue. I was not aware that this was cached over a vagrant destroy.
Maybe it would make sense to have the install script remove the file and re-try downloading if the checksum is wrong. It is hard for me to see any situation where you would like to keep a file with a wrong checksum. I think it is more likely you are going to end up frustrated (like me) and trying 3 times - only to get the same result :)
Maybe it would make sense to have the install script remove the file and re-try downloading if the checksum is wrong.
This is indeed something we do for the container images (here)
@PaulNeumann -- I think you contributed this Vagrant project, would you like to implement something similar?
@AmedeeBulle Sure, I'm happy to work on this.
I think the checksum verification code should be added to all of the single instance database projects. The non-"XE/Free" projects don't download the database installer files, but the script could still verify the checksum and exit with an error message if it's incorrect.
For the XE/Free projects (18.4.0-XE, 21.3.0-XE, 23.3.0-Free, and 23.4.0-Free), the script could retry the download once if the checksum verification fails. If it fails twice, there's likely something wrong that the script can't correct. However, if the database installer file is already in the project directory when the script runs, and the verification fails, I think the script should just exit with an error message. It's not a good idea, IMO, for the script to delete a file that it didn't download.
Yes, it would be great if we have it for all DB projects where it makes sense...
Easiest is probably to simply abort when the downloaded file does not match the checksum (this is what is done for the container project). End user can then investigate why it might have failed and possibly retry.
But feel free to implement what you think is best.
It's not a good idea, IMO, for the script to delete a file that it didn't download.
vagrant up downloads and deletes it if the installation is successful.
Unless I ask it to keep the file, I think is is fair, if vagrant up also deletes the file if the checksum does not match.
To me it was not at all obvious that the file was cached over vagrant up; vagrant destroy - but only of the file was broken (a good file would have been deleted).
I apologize for the delay in completing this. The updates are done and tested for all of the single-instance database projects except 23.4.0-Free. I need some guidance from @gvenzl before I finish that project. (See below.)
The install.sh scripts will now download the database installer (if applicable) and verify its SHA-256 digest before doing anything else. If there's a problem, the script will exit with an error message stating what happened and how to proceed.
For the projects that download the database installer (18.4.0-XE, 21.3.0-XE, 23.3.0-Free, 23.4.0-Free), the script will try to download the file only once. After thinking about possible edge cases, I don't think it's worthwhile to retry the download if there's a problem.
Finally, the script will never delete the installer file if it's already in the project directory when the script runs. This can happen with the current scripts, as @ole-tange observed, but it shouldn't. Deleting a file on the host without permission is malicious behavior. We can't be 100% certain how the file got there, or what the end user would want. The end user might not be aware of the VM_KEEP_DB_INSTALLER parameter.
Since Oracle Database 23ai Free has been updated to version 23.5.0, the 23.4.0-Free directory should probably be renamed. I'm happy to take care of that, but should it be renamed to "23.5.0-Free", or a more generic name like "23ai-Free"? If RUs will be fairly frequent, maybe the generic name would be better, but it's your call.
Thanks!
I've submitted a PR for this. Comments and suggestions are welcome. Again, I apologize for the delay.