Can't start Oracle Database XE 18.4 Docker Container - database

I'm having this problem after creating the Oracle Database XE 18.4 image with WSL2. I'm trying to create a container based on this image and I keep receiving these errors, even though I'm doing exactly the same thing that is asked on this tutorial provided by Oracle.
The errors show up when I try to create the container and turn it on for the first time
sed: can't read /etc/oratab: No such file or directory
/opt/oracle/runOracle.sh: line 194: /etc/init.d/oracle-xe-18c: No such file or directory
grep: /etc/oratab: No such file or directory
/opt/oracle/checkDBStatus.sh: line 18: oraenv: No such file or directory
#####################################
########### E R R O R ###############
DATABASE SETUP WAS NOT SUCCESSFUL!
Please check output for further info!
########### E R R O R ###############
#####################################
The following output is now a tail of the alert.log:
tail: cannot open '/opt/oracle/diag/rdbms/*/*/trace/alert*.log' for reading: No such file or directory
tail: no files remaining
I would like to know what on earth could I do to solve these errors and get this database running. As a matter of fact, I can't verify if these files mentioned in the log exist because I can't even connect to this container as it remains on for around 5 seconds due to these errors.
I'm using Docker on Windows integrated with WSL2.
My Docker installation info is:
Client: Docker Engine - Community
Cloud integration: 1.0.12
Version: 20.10.5
API version: 1.41
Go version: go1.13.15
Built: Tue Mar 2 20:14:53 2021
OS/Arch: windows/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 20.10.5
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: 363e9a8
Built: Tue Mar 2 20:15:47 2021
OS/Arch: linux/amd64
containerd:
Version: 1.4.4
runc:
Version: 1.0.0-rc93
docker-init:
Version: 0.19.0

The Dockerfile for XE v18.4.0 is different from all the others in the same repo as it tries to pull the image directly from the oracle web server using https during the container build phase. But the container build phase itself happens inside a container (FROM...) so, in my case, it was failing because it did not have the right internet connectivity (shitty proxy with https problems). The image was created, but it did not contain the database engine.
I have modified the Dockerfile inside OracleDatabase\SingleInstance\dockerfiles\18.4.0 so that istead of using the https origin it does a COPY of a (already downloaded) oracle-database-xe-18c-1.0-1.x86_64.rpm inside the image and installs it "locally".
I used as a template the Dockerfile of another version, but it's quite simple.

Tucked away in docker-images\OracleDatabase\SingleInstance\README.md is the following:
IMPORTANT: You will have to provide the installation binaries of Oracle Database (except for Oracle Database 18c XE) and put them into the dockerfiles/<version> folder. You only need to provide the binaries for the edition you are going to install. The binaries can be downloaded from the Oracle Technology Network, make sure you use the linux link: Linux x86-64. The needed file is named linuxx64_<version>_database.zip. You also have to make sure to have internet connectivity for yum. Note that you must not uncompress the binaries. The script will handle that for you and fail if you uncompress them manually!
If you download the OracleXE RPM from https://www.oracle.com/uk/database/technologies/xe-downloads.html and copy it into the version directory as described in the doc, when building the Oracle XE docker image, it seems to do a full install of Oracle XE using the downloaded RPM.
If you skip the manual download of the RPM before building the Docker image, it seems the container will be built, but it tries to do the download when run, which for me at least, didn't work.
Once the Docker image has been built, a container can be started using:
docker run --name oraclexe \
-p 51521:1521 \
-p 55500:5500 \
-v [HOST_PATH]:/opt/oracle/oradata \
-e ORACLE_PWD=mysecurepassword \
-e ORACLE_CHARACTERSET=AL32UTF8 \
oracle/database:18.4.0-xe
Where HOST_PATH is the path to the local directory that Oracle will store the database in.

Related

MariaDB version 10.5.9 unable to install

In my current workplace we are using MariaDB version 10.5.9 for our DB's and we are trying to reinstall this version for testing purposes on a separate container. However, seems anything from 10.5.9 below is failing with the follow error;
root#mdb-10-5:~# curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version=mariadb-10.5.9
# [info] Checking for script prerequisites.
# [warning] Found existing file at /etc/apt/sources.list.d/mariadb.list. Moving to /etc/apt/sources.list.d/mariadb.list.old_5
# [error] MariaDB Server version 10.5.9 is not working.
# Please verify that the version is correct.
#
# The latest MariaDB Server versions are:
# 10.10.1 10.3.36 10.4.26 10.5.17 10.6.10 10.7.6 10.8.5 10.9.3
#
# More information on MariaDB releases is available at:
# https://mariadb.com/kb/en/release-notes/
When I try the same command with version 10.5.10, it works and downloads successfully.
I am using the following procedure, one of which is the MariaDB KB:
https://mariadb.com/kb/en/mariadb-package-repository-setup-and-usage/
https://www.dbi-services.com/blog/how-to-install-a-specific-version-of-mariadb/
Both guides use the same repo, and it is also the only thing that I have found specific when I search for information to install this particular version or MariaDB.
Can anyone offer any suggestions or have experienced similar problems?
We (MariaDB corporation) recently moved over our repositories to a content delivery network instead of using our own servers only. Unfortunately the new service does not have a full archive of older releases yet, the oldest 10.5 we have on there for example is 10.5.10.
I have filed an internal bug report / feature request about that already, but it is still pending.
Meanwhile you can "fix" this by first running the repo setup script with a supported version like 10.5.10, and then editing the repository file it created, replacing the version number with 10.5.9, and the host name dlm.mariadb.com with download.mariadb.com.
On Debian and Ubuntu the repository file would be /etc/apt/sources.list.d/mariadb.list, and you'd have to run apt-get update afterwards to pick up the repo change before installing packages.
On RHEL, CentOS, Rocky etc. the file is /etc/yum.repos.d/mariadb.repo and no further action is needed before installing actual packages.

How to deploy SQL Server Express on Docker Desktop Kubernetes

I've been studying "Kubernetes Up and Running" by Hightower et al (first edition) Chapter 13 where they discussed creating a Reliable MySQL Singleton (Since I just discovered that there is a second edition, I guess I'll be buying it soon).
Using their MySQL reliable singleton example as a model, I've been looking for some sample YAML files to make a similar deployment with Microsoft SQL Server (Express) on Docker Desktop for Kubernetes.
Apparently I need YAML files to deploy
Persistent Volume
Volume claim (should this be NFS?)
SQL Server (Express edition) replica set (in spite of the fact that this is just a singleton).
I've tried this example but I'm confused because it does not contain a persistent volume & claim and it does not work. I get the error
Error: unable to recognize "sqlserver.yml": no matches for kind "Deployment" in version "apps/v1beta1"
Can someone please point me to some sample YAML files that are not Azure specific that will work on Docker Desktop Kubernetes for Windows 10? After debugging my application, I'll want to deploy this to Azure (AKS).
Wed Jul 15 2020 Update
I left out the "-n namespace" for the helm install command (possibly because I'm using Helm and you are using helm v2?).
That install command still did not work. Then I did a
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
Now this command works:
helm install todo-app-database stable/mssql-linux
Progress!
When I do a "k get pods" I see that my todo-app-mssql-linux database is in the pending state. So I did a
kubectl get events
and I see
Warning FailedScheduling pod/todo-app-database-mssql-linux-8668d9b88c-lsh5l 0/1 nodes are available: 1 Insufficient memory.
I've been google searching for "Kubernetes insufficient memory" and can find no match.
I suspect this is a problem specific to "Docker Desktop Kubernetes".
When I look at the output for
helm -n ns-todolistdemo template todo-app-database stable/mssql-linux
I see the deployment is asking for 2Gi. (Interesting: when I use the template command, the "-n ns-todolistdemo" does not cause an error like it does with the install command).
So I do
kubectl describe deployment todo-app-database-mssql-linux >todo-app-database-mssql-linux.yaml
I edit the yaml file to change 2Gi to 1Gi.
kubectl apply -f todo-app-database-mssql-linux.yaml
I get this error:
error: error parsing todo-app-database-mssql-linux.yaml: error converting YAML to JSON: yaml: line 9: mapping values are not allowed in this context
Hmm... that did not work. I try delete:
kubectl delete deployment todo-app-database-mssql-linux
kubectl create -f todo-app-database-mssql-linux.yaml
I get this error:
error: error validating "todo-app-database-mssql-linux.yaml": error validating data: invalid object to validate; if you choose to ignore these errors, turn validation off with --validate=false
So I try apply:
kubectl apply -f todo-app-database-mssql-linux.yaml
Same error!
Shucks.... Is there a way to adjust the memory allocation for Docker Desktop?
Thank you
Siegfried
Short answer
https://github.com/helm/charts/blob/master/stable/mssql-linux/templates/pvc-master.yaml
Detailed Answer
Docker For Desktop comes already with a default StorageClass :
This storage class is responsible for auto-provisioning of PV whenever you create a PVC.
If you have a YAML definition of PVC (persistent volume claim), you just need to keep storageClass empty, so it will use the default.
k get storageclass
NAME PROVISIONER AGE
hostpath (default) docker.io/hostpath 11d
This is fair enough as Docker-For-Desktop Cluster is a one node cluster. So if your DB crashes and the cluster opens it again , it will not move to another node, because simply, you have a single node :)
Now should write the YAML of PVC from scratch ?
No , you don't need. Because Helm should be your best friend.
( I explained below Why you have to use Helm even without deep learning curve)
Fortunately, the community provides a chart called stable/mssql-linux..
Let's run it together :
helm -n <your-namespace> install todo-app-database stable/mssql-linux
# helm -n <namespace> install <release-name> <chart-name-from-community>
If you want to check the YAML (namely PVC) that Helm computed, you can run template instead of install
helm -n <your-namespace> template todo-app-database stable/mssql-linux
Why I give you the answer with Helm ?
Writing YAML from scratch lets reinventing the wheel while others do it.
The most efficient way is to reuse what community prepare for you.
However, you may ask: How can i reuse what others doing ?
That's why Helm comes.
Helm comes to be your installer of any application on top of kubernetes regardless how much YAML does your app require.
Install it now and hit the ground choco install kubernetes-helm

Launch Mongodb in AWS envirement after installation

During 3 days I have been trying to install mongo BD in AWS ec2 instance, today finally managed to install it in Ubuntu, now I can't launch it in AWS environment, after numerous attempts to check the status in aws environment terminal I get errors:
What I have already tried do:
installed mongodb on Ubuntu 16.04 (Xenial)
launch mongo as a service (Ubuntu)
sudo service mongod start
sudo service mongod status
Go to AWS environment and do attempts to check if I'm connected to DB, and get errors:
sudo: mongod: command not found
mongod: unrecognized service
sudo: apt-get: command not found
bash: mongo: command not found
Please help to set my environment
I am pretty sure that Шоира is dealing not with Ubuntu OS but Amazon Linux or so.
So, if she is dealing with Community Edition version of it, the actual docs for every *nix based OS can be found here (MongoDB Docs)
And if I remember this fact correctly, AWS instances comes with Amazon Linux by default, so the documentation guide should been read for Amazon Linux (here), not Ubuntu.
To ensure that she is using Amazon Linus, she must type command grep ^NAME /etc/*release in terminal. If so, the reply should be: Amazon Linux or Amazon Linux AMI
Also, I don't know does it matter or not, but MongoDB Atlas provides also free-tier (as EC2 instance) servers in (almost) every data centers from GCP / Azure / AWS, so sometimes it's better to dealing with Cloud Service (which includes Compass and Realms by default, out of the box) instead of using the Community edition of the -raw DB, and write code and https API for it, later.
I tried to recreate the issue on an EC2 instance with Ubuntu 16.04:
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.6 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
I followed the instructions from your link:
Install MongoDB Community Edition on Ubuntu
I had no issues and was able to install mangoDB as described in the link. The mongoDB is working fine on my instance:
● mongod.service - MongoDB Database Server
Loaded: loaded (/lib/systemd/system/mongod.service; disabled; vendor preset: enabled)
Active: active (running) since Sun 2020-07-19 08:21:41 UTC; 8s ago
Docs: https://docs.mongodb.org/manual
Main PID: 3214 (mongod)
Tasks: 24
Memory: 69.6M
CPU: 746ms
CGroup: /system.slice/mongod.service
└─3214 /usr/bin/mongod --config /etc/mongod.conf
Thus, please double check and ensure that you follow the instructions from the link. The instructions are correct.
Also please make sure to use Ubuntu 16.04:
This means that, you are trying to connect to the mongod process running on the local host which is binded on the default port of 27017

PHP 7.x connection with MSSQL server with MAMP

I am trying to connect mssql server to PHP 7.0.8 through MAMP. I have tried using freetds. On some blog people are saying to use pdo_dblib.so extension but it's not working.
Please guide me through the process of connection.
For those who still have this problem:
/Applications/MAMP/bin/php/php7.2.1/bin/pecl install sqlsrv pdo_sqlsrv
Edit php.ini:
extension=sqlsrv.so
extension=pdo_sqlsrv.so
If necessary, use brew install autoconf if you don't have it already.
While the answers posted by Vague Space and Pedro Santiago helped, I still think the answers are a bit lacking and incomplete… Or ask you to do too much. Honestly the official Microsoft instructions are overkill when they state you need to install their Docker image of SQL Server and such? C’mon… Most people just need the drivers installed to make a connection.
So here is my answer based on my experience installing the pdo_sqlsrv.so and sqlsrv.so modules in MAMP (version 5.2) but should work for most any MAMP version that supports some flavor of PHP 7.
Adjust the .bash_profile so MAMP’s binaries and libraries are a part of your $PATH settings.
First, adjust your .bash_profile so the MAMP stuff is in there; makes it easier to launch and work with MAMP specific binaries and ensures MAMP libraries are checked when doing things like installing new modules like this.
The way I like to do it is like this; set $MAMP_BIN and $MAMP_PHP variables like this and then rebuild the $PATH variables:
# MAMP stuff.
export MAMP_BIN="/Applications/MAMP/Library/bin";
export MAMP_PHP="/Applications/MAMP/bin/php/php7.2.10/bin";
# Final $PATH setting.
export PATH="/usr/local/bin:/usr/local/sbin:$MAMP_BIN:$MAMP_PHP:$PATH";
Save it and just log out of the Terminal session and back in, or just resource the .bash_profile like this:
source ~/.bash_profile
With that done, let’s install the core Microsoft ODBC binary stuff.
Install the Microsoft ODBC stuff.
Do this to install the core ODBC stuff on macOS; be sure to have Homebrew installed:
brew tap microsoft/SQLSRV-release https://github.com/Microsoft/homebrew-SQLSRV-release
brew update
brew install --no-sandbox msodbcsql17 SQLSRV-tools
Then when that’s done, go ahead and install the Unix ODBC stuff like this:
brew install unixodbc
Now install the actual PHP modules via PECL:
pecl install sqlsrv pdo_sqlsrv
With the modules installed, add them to the php.ini file in MAMP so PHP can recognize it. For PHP 7.2.10 on MAMP 5.x it should be located here:
/Applications/MAMP/bin/php/php7.2.10/conf/php.ini
And just add these config lines to the bottom of the file:
; Enable 'Microsoft Drivers for PHP for SQL Server' extension module
extension = sqlsrv.so
extension = pdo_sqlsrv.so
; Configuration
;sqlsrv.WarningsReturnAsErrors = 1
;sqlsrv.LogSeverity = 0
;sqlsrv.LogSubsystems = 0
;sqlsrv.ClientBufferMaxKBSize = 10240
;pdo_sqlsrv.log_severity = 0
;pdo_sqlsrv.client_buffer_max_kb_size = 10240
Note, most tutorials—and even PECL when you install the modules—simply mention adding extension = sqlsrv.so and extension = pdo_sqlsrv.so to the php.ini config, but these config options are the ones that RedHat has when installing the PHP SQLSRV via the Remi repo. Yeah, most of them are commented out but I still like having it there for reference.
Follow this guide through step 3: Microsoft PHP drivers for SQL Server
Find where pecl drops extensions in your local machine
Copy the files pdo_sqlsrv.so and sqlsrv.so into your MAMP's PHP extension directory. Mine was located at /Applications/MAMP/bin/php/php7x.x/lib/php/extensions/no-debug-foo-bar
Edit your php.ini file to include the new extensions:
extension=sqlsrv.so
extension=pdo_sqlsrv.so
Restart your MAMP servers.
having just done this in 2019 with MAMPPRO4 on windows 10 (follow upto step 4 to test that you are connected and then do point 9 ) point 5 onwards is for changing the path in the command line
download dll files from microsoft
https://www.microsoft.com/en-gb/download/details.aspx?id=20098
follow the instruction after running the exe file and place the dll
files into the extension directory of the php version that you are
using eg: MAMP/bin/php/php7.1.29/ext
check phpinfo for the Loaded Configuration File of the php.ini file
add the 2 dll files depending on your requirements (I wasted time by
using the 64.dll) make sure you are using ts(thread safe) not
nts(none thread safe) in the file name of the dll
extension=php_sqlsrv_71_ts_x86.dll
extension=php_pdo_sqlsrv_71_ts_x86.dll
in control panel search for advanced system settings and click
click Environment Variables
under system variables not user variables click path and click edit
click new and add C:\MAMP\bin\php\php7.1.29 (Edit this to your path)
restart MAMP
open a new command line an enter php -v
you should see the php version displayed

DC/OS installation failure during preflight

I am using 5 cloud-based VMs to install DC/OS
1 mesos master
3 mesos agent
1 launching VM
I have installed Docker on my launching VM and start installing DC/OS. It is running successfully during install_prereqs stage without any errors. But it's failing during preflight with below errors for each of my VM system.
STDERR:
Connection to 129.114.18.235 closed.
STDOUT:
Running preflight checks /opt/dcos_install_tmp/dcos_install.sh: line 225: getenforce: command not found
Checking if docker is installed and in PATH: FAIL
Checking if unzip is installed and in PATH: FAIL
Checking if ipset is installed and in PATH: FAIL
Checking if systemd-notify is installed and in PATH: FAIL
/opt/dcos_install_tmp/dcos_install.sh: line 387: systemctl: command not found
Checking if systemctl is installed and in PATH: FAIL
Checking Docker is configured with a production storage driver: /opt/dcos_install_tmp/dcos_install.sh: line 285: docker: command not found
Do I need to install all the required software into my master and agents VMS? Please guide.
We have a similar setup but using straight vm's. We found docker needs to be running on all nodes, including masters, before running the install. Also, make sure you look at: /etc/sysconfig/docker-storageand have: DOCKER_STORAGE_OPTIONS= -s overlayset in the file on all nodes.
I don't believe this is the production setup but should get you running. You also may want to check the privilege of the user executing the install on the remote nodes, does it have permission to see/run systemctl?
I had the same error with the DC/OS web installer in version 1.9
I solved the error after double-checking the bootstraps machines's private key in the web form. To create the key, log into the bootstrap machine and run:
$ ssh-keygen -t rsa
$ for i in `cat dcos-ips.txt`; do ssh-copy-id root#$i; done
$ cat ~/.ssh/id_rsa

Resources