On Windows hosts, the setPassword.sh scripts for the Oracle Database boxes fail. This seems to be the same Git for Windows end-of-line conversion issue that was reported recently for the Kubernetes box (#68).

Environment: Windows 10 Professional x64 Version 1803, VirtualBox 5.2.18, Vagrant 2.1.5, Git for Windows 2.19.0.

The following from the Oracle Database 12.2.0.1 box shows the issue. The 11g XE and 18c setPassword.sh scripts generate the same error.

[vagrant@oracle-12201-vagrant ~]$ sudo su - oracle
Last login: Sun Sep 16 16:54:02 -06 2018
[oracle@oracle-12201-vagrant ~]$ ./setPassword.sh TopSecret
-bash: ./setPassword.sh: /bin/bash^M: bad interpreter: No such file or directory

To confirm that end-of-line conversion is the problem, I made a copy of the setPassword.sh script with the CR characters removed. The copy worked correctly.

[oracle@oracle-12201-vagrant ~]$ tr -d '\r' < setPassword.sh > setPassword2.sh
[oracle@oracle-12201-vagrant ~]$ chmod a+rx setPassword2.sh
[oracle@oracle-12201-vagrant ~]$ ./setPassword2.sh TopSecret
The Oracle base remains unchanged with value /opt/oracle
...
<script runs normally>
...
SQL> Disconnected from Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production

I've verified that the same .gitattributes file that @AmedeeBulle created to fix this issue for the ContainerRegistry and Kubernetes boxes also fixes it for the database boxes.

If you agree that this is a legitimate issue, and that adding .gitattributes files is the right solution, I'd be happy to submit a PR.

when I run /vagrant/scripts/kubeadm-setup-master.sh, I met an Error:

[ERROR] kubeadm init failed
invalid configuration: kind and apiVersion is mandatory information that needs to be specified in all YAML documents

I checked out to k8s-1.12.5 by using git checkout k8s-1.12.5, and then kubeadm-setup-master.sh worked well except a timeout error:

I0413 03:56:48.159054   16380 version.go:93] could not fetch a Kubernetes version from the internet: unable to get URL "https://dl.k8s.io/release/stable-1.txt": Get https://dl.k8s.io/release/stable-1.txt: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
I0413 03:56:48.159348   16380 version.go:94] falling back to the local client version: v1.12.5

Then I ssh into worker1 node, and run /vagrant/scripts/kubeadm-setup-worker.sh, worker node could not connect to api server:

Login Succeeded
./kubeadm-setup-worker.sh: Setup Worker node
Checking kubelet and kubectl RPM ...
Starting to initialize worker node ...
Checking if env is ready ...
Checking whether docker can pull busybox image ...
Checking access to container-registry.oracle.com/kubernetes ...
Trying to pull repository container-registry.oracle.com/kubernetes/kube-proxy ...
v1.12.5: Pulling from container-registry.oracle.com/kubernetes/kube-proxy
Digest: sha256:21be9af716c3d0e4ff4046f55b24e083d6a054da3050bcec13cd3d49a3e6f250
Status: Image is up to date for container-registry.oracle.com/kubernetes/kube-proxy:v1.12.5
Checking whether docker can run container ...
Checking iptables default rule ...
Checking br_netfilter module ...
Checking sysctl variables ...
Enabling kubelet ...
Created symlink from /etc/systemd/system/multi-user.target.wants/kubelet.service to /etc/systemd/system/kubelet.service.
Check successful, ready to run 'join' command ...
[validation] WARNING: kubeadm doesn't fully support multiple API Servers yet
[preflight] running pre-flight checks
[discovery] Trying to connect to API Server "10.0.2.15:6443"
[discovery] Trying to connect to API Server "10.0.2.15:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.0.2.15:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.0.2.15:6443"
[discovery] Failed to request cluster info, will try again: [Get https://10.0.2.15:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: dial tcp 10.0.2.15:6443: connect: connection refused]
[discovery] Failed to request cluster info, will try again: [Get https://10.0.2.15:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: dial tcp 10.0.2.15:6443: connect: connection refused]
[discovery] Failed to request cluster info, will try again: [Get https://10.0.2.15:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: dial tcp 10.0.2.15:6443: connect: connection refused]
[discovery] Failed to request cluster info, will try again: [Get https://10.0.2.15:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: dial tcp 10.0.2.15:6443: connect: connection refused]
[discovery] Failed to request cluster info, will try again: [Get https://10.0.2.15:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: dial tcp 10.0.2.15:6443: connect: connection refused]
[discovery] Failed to request cluster info, will try again: [Get https://10.0.2.15:6443/api/v1/namespaces/kube-public/configmaps/cluster-info: dial tcp 10.0.2.15:6443: connect: connection refused]

Any ideas for this problem?

The SSL certificate deployed on download.virtualbox.org is NOT trusted because of host name mismatch.
Users are not able to download files even after manually trusting the certificate.
All requests to download.virtualbox.org return HTTP 403 Unauthorized Request.

This isn't a requested change, it's just a workaround for a temporary shared folder issue.

The latest UEK Release 5 kernel releases for Oracle Linux 7 and the latest version of the VirtualBox Guest Additions kernel module apparently aren't totally compatible. As a result, VirtualBox shared folders don't work. This isn't related to the boxes in this repository, but it affects new boxes built using the latest version of the OL7 base box.

If you're affected by this problem, the box will build fine, but after a reboot, shared folders (including /vagrant) won't work. Here's what seems to be happening:

• All of the OL7-based boxes are built on top of the base box called ol7-latest.box. The current version of the base box includes the UEK Release 5 kernel and the VirtualBox Guest Additions kernel module. This kernel module provides the shared folder functionality.

• When starting a box for the first time, installed packages are updated to the latest versions by the command yum upgrade -y in the install script. During the update, the kernel is upgraded to version 4.14.35-1818.4.7.el7uek.x86_64, and the VirtualBox Guest Additions kernel module is upgraded to version 5.2.20 (kmod-vboxguest-uek5-5.2.20-1.el7.x86_64).

• When the guest is rebooted (vagrant halt / vagrant up), the new kernel version is loaded. With this new kernel version, the updated Guest Additions kernel module no longer provides shared folder functionality. You'll see something like the following when you run vagrant up. The exact text may vary depending on host OS:

      ==> ol7-vagrant: Mounting shared folders...
      ol7-vagrant: /vagrant => C:/vagrant-boxes/OracleLinux/7
      Vagrant was unable to mount VirtualBox shared folders. This is usually
      because the filesystem "vboxsf" is not available. This filesystem is
      made available via the VirtualBox Guest Additions and kernel module.
      Please verify that these guest additions are properly installed in the
      guest. This is not a bug in Vagrant and is usually caused by a faulty
      Vagrant box. For context, the command attempted was:

      mount -t vboxsf -o uid=1000,gid=1000 vagrant /vagrant

      The error output from the command was:

      /sbin/mount.vboxsf: mounting failed with the error: No such device

If you're seeing this, you can work around it by downgrading the kernel:

• Run vagrant ssh.

• In the SSH session, run sudo yum -y install kernel-uek-4.14.35-1818.3.3.el7uek.x86_64, then reboot the VM. (Version 4.14.35-1818.3.3.el7uek.x86_64 of the UEK Release 5 kernel seems to be the latest version that works properly with version 5.2.20 of the VirtualBox Guest Additions kernel module.)

I'm sure this will be fixed soon with a new release of the Guest Additions kernel module and/or the kernel. In the meantime, I hope this helps.

In the 12.2.0.1 VM the database listener is not listening on port 1521.

There are 2 issues with the tnsnames.ora file for the Oracle Database 18c XE box that make connecting to the database from an SSH session a little harder than it is with the other database boxes.

First, unlike the other database boxes, the permissions on tnsnames.ora allow read access to the oracle user and the oinstall group, but not to others, including the vagrant user.

Permissions on tnsnames.ora for the 12cR2 box:

-rw-r--r--. 1 oracle oinstall 197 Feb 26 20:05 tnsnames.ora

Permissions on tnsnames.ora for the 18c XE box:

-rw-r-----. 1 oracle oinstall 395 Feb 25 18:57 tnsnames.ora

This means that sqlplus <user>/<password>@XE fails for the vagrant user with ORA-12154: TNS:could not resolve the connect identifier specified, even after running oraenv.

Second, unlike the 12c and 18c boxes, the tnsnames.ora file doesn't have an entry for the PDB. So, even after changing the permissions on tnsnames.ora, sqlplus <user>/<password>@XEPDB1 fails with ORA-12154.

Adding the following to install.sh right after running oracle-xe-18c configure would remedy both issues, and would make the box easier to use, especially for users who may not be familiar with Easy Connect syntax:

chmod o+r /opt/oracle/product/18c/dbhomeXE/network/admin/tnsnames.ora

# add tnsnames.ora entry for PDB
echo 'XEPDB1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = XEPDB1)
    )
  )
' >> /opt/oracle/product/18c/dbhomeXE/network/admin/tnsnames.ora

If you think that this would be helpful, I'd be happy to submit a PR.

During 18.4.0-XE deployment, I got the error:

oracle18c-xe-vagrant: Installed:
oracle18c-xe-vagrant:   oracle-database-xe-18c.x86_64 0:1.0-1
oracle18c-xe-vagrant: Complete!
oracle18c-xe-vagrant: INSTALLER: Oracle software installed
oracle18c-xe-vagrant: Configuring Oracle Listener.
oracle18c-xe-vagrant: Listener configuration succeeded.
oracle18c-xe-vagrant: Configuring Oracle Database XE.
oracle18c-xe-vagrant: [FATAL] [DBT-06103] The port (5,500) is already in use.
oracle18c-xe-vagrant:    ACTION: Specify a free port.

If I try to run it manually, I get the same error:

[root@sevenos ~]# /etc/init.d/oracle-xe-18c configure
Configuring Oracle Listener.
Listener configuration succeeded.
Configuring Oracle Database XE.
[FATAL] [DBT-06103] The port (5,500) is already in use.
ACTION: Specify a free port.

#This is a configuration file to setup the Oracle Database.
Database configuration failed. Check logs under '/opt/oracle/cfgtoollogs/dbca'.

I can see that port 5500 is not in use. The error is caused because the hostname was updated but not reflected on /etc/hostname:

[root@sevenos ~]# cat /etc/hostname
localhost.localdomain
[root@sevenos ~]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

After I change it manually, the configuration run smoothly:

[root@sevenos ~]# hostnamectl set-hostname sevenos
[root@sevenos ~]# cat /etc/hostname
sevenos
[root@sevenos ~]# /etc/init.d/oracle-xe-18c configure
Configuring Oracle Listener.
Listener configuration succeeded.
Configuring Oracle Database XE.
Enter SYS user password:

Enter SYSTEM user password:

Enter PDBADMIN User Password:

Prepare for db operation
7% complete
...

To solve the bug simply add command above on install script. Thanks.

The install.sh script for the Oracle Database 11.2.0.2 box modifies the ORACLE_PASSWORD and ORACLE_CONFIRM_PASSWORD values in the xe.rsp file with the generated Oracle password (or the password set in the ORACLE_PWD envrionment variable, if applicable). This causes two problems:

• After the first vagrant up, git treats the xe.rsp file as modified.
• It's more difficult to start over after a vagrant destroy. Unless xe.rsp is edited to change the ORACLE_PASSWORD and ORACLE_CONFIRM_PASSWORD values back to "###ORACLE_PWD###", subsequent vagrant up operations will use the password generated the first time vagrant up was run. This happens because the string "###ORACLE_PWD###" no longer exists in xe.rsp, so sed can't replace it with the new password).

One solution is to use a template for xe.rsp. This is how response files are handled for the Oracle Database 12.2.0.1 box. The following changes would fix the issue:

• Rename the existing xe.rsp file to xe.rsp.tmpl.
• Add one line of code to install.sh to copy xe.rsp.tmpl to xe.rsp before replacing the "###ORACLE_PWD###" strings with the generated password.
• Add one line of code to install.sh to delete xe.rsp after the database is created.

The recent enhancement to allow running user-defined post-setup scripts for the database boxes contained an error in the README.md and put_custom_scripts_here.txt files. The instructions in these files state that user-defined shell scripts will be executed as the vagrant user. This is incorrect. The install.sh script, and any shell scripts called from it, are executed as root. To demonstrate this, replace the install.sh script for any of the database boxes with the following, and run vagrant up.

#!/bin/bash
echo "INSTALLER: Script running as $(whoami)"

The last line of the output from Vagrant will be similar to:

oracle-12201-vagrant: INSTALLER: Script running as root

This issue is my fault. I thought I had verified how the scripts were run, but I was wrong, and I apologize. If you'd like, I can submit a PR to correct the instructions in these files.

Steps to reproduce

1. git clone https://github.com/oracle/vagrant-boxes/
2. cd vagrant-boxes/OracleDatabase/11.2.0.2
3. vagrant up

Expected result
No errors during vagrant instalation.

Actual result
2 errors encountered (1st and 3rd lines in following text):

    oracle11g-xe-vagrant: unzip:  cannot find or open /vagrant/oracle-xe-11.2.0-1.0.x86_64.rpm.zip, /vagrant/oracle-xe-11.2.0-1.0.x86_64.rpm.zip.zip or /vagrant/oracle-xe-11.2.0-1.0.x86_64.rpm.zip.ZIP.
    oracle11g-xe-vagrant: INSTALLER: Oracle software installed
    oracle11g-xe-vagrant: sudo: /etc/init.d/oracle-xe: command not found

Although those errors occur, vagrant up exits with code 0.

Environment
macOS Mojave 10.14.3
Vagrant 2.2.4
VirtualBox 6.0.4 r128413

Congratulations on the new DG and RAC boxes! Very nice!

I've looked though the files, and I have a few suggestions that might help avoid future problems, based on what I've seen with the other Vagrant boxes. I don't mean any of them as criticism--they're just my opinions.

CODEOWNERS

• I don't think the additions to the CODEOWNERS file will work as expected, because they contain typos.
  • "/OralceDG/" on line 5 should be "/OracleDG/"
  • "/OralceRAC/" on line 6 should be "/OracleRAC/"

OracleDG/config/

• I think it'd be helpful to add a .gitignore file in this directory that ignores setup.env (generated during the build), to prevent it from being accidentally committed.

OracleDG/scripts/01_install_os_packages.sh

• I don't think lines 27-29 are compatible with the new yum repository configuration. public-yum-ol7.repo is no longer included in ol7-latest.box, and the file is no longer being updated on yum.oracle.com.

OracleDG/userscripts/

• I think a .gitignore file should be added to this directory to ignore all files except put_custom_scripts_here.txt and .gitignore itself, to prevent user scripts from being accidentally committed. If you want, you can copy the .gitignore file from the userscripts directory of any of the database boxes.

OracleDG/userscripts/put_custom_scripts_here.txt

• I think the text on lines 6-7 should be revised. Shell scripts will be executed as root, not as the vagrant user. (This was my mistake, and I apologize. You just copied the text that I had in the file.)

OracleDG/README.md

• In the text describing "Running scripts after setup", I think the statement that shell scripts will be executed as the vagrant user should be revised to say that shell scripts will be executed as root. (Again, my apologies.)

OracleRAC/config/

• I think it'd be helpful to add a .gitignore file in this directory that ignores setup.env (generated during the build), to prevent it from being accidentally committed.

OracleRAC/scripts/

• I think it'd be helpful to add a .gitignore file in this directory that ignores 09_gi_installation.sh, 11_gi_config.sh, 13_RDBMS_software_installation.sh, and 14_create_database.sh (all generated during the build), to prevent them from being accidentally committed.

OracleRAC/scripts/02_install_os_packages.sh

• I don't think lines 27-29 are compatible with the new yum repository configuration. public-yum-ol7.repo is no longer included in ol7-latest.box, and the file is no longer being updated on yum.oracle.com.

OracleRAC/userscripts/

• I think a .gitignore file should be added to this directory to ignore all files except put_custom_scripts_here.txt and .gitignore itself, to prevent user scripts from being accidentally committed. If you want, you can copy the .gitignore file from the userscripts directory of any of the database boxes.

OracleRAC/userscripts/put_custom_scripts_here.txt

• I think the text on lines 6-7 should be revised. Shell scripts will be executed as root, not as the vagrant user.

OracleRAC/README.md

• In the text describing "Running scripts after setup", I think the statement that shell scripts will be executed as the vagrant user should be revised to say that shell scripts will be executed as root.

Again, congratulations! These boxes are a great addition.

Just tried to spin up 12.2.0.1 DB, provisioning failed on this step:

# create directories
mkdir $ORACLE_BASE && \
chown oracle:oinstall -R $ORACLE_BASE && \
mkdir /u01/app && \
ln -s $ORACLE_BASE /u01/app/oracle

It seems the oracle dir already exists, which poses problem with above script (&&):

[root@oracle-12201-vagrant opt]# ll /opt
total 4
drwxr-xr-x. 2 root root    6 Jun 26 11:28 oracle
drwxr-xr-x. 9 root root 4096 Apr 24 08:06 VBoxGuestAdditions-5.1.24

oracle-12201-vagrant: INSTALLER: Oracle preinstall and openssl complete
oracle-12201-vagrant: mkdir:
oracle-12201-vagrant: cannot create directory ‘/opt/oracle’
oracle-12201-vagrant: : File exists
oracle-12201-vagrant: INSTALLER: Oracle directories created
....
oracle-12201-vagrant: Preparing to launch Oracle Universal Installer from /tmp/OraInstall2018-06-26_11-49-22AM. Please wait ...
oracle-12201-vagrant: [FATAL] [INS-32012] Unable to create directory: /opt/oracle, on this server.
oracle-12201-vagrant:    CAUSE: Either proper permissions were not granted to create the directory or there was no space left in the volume.
oracle-12201-vagrant:    ACTION: Check your permission on the selected directory or choose another directory.
oracle-12201-vagrant: [FATAL] [INS-32012] Unable to create directory: /opt/oracle/product/12.2.0.1/dbhome_1, on this server.
oracle-12201-vagrant:    CAUSE: Either proper permissions were not granted to create the directory or there was no space left in the volume.
oracle-12201-vagrant:    ACTION: Check your permission on the selected directory or choose another directory.

mkdir -p ?

Opening this issue for making a pull request to the vagrant box scripts I have created which enables the Linux box to have Oracle 12c, golden gate, golden gate big data, confluent Kafka setup.

With the Oracle Database 12.2.0.1 and 18.3.0 boxes, EM Express can connect to the CDB, but not directly to the PDB. This is because only port 5500 is forwarded from the host to the guest for EM Express, and this port is used by the CDB. By default, EM Express connections to the PDB would use a different port. Being able to connect directly to the PDB using EM Express would improve usability.

Executing the procedure DBMS_XDB_CONFIG.SETGLOBALPORTENABLED with a parameter of TRUE enables EM Express to connect to both the CDB and the PDB on port 5500. This change is persistent; the procedure needs to be run only once. (The 12cR2 docs for this procedure are here, and the 18c docs are here.)

Adding the following to install.sh after database creation would automate this:

# enable global port for EM Express
su -l oracle -c 'sqlplus / as sysdba <<EOF
   EXEC DBMS_XDB_CONFIG.SETGLOBALPORTENABLED (TRUE);
   exit
EOF'

echo 'INSTALLER: Global EM Express port enabled'

This suggestion is only for the 12.2.0.1 and 18.3.0 boxes. CDB/PDB doesn't apply to 11g XE, 12.1.0.2 requires a separate EM Express port for each container, and the 18c XE box already includes this functionality.

If you think this is a good idea, I'd be happy to submit a PR.

Can you add a port for Apex port

Vagrant up master worked successfully .
After this i typed vagrant ssh master
sudo -s
/vagrant/scripts/kubeadm-setup-master.sh
gave me
bash: /vagrant/scripts/kubeadm-setup-master.sh: /bin/bash^M: bad interpreter: No such file or directory

"vagrant up master" gave an error.
But I could run "vagrant up" which provisioned all 3 default nodes.

Congratulations on the release of Oracle Database 18c XE! Very nice!

As a learning exercise, I built a Vagrant box for 18c XE, based on the other database boxes in this repository. (You can see it in my fork here.)

I wanted to share a couple of things I found, in case they help someone else (and in case someone has better solutions!). Some of this might be environment-specific. I used VirtualBox 5.2.20 and Vagrant 2.2.0 on Windows 10 Professional x64 Version 1803.

• If the VM hostname is set in the Vagrantfile (config.vm.hostname = NAME), listener configuration fails. oracle-xe-18c configure errors out with the message Listener configuration failed. Check log '/opt/oracle/cfgtoollogs/netca/netca_configure_out.log' for more details.

  /opt/oracle/cfgtoollogs/netca/netca_configure_out.log includes the following:

  Oracle Net Listener Startup:
  No valid IP Address returned for the host oracle18c-xe-vagrant.
  Check the trace file for details: /opt/oracle/cfgtoollogs/netca/trace_OraHomeXE-1810226PM1428.log
  Oracle Net Services configuration failed.  The exit code is 1
  

  Since listener configuration fails, the rest of the configuration is skipped, and the database isn't created. To avoid this problem, don't specify a VM hostname in the Vagrantfile. The hostname then defaults to localhost, which seems OK in this case.

  (Interestingly, if you ssh to the box after the configuration fails and run oracle-xe-18c configure again, it works. But that doesn't help with a non-interactive installation.)

• The preinstall rpm is automatically pulled when the database rpm is installed, but it doesn't create the oracle user's home directory (/home/oracle), which means that oracle's database-related environment variables can't easily be set in .bashrc, and sudo su - oracle doesn't work quite as expected.

  However, if you install the preinstall rpm separately before installing the database rpm, /home/oracle is created normally. This doesn't seem to be a Vagrant issue--the same behavior occurs using a clean VM installed from the OL7.5 iso.

• If you edit the oracle-xe-18c.conf file on a Windows host, be sure to preserve the Unix (LF) line endings. oracle-xe-18c configure won't work if the configuration file uses DOS (CR/LF) line endings.

I hope this helps. Again, congratulations on the release.

when i run vagrant up, it failed with many errors like below:
' ...
node2: /vagrant_scripts/01_setup_u01.sh: line 30: $'\r': command not found
...'

the cause is the .sh files in scripts directory is converted to DOS format, i use one of below method to resolve it:

1. dos2unix
2. git config --global core.autocrlf false

The copied setPassword.sh script is not called from the main install.sh.

I added the following line after line 82 to make it work:

sudo su - oracle -c "/home/oracle/setPassword.sh $ORACLE_PWD

I'm no script wizard, but this worked for me.

vagrant up worker2 creating and starting both are normal, BUT, Kubectl get nodes shows Node-workd2 is NotReady! why? thanks in advance.

Best regards,
owen
----issue-info-
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
master.vagrant.vm Ready master 40m v1.9.1+2.1.5.el7
worker1.vagrant.vm Ready 23m v1.9.1+2.1.5.el7
worker2.vagrant.vm NotReady 9m v1.9.1+2.1.5.el7

----vagrant up work2----
vagrant up worker2
Bringing machine 'worker2' up with 'virtualbox' provider...
==> worker2: Importing base box 'ol7-latest'...
==> worker2: Matching MAC address for NAT networking...
==> worker2: Setting the name of the VM: Kubernetes_worker2_1530192939894_22077
==> worker2: Fixed port collision for 22 => 2222. Now on port 2201.
==> worker2: Clearing any previously set network interfaces...
==> worker2: Preparing network interfaces based on configuration...
worker2: Adapter 1: nat
worker2: Adapter 2: hostonly
==> worker2: Forwarding ports...
worker2: 22 (guest) => 2201 (host) (adapter 1)
==> worker2: Running 'pre-boot' VM customizations...
==> worker2: Booting VM...
==> worker2: Waiting for machine to boot. This may take a few minutes...
worker2: SSH address: 127.0.0.1:2201
worker2: SSH username: vagrant
worker2: SSH auth method: private key
worker2:
worker2: Vagrant insecure key detected. Vagrant will automatically replace
worker2: this with a newly generated keypair for better security.
worker2:
worker2: Inserting generated public key within guest...
worker2: Removing insecure key from the guest if it's present...
worker2: Key inserted! Disconnecting and reconnecting using new SSH key...
==> worker2: Machine booted and ready!
==> worker2: Checking for guest additions in VM...
==> worker2: Setting hostname...
==> worker2: Configuring and enabling network interfaces...
worker2: SSH address: 127.0.0.1:2201
worker2: SSH username: vagrant
worker2: SSH auth method: private key
==> worker2: Automatic installation for Landrush IP not enabled
==> worker2: Mounting shared folders...
worker2: /vagrant => /Users/biyang/k8s/labs/vagrant-boxes/Kubernetes
==> worker2: Running provisioner: shell...
worker2: Running: /var/folders/2m/bjrpx9zj1mn0q120w4cgg_b80000gn/T/vagrant-shell20180628-47236-qod999.sh
worker2: Installing and configuring Docker Engine
worker2: Package btrfs-progs-4.9.1-1.0.2.el7.x86_64 already installed and latest version
worker2: Resolving Dependencies
worker2: --> Running transaction check
worker2: ---> Package docker-engine.x86_64 0:17.12.1.ol-1.0.3.el7 will be installed
worker2: --> Processing Dependency: container-selinux >= 2.9 for package: docker-engine-17.12.1.ol-1.0.3.el7.x86_64
worker2: --> Processing Dependency: libcgroup for package: docker-engine-17.12.1.ol-1.0.3.el7.x86_64
worker2: --> Processing Dependency: libltdl.so.7()(64bit) for package: docker-engine-17.12.1.ol-1.0.3.el7.x86_64
worker2: --> Running transaction check
worker2: ---> Package container-selinux.noarch 2:2.21-1.el7 will be installed
worker2: --> Processing Dependency: policycoreutils-python for package: 2:container-selinux-2.21-1.el7.noarch
worker2: ---> Package libcgroup.x86_64 0:0.41-15.el7 will be installed
worker2: ---> Package libtool-ltdl.x86_64 0:2.4.2-22.el7_3 will be installed
worker2: --> Running transaction check
worker2: ---> Package policycoreutils-python.x86_64 0:2.5-22.0.1.el7 will be installed
worker2: --> Processing Dependency: audit-libs-python >= 2.1.3-4 for package: policycoreutils-python-2.5-22.0.1.el7.x86_64
worker2: --> Processing Dependency: setools-libs >= 3.3.8-2 for package: policycoreutils-python-2.5-22.0.1.el7.x86_64
worker2: --> Processing Dependency: libsemanage-python >= 2.5-9 for package: policycoreutils-python-2.5-22.0.1.el7.x86_64
worker2: --> Processing Dependency: python-IPy for package: policycoreutils-python-2.5-22.0.1.el7.x86_64
worker2: --> Processing Dependency: libqpol.so.1(VERS_1.2)(64bit) for package: policycoreutils-python-2.5-22.0.1.el7.x86_64
worker2: --> Processing Dependency: libqpol.so.1(VERS_1.4)(64bit) for package: policycoreutils-python-2.5-22.0.1.el7.x86_64
worker2: --> Processing Dependency: checkpolicy for package: policycoreutils-python-2.5-22.0.1.el7.x86_64
worker2: --> Processing Dependency: libapol.so.4(VERS_4.0)(64bit) for package: policycoreutils-python-2.5-22.0.1.el7.x86_64
worker2: --> Processing Dependency: libapol.so.4()(64bit) for package: policycoreutils-python-2.5-22.0.1.el7.x86_64
worker2: --> Processing Dependency: libqpol.so.1()(64bit) for package: policycoreutils-python-2.5-22.0.1.el7.x86_64
worker2: --> Running transaction check
worker2: ---> Package audit-libs-python.x86_64 0:2.8.1-3.el7 will be installed
worker2: ---> Package checkpolicy.x86_64 0:2.5-6.el7 will be installed
worker2: ---> Package libsemanage-python.x86_64 0:2.5-11.el7 will be installed
worker2: ---> Package python-IPy.noarch 0:0.75-6.el7 will be installed
worker2: ---> Package setools-libs.x86_64 0:3.3.8-2.el7 will be installed
worker2: --> Finished Dependency Resolution
worker2:
worker2: Dependencies Resolved
worker2:
worker2: ================================================================================
worker2: Package Arch Version Repository Size
worker2: ================================================================================
worker2: Installing:
worker2: docker-engine x86_64 17.12.1.ol-1.0.3.el7 ol7_preview 31 M
worker2: Installing for dependencies:
worker2: audit-libs-python x86_64 2.8.1-3.el7 ol7_latest 75 k
worker2: checkpolicy x86_64 2.5-6.el7 ol7_latest 294 k
worker2: container-selinux noarch 2:2.21-1.el7 ol7_addons 28 k
worker2: libcgroup x86_64 0.41-15.el7 ol7_latest 65 k
worker2: libsemanage-python x86_64 2.5-11.el7 ol7_latest 112 k
worker2: libtool-ltdl x86_64 2.4.2-22.el7_3 ol7_latest 48 k
worker2: policycoreutils-python x86_64 2.5-22.0.1.el7 ol7_latest 454 k
worker2: python-IPy noarch 0.75-6.el7 ol7_latest 32 k
worker2: setools-libs x86_64 3.3.8-2.el7 ol7_latest 619 k
worker2:
worker2: Transaction Summary
worker2: ================================================================================
worker2: Install 1 Package (+9 Dependent packages)
worker2: Total download size: 32 M
worker2: Installed size: 128 M
worker2: Downloading packages:
worker2: --------------------------------------------------------------------------------
worker2: Total 4.1 MB/s | 32 MB 00:07
worker2: Running transaction check
worker2: Running transaction test
worker2: Transaction test succeeded
worker2: Running transaction
worker2: Installing : libcgroup-0.41-15.el7.x86_64 1/10
worker2:
worker2: Installing : audit-libs-python-2.8.1-3.el7.x86_64 2/10
worker2:
worker2: Installing : checkpolicy-2.5-6.el7.x86_64 3/10
worker2:
worker2: Installing : libtool-ltdl-2.4.2-22.el7_3.x86_64 4/10
worker2:
worker2: Installing : python-IPy-0.75-6.el7.noarch 5/10
worker2:
worker2: Installing : libsemanage-python-2.5-11.el7.x86_64 6/10
worker2:
worker2: Installing : setools-libs-3.3.8-2.el7.x86_64 7/10
worker2:
worker2: Installing : policycoreutils-python-2.5-22.0.1.el7.x86_64 8/10
worker2:
worker2: Installing : 2:container-selinux-2.21-1.el7.noarch 9/10
worker2:
worker2: Installing : docker-engine-17.12.1.ol-1.0.3.el7.x86_64 10/10
worker2:
worker2: Verifying : libcgroup-0.41-15.el7.x86_64 1/10
worker2:
worker2: Verifying : setools-libs-3.3.8-2.el7.x86_64 2/10
worker2:
worker2: Verifying : libsemanage-python-2.5-11.el7.x86_64 3/10
worker2:
worker2: Verifying : 2:container-selinux-2.21-1.el7.noarch 4/10
worker2:
worker2: Verifying : python-IPy-0.75-6.el7.noarch 5/10
worker2:
worker2: Verifying : libtool-ltdl-2.4.2-22.el7_3.x86_64 6/10
worker2:
worker2: Verifying : docker-engine-17.12.1.ol-1.0.3.el7.x86_64 7/10
worker2:
worker2: Verifying : policycoreutils-python-2.5-22.0.1.el7.x86_64 8/10
worker2:
worker2: Verifying : checkpolicy-2.5-6.el7.x86_64 9/10
worker2:
worker2: Verifying : audit-libs-python-2.8.1-3.el7.x86_64 10/10
worker2:
worker2:
worker2: Installed:
worker2: docker-engine.x86_64 0:17.12.1.ol-1.0.3.el7
worker2:
worker2: Dependency Installed:
worker2: audit-libs-python.x86_64 0:2.8.1-3.el7
worker2: checkpolicy.x86_64 0:2.5-6.el7
worker2: container-selinux.noarch 2:2.21-1.el7
worker2: libcgroup.x86_64 0:0.41-15.el7
worker2: libsemanage-python.x86_64 0:2.5-11.el7
worker2: libtool-ltdl.x86_64 0:2.4.2-22.el7_3
worker2: policycoreutils-python.x86_64 0:2.5-22.0.1.el7
worker2: python-IPy.noarch 0:0.75-6.el7
worker2: setools-libs.x86_64 0:3.3.8-2.el7
worker2: Complete!
worker2: Creating 'btrfs' file system on: /dev/sdb
worker2: Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.
worker2: Installing and configuring Kubernetes packages
worker2: Resolving Dependencies
worker2: --> Running transaction check
worker2: ---> Package kubeadm.x86_64 0:1.9.1-2.1.5.el7 will be installed
worker2: --> Processing Dependency: kubectl >= 1.9.1-2.1.5.el7 for package: kubeadm-1.9.1-2.1.5.el7.x86_64
worker2: --> Processing Dependency: kubernetes-cni >= 0.6.0 for package: kubeadm-1.9.1-2.1.5.el7.x86_64
worker2: --> Processing Dependency: kubelet >= 1.9.1-2.1.5.el7 for package: kubeadm-1.9.1-2.1.5.el7.x86_64
worker2: --> Running transaction check
worker2: ---> Package kubectl.x86_64 0:1.9.1-2.1.5.el7 will be installed
worker2: ---> Package kubelet.x86_64 0:1.9.1-2.1.5.el7 will be installed
worker2: --> Processing Dependency: socat for package: kubelet-1.9.1-2.1.5.el7.x86_64
worker2: ---> Package kubernetes-cni.x86_64 0:0.6.0-2.0.1.el7 will be installed
worker2: --> Processing Dependency: kubernetes-cni-plugins = 0.6.0 for package: kubernetes-cni-0.6.0-2.0.1.el7.x86_64
worker2: --> Running transaction check
worker2: ---> Package kubernetes-cni-plugins.x86_64 0:0.6.0-2.0.1.el7 will be installed
worker2: ---> Package socat.x86_64 0:1.7.3.2-2.el7 will be installed
worker2: --> Finished Dependency Resolution
worker2:
worker2: Dependencies Resolved
worker2:
worker2: ================================================================================
worker2: Package Arch Version Repository Size
worker2: ================================================================================
worker2: Installing:
worker2: kubeadm x86_64 1.9.1-2.1.5.el7 ol7_addons 17 M
worker2: Installing for dependencies:
worker2: kubectl x86_64 1.9.1-2.1.5.el7 ol7_addons 8.9 M
worker2: kubelet x86_64 1.9.1-2.1.5.el7 ol7_addons 17 M
worker2: kubernetes-cni x86_64 0.6.0-2.0.1.el7 ol7_addons 797 k
worker2: kubernetes-cni-plugins x86_64 0.6.0-2.0.1.el7 ol7_addons 8.5 M
worker2: socat x86_64 1.7.3.2-2.el7 ol7_latest 289 k
worker2:
worker2: Transaction Summary
worker2: ================================================================================
worker2: Install 1 Package (+5 Dependent packages)
worker2: Total download size: 52 M
worker2: Installed size: 279 M
worker2: Downloading packages:
worker2: --------------------------------------------------------------------------------
worker2: Total 5.8 MB/s | 52 MB 00:08
worker2: Running transaction check
worker2: Running transaction test
worker2: Transaction test succeeded
worker2: Running transaction
worker2: Installing : socat-1.7.3.2-2.el7.x86_64 1/6
worker2:
worker2: Installing : kubelet-1.9.1-2.1.5.el7.x86_64 2/6
worker2:
worker2: Installing : kubectl-1.9.1-2.1.5.el7.x86_64 3/6
worker2:
worker2: Installing : kubernetes-cni-plugins-0.6.0-2.0.1.el7.x86_64 4/6
worker2:
worker2: Installing : kubernetes-cni-0.6.0-2.0.1.el7.x86_64 5/6
worker2:
worker2: Installing : kubeadm-1.9.1-2.1.5.el7.x86_64 6/6
worker2:
worker2: Verifying : kubernetes-cni-plugins-0.6.0-2.0.1.el7.x86_64 1/6
worker2:
worker2: Verifying : kubeadm-1.9.1-2.1.5.el7.x86_64 2/6
worker2:
worker2: Verifying : kubernetes-cni-0.6.0-2.0.1.el7.x86_64 3/6
worker2:
worker2: Verifying : kubectl-1.9.1-2.1.5.el7.x86_64 4/6
worker2:
worker2: Verifying : socat-1.7.3.2-2.el7.x86_64 5/6
worker2:
worker2: Verifying : kubelet-1.9.1-2.1.5.el7.x86_64 6/6
worker2:
worker2:
worker2: Installed:
worker2: kubeadm.x86_64 0:1.9.1-2.1.5.el7
worker2:
worker2: Dependency Installed:
worker2: kubectl.x86_64 0:1.9.1-2.1.5.el7
worker2: kubelet.x86_64 0:1.9.1-2.1.5.el7
worker2: kubernetes-cni.x86_64 0:0.6.0-2.0.1.el7
worker2: kubernetes-cni-plugins.x86_64 0:0.6.0-2.0.1.el7
worker2: socat.x86_64 0:1.7.3.2-2.el7
worker2: Complete!
worker2: net.bridge.bridge-nf-call-ip6tables = 1
worker2: net.bridge.bridge-nf-call-iptables = 1
worker2: Your Kubernetes VM is ready to use!

$ vagrant status
Current machine states:

master running (virtualbox)
worker1 running (virtualbox)
worker2 running (virtualbox)

This environment represents multiple VMs. The VMs are all listed
above with their current state. For more information about a specific
VM, run vagrant status NAME.
Yangs-MacBook-Pro:Kubernetes biyang$ vagrant ssh master
Last login: Thu Jun 28 13:02:06 2018 from 10.0.2.2

Welcome to Oracle Linux Server release 7.5 (GNU/Linux 4.1.12-124.14.1.el7uek.x86_64)

The Oracle Linux End-User License Agreement can be viewed here:

* /usr/share/eula/eula.en_US

For additional packages, updates, documentation and community help, see:

* http://yum.oracle.com/

-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory

get nodes
NAME STATUS ROLES AGE VERSION
master.vagrant.vm Ready master 40m v1.9.1+2.1.5.el7
worker1.vagrant.vm Ready 23m v1.9.1+2.1.5.el7
worker2.vagrant.vm NotReady 9m v1.9.1+2.1.5.el7

get pods --namespace=kube-system
NAME READY STATUS RESTARTS AGE
etcd-master.vagrant.vm 1/1 Running 0 42m
kube-apiserver-master.vagrant.vm 1/1 Running 0 41m
kube-controller-manager-master.vagrant.vm 1/1 Running 0 41m
kube-dns-855949bbf-b2ldn 3/3 Running 0 42m
kube-flannel-ds-hvl54 0/1 Init:0/1 0 12m
kube-flannel-ds-j9bq2 1/1 Running 0 26m
kube-flannel-ds-thpr7 1/1 Running 0 42m
kube-proxy-4hmmw 1/1 Running 0 26m
kube-proxy-q2vmp 1/1 Running 0 12m
kube-proxy-sj6lj 1/1 Running 0 42m
kube-scheduler-master.vagrant.vm 1/1 Running 0 42m
kubernetes-dashboard-7c966ddf6d-l2r7n 1/1 Running 0 42m

Reposting this from a blog post comment:

Hi Gerald,
Thank you for this guide. I followed this guide and installed 3 nodes k8s cluster. However I found there is something wrong with network between pods

[vagrant@master vagrant]$ kubectl get po -o wide -n kube-system
NAME READY STATUS RESTARTS AGE IP NODE
etcd-master.vagrant.vm 1/1 Running 3 2d 192.168.99.100 master.vagrant.vm
kube-apiserver-master.vagrant.vm 1/1 Running 7 2d 192.168.99.100 master.vagrant.vm
kube-controller-manager-master.vagrant.vm 1/1 Running 3 2d 192.168.99.100 master.vagrant.vm
kube-dns-855949bbf-d4cj2 3/3 Running 6 2d 10.244.0.6 master.vagrant.vm
kube-flannel-ds-cmq2z 1/1 Running 1 2d 192.168.99.101 worker1.vagrant.vm
kube-flannel-ds-h87pm 1/1 Running 3 2d 192.168.99.100 master.vagrant.vm
kube-flannel-ds-ssdcw 1/1 Running 1 2d 192.168.99.102 worker2.vagrant.vm
kube-proxy-c97rv 1/1 Running 2 2d 192.168.99.100 master.vagrant.vm
kube-proxy-fd9c8 1/1 Running 1 2d 192.168.99.102 worker2.vagrant.vm
kube-proxy-w5ggl 1/1 Running 1 2d 192.168.99.101 worker1.vagrant.vm
kube-scheduler-master.vagrant.vm 1/1 Running 3 2d 192.168.99.100 master.vagrant.vm
kubernetes-dashboard-7c966ddf6d-dzwf7 1/1 Running 3 2d 10.244.0.7 master.vagrant.vm
tiller-deploy-75f5797b-5ps8s 1/1 Running 0 46m 10.244.1.2 worker1.vagrant.vm
[vagrant@master vagrant]$ ping 10.244.1.2
PING 10.244.1.2 (10.244.1.2) 56(84) bytes of data.
^C
— 10.244.1.2 ping statistics —
56 packets transmitted, 0 received, 100% packet loss, time 55097ms

Did you encounter this issue?

Thanks,
Junyi.

I followed the guide to setup a Kubernetes cluster but noticed that Kubernetes 1.9 was deployed. I will try to update to 1.13 but is it possible to deploy version 1.13 from the start?

Steps to Reproduce:

1. cd into Container Registry folder.
2. vagrant up
3. vagrant ssh registry
4. /vagrant/scripts/kubeadm-setup-registry.sh --from container-registry-fra.oracle.com
   After the credentials entered, it is throwing an error while pulling docker images from oracle registry.
   manifest for container-registry-fra.oracle.com/kubernetes/pause-amd64:3.1 not found

Logs:

Pulling images [v1.10.5] from: [container-registry-fra.oracle.com/kubernetes] to: [localhost:5000/kubernetes]
Checking if docker is active ...
Checking for pull access from container-registry-fra.oracle.com/kubernetes registry ...
Trying to pull repository container-registry-fra.oracle.com/kubernetes/pause-amd64 ...
manifest for container-registry-fra.oracle.com/kubernetes/pause-amd64:3.1 not found
[ERROR] docker cannot pull pause-amd64:3.1 from container-registry-fra.oracle.com/kubernetes registry

The idea is that the Vagrantfile script automatically detects certain environment variables from the host and passes those one, therefore not requiring the user to manually change the Vagrantfile any longer for customizations. The idea would be:

export ORACLE_HOME=/home/oracle/database
export ORACLE_SID=MYDB
vagrant up

Vagrant then automatically detects those and sets them for the VM as well, rather than having the user to go into the Vagrantfile itself and set those.

I am seeing #25. Workaround mentioned does not solve the problem.

1. Attempting to setup maser

[root@master scripts]# ./kubeadm-setup-master.sh
./kubeadm-setup-master.sh: Login to container-registry.oracle.com
Username: [email protected]
Password:
Login Succeeded
./kubeadm-setup-master.sh: Setup Master node -- be patient!
./kubeadm-setup-master.sh: kubeadm-setup.sh did not complete successfully
Last lines of kubeadm-setup.log:
Starting to initialize master node ...
Checking if env is ready ...
Checking whether docker can pull busybox image ...
Checking access to container-registry.oracle.com/kubernetes ...
[ERROR] Please login with valid credential to the container-registry.oracle.com/kubernetes
# docker login container-registry.oracle.com/kubernetes

2. Try to do docker login. This is successful

[root@master scripts]# docker login container-registry.oracle.com/kubernetes
Username ([email protected]):
Password:
Login Succeeded

3. Again try master setup. Failure again

[root@master scripts]# ./kubeadm-setup-master.sh
./kubeadm-setup-master.sh: Login to container-registry.oracle.com
Username ([email protected]):
Password:
Login Succeeded
./kubeadm-setup-master.sh: Setup Master node -- be patient!
./kubeadm-setup-master.sh: kubeadm-setup.sh did not complete successfully
Last lines of kubeadm-setup.log:
Starting to initialize master node ...
Checking if env is ready ...
Checking whether docker can pull busybox image ...
Checking access to container-registry.oracle.com/kubernetes ...
[ERROR] Please login with valid credential to the container-registry.oracle.com/kubernetes
# docker login container-registry.oracle.com/kubernetes
[root@master scripts]#

Any help appreciated. Thanks Sathish

I deployed a master + 3 node k8s cluster (on OSX)
From the master node I borrowed the ~/.kube/config file and placed in my ~/.kube/config on my Mac
Using HomeBrew, installed the kubectl package. This has worked before against minikube

Not able to communicate with the cluster

The master appears to have port 6443 mapped out on the host only adapter but I can't seem to connect/netcat to it

When running /vagrant/scripts/kubeadm-setup-master.sh as per instruction given, it gave error even after providing oracle container registry credentials. Screenshot attached. I needed to run "docker login" command separately, after which running the script (/vagrant/scripts/kubeadm-setup-master.sh ) worked.

invalid configuration: kind and apiVersion is mandatory information that needs to be specified in all YAML documents

• created master node using vagrant
• logged in to master
• "su -"
• /vagrant/scripts/kubeadm-setup-master.sh
  It asked for Oracle ID/pw, all good.
  .......
  Login Succeeded
  ./kubeadm-setup-master.sh: Setup Master node -- be patient!
  ./kubeadm-setup-master.sh: kubeadm-setup.sh did not complete successfully
  Last lines of kubeadm-setup.log:
  Checking br_netfilter module ...
  Checking sysctl variables ...
  Enabling kubelet ...
  Created symlink from /etc/systemd/system/multi-user.target.wants/kubelet.service to /etc/systemd/system/kubelet.service.
  Check successful, ready to run 'up' command ...
  Waiting for kubeadm to setup master cluster...
  Please wait ...

[ERROR] kubeadm init failed
invalid configuration: kind and apiVersion is mandatory information that needs to be specified in all YAML documents

Hi, I am on a Mac, with the latest version of Vagrant, in the cloned sub directory /Users/jifbrodeur/vagrant-boxes/OracleLinux/7 and the vagrant up goes into a infinite loop I think, see below, am I doing something wrong?
Thanks in advance
Jean-Francois Brodeur

Installing vagrant-reload Plugin...
Exec error: fork/exec /opt/vagrant/embedded/bin/ruby: argument list too long
Installing vagrant-proxyconf Plugin...
Exec error: fork/exec /opt/vagrant/embedded/bin/ruby: argument list too long
Installing the 'vagrant-reload' plugin. This can take a few minutes...
Installed the plugin 'vagrant-reload (0.0.1)'!
Installing vagrant-proxyconf Plugin...
Installing vagrant-reload Plugin...
Exec error: fork/exec /opt/vagrant/embedded/bin/ruby: argument list too long
Installing vagrant-proxyconf Plugin...
Exec error: fork/exec /opt/vagrant/embedded/bin/ruby: argument list too long
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Fetching: vagrant-proxyconf-1.5.2.gem (100%)
Installed the plugin 'vagrant-proxyconf (1.5.2)'!
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Installed the plugin 'vagrant-proxyconf (1.5.2)'!
Installing the 'vagrant-reload' plugin. This can take a few minutes...
Successfully uninstalled vagrant-proxyconf-1.5.2
Installed the plugin 'vagrant-reload (0.0.1)'!
Installing vagrant-proxyconf Plugin...
Installing vagrant-reload Plugin...
Installing vagrant-reload Plugin...
Installing vagrant-reload Plugin...
Exec error: fork/exec /opt/vagrant/embedded/bin/ruby: argument list too long
Installing vagrant-proxyconf Plugin...
Exec error: fork/exec /opt/vagrant/embedded/bin/ruby: argument list too long
Installing the 'vagrant-reload' plugin. This can take a few minutes...
Installed the plugin 'vagrant-reload (0.0.1)'!
Installing vagrant-proxyconf Plugin...
Installing vagrant-reload Plugin...
Exec error: fork/exec /opt/vagrant/embedded/bin/ruby: argument list too long
Installing vagrant-proxyconf Plugin...
Exec error: fork/exec /opt/vagrant/embedded/bin/ruby: argument list too long
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Fetching: vagrant-proxyconf-1.5.2.gem (100%)

Installing vagrant-proxyconf Plugin...
Installing the 'vagrant-proxyconf' plugin. This can take a few minutes...
Fetching: vagrant-proxyconf-1.5.2.gem (100%)
Bundler, the underlying system Vagrant uses to install plugins,
reported an error. The error is shown below. These errors are usually
caused by misconfigured plugin installations or transient network
issues. The error from Bundler is:

Unable to resolve dependency: user requested 'vagrant-vbguest (= 0.15.0)'

(Please bear with me; this one takes some explanation.)

After the release of the most recent version of the ol7-latest base box on April 19, I began seeing an error on some Windows hosts when building the Oracle Database 12cR1 box. After the database installer files are unzipped, the runInstaller script fails, so the database software isn’t installed:

<snip everything before last installer file being unzipped>
    oracle-12102-vagrant:   inflating: /vagrant/database/install/.oui  
    oracle-12102-vagrant: 
    oracle-12102-vagrant: 2 archives were successfully processed.
    oracle-12102-vagrant: /vagrant/database/runInstaller: line 249: /vagrant/database/install/.oui: Permission denied
    oracle-12102-vagrant: /tmp/vagrant-shell: line 73: /opt/oracle/oraInventory/orainstRoot.sh: No such file or directory
    oracle-12102-vagrant: /tmp/vagrant-shell: line 74: /opt/oracle/product/12.1.0.2/dbhome_1/root.sh: No such file or directory
<snip rest of log>

The hosts this error occurs on are Windows 10 Professional Build 1809 and Windows 10 Enterprise Build 1803, with VirtualBox 6.0.6 and Vagrant 2.2.4. The affected hosts are fairly quick machines (Core i7, 32 GB RAM, SSD). The build worked successfully on these hosts with the previous version of the ol7-latest base box. The build still works successfully on an older, slower Windows 10 Professional 1809 host (Core i5, 8 GB RAM, HDD) running the same versions of VirtualBox, Vagrant and the ol7-latest box. This behavior is consistent and reproducible: the build fails on the faster hosts, and works on the slower host.

After some troubleshooting, I believe that the problem is a timing issue, not permissions. It may be specific to Windows hosts. For the 12cR1 box, the database installer files are unzipped to the host's filesystem (/vagrant/database). I think that the installer files aren't being fully flushed to disk before runInstaller starts. (The file that runInstaller can't access, .oui, is the last file that's unzipped.)

One of the items in the VirtualBox 6.0.6 changelog is "Linux guests: shared folder performance and reliability improvements and missing features". I suspect that the upgraded Guest Additions in the base box changed the timing just enough to introduce a problem with the 12cR1 build. If I add a sleep 0.2s statement to install.sh right after the unzip statement, the build succeeds on the same hosts. The slight delay seems to allow enough time for all of the installer files to be flushed to disk. (sleep 0.1s wasn't enough; the build still failed on the faster hosts.)

Adding a sleep command seems to fix the immediate issue, but it's not very elegant or robust. With an even faster host, or an anti-virus application locking one of the installer files, the build could still fail.

I think a better solution would be to unzip the installer files to /tmp, instead of /vagrant. This would take the host filesystem out of the picture. There's enough space available in the VM, and the installer files are deleted after use. I've tested this, and it seems to work well. Unzipping to and installing from /tmp also seems to be a little faster.

Even though I've seen this issue only with the 12cR1 box, I suggest modifying the install.sh scripts for the 11gXE, 12cR1 and 12cR2 boxes to unzip the database installer files to /tmp, instead of /vagrant. (These are the only database boxes that extract the installer files to the host's filesystem.) This would keep the boxes consistent, and would reduce the chance of similar problems in the future.

I hope this makes sense. Please let me know if you need any more information. If you agree with this approach, and you'd like me to work on it, I'd be happy to.

Thanks,
Paul

(Note: similar symptoms to issue #24 but it didn't go away when I tried vagrant destroy... still freezes)

setup

Win 7 pro
git bash
$ vagrant --version
Vagrant 2.2.2

$ vagrant up master
(or... retrying)
$ vagrant reload master --provision

Bringing machine 'master' up with 'virtualbox' provider...
==> master: Importing base box 'ol7-latest'...
==> master: Matching MAC address for NAT networking...
==> master: Setting the name of the VM: Kubernetes_master_1544738206907_88094
==> master: Couldn't find Cheffile at ./Cheffile.
==> master: Fixed port collision for 22 => 2222. Now on port 2202.
==> master: Vagrant has detected a configuration issue which exposes a
==> master: vulnerability with the installed version of VirtualBox. The
==> master: current guest is configured to use an E1000 NIC type for a
==> master: network adapter which is vulnerable in this version of VirtualBox.
==> master: Ensure the guest is trusted to use this configuration or update
==> master: the NIC type using one of the methods below:
==> master:
==> master: https://www.vagrantup.com/docs/virtualbox/configuration.html#default-nic-type
==> master: https://www.vagrantup.com/docs/virtualbox/networking.html#virtualbox-nic-type
==> master: Clearing any previously set network interfaces...
==> master: Preparing network interfaces based on configuration...
master: Adapter 1: nat
master: Adapter 2: hostonly
==> master: Forwarding ports...
master: 8001 (guest) => 8001 (host) (adapter 1)
master: 22 (guest) => 2202 (host) (adapter 1)
==> master: Running 'pre-boot' VM customizations...
==> master: Booting VM...
==> master: Waiting for machine to boot. This may take a few minutes...
master: SSH address: 127.0.0.1:2202
master: SSH username: vagrant
master: SSH auth method: private key

Just like #31 we should have this for all images.

Would you consider an enhancement to the Oracle Database boxes to allow running user-defined scripts after the database is set up? Users often need to run shell and/or SQL scripts to finish setting up the environment after database installation, and this would automate the process. The Oracle Database builds in the docker-images repository have this feature, and it might be useful for the Vagrant database boxes, too.

In the docker-images repository, there's a script called runUserScripts.sh that runs user-defined scripts. It's straightforward to add the same logic to the install.sh scripts for the database boxes:

# run user-defined post-setup scripts
echo 'INSTALLER: Running user-defined post-setup scripts'

for f in /vagrant/userscripts/*
  do
    case "${f,,}" in
      *.sh)
        echo "INSTALLER: Running $f"
        . "$f"
        echo "INSTALLER: Done running $f"
        ;;
      *.sql)
        echo "INSTALLER: Running $f"
        su -l oracle -c "echo 'exit' | sqlplus -s / as sysdba @\"$f\""
        echo "INSTALLER: Done running $f"
        ;;
      *)
        echo "INSTALLER: Ignoring $f"
        ;;
    esac
  done

echo 'INSTALLER: Done running user-defined post-setup scripts'

I've been using this for a while, and it seems to work well. It runs any .sh and .sql scripts in the /vagrant/userscripts directory, and ignores other file extensions. It handles both lower- and upper-case file extensions, and works for filenames with spaces in them. The functionality is completely optional; if there aren't any script files in the directory, nothing is run. I put this block right after setPassword.sh is set up.

To make this as easy to use as possible, it might make sense to add the /vagrant/userscripts directory, perhaps including a file called put_custom_scripts_here.txt. Usage instructions could be placed in this file, as well as in README.md.

Do you think this would be worthwhile? If so, I'd be happy to work on it. I'd also be grateful for any suggested improvements.

A new version of VirtualBox guest additions has been released (6.0.4 -> 6.0.6): https://www.virtualbox.org/wiki/Downloads

The repo containing the oracle linux vagrant boxes still has 6.0.4 installed. The vagrant-vbguest plugin can be used to automatically upgrade it, but this upgrade has to be done every time you provision the base box which slows things down a little. For the best user experience, a new base box with upgraded guest additions should be created.

I understand that this repo is not for the maintenance of those boxes, but I couldn't figure out where else to bring this up. Hopefully someone here can at least point me in the right direction.

Would you consider an enhancement to add an Oracle Database 12c Release 1 (12.1.0.2) box? There are 12c R1 builds for EE and SE2 in the docker-images repository, and I think it'd be helpful to have it available as a Vagrant box, too--a lot of organizations still use 12c R1.

If you think this is a good idea, I have a 12c R1 box ready that supports both EE and SE2. It follows the same conventions as the other database boxes in this repository.

Vagrant box name do not take into account the NAME variable.
Vagrant global-status return "default" as name for all boxes.

Setting config.vm.define parameter to NAME variable fix this problem.

With the current version of ol7-latest.box (as of 31-Jan) and the announced Oracle Linux yum server changes, the install.sh script fails. One can see this in the output from vagrant up:

oracle-18c-vagrant: IMPORTANT: A legacy Oracle Linux yum server repo file was found. Oracle Linux yum server repository configurations have changed which means public-yum-ol7.repo will no longer be updated. New repository configuration files have been installed but are disabled. To complete the transition, run this script as the root user:
oracle-18c-vagrant:
oracle-18c-vagrant: /usr/bin/ol_yum_configure.sh

A quick fix is just to check for the existence of the yum repo script post update (insert the below after line 20)

if [ -f /usr/bin/ol_yum_configure.sh ]; then
  echo 'INSTALLER: updating Oracle Linux yum server repo file'
  /usr/bin/ol_yum_configure.sh
  echo 'INSTALLER: updating Oracle Linux yum server repo file, done!'
fi

This allows the install to run to completion successfully.

Hello. I followed instructions here:
https://geraldonit.com/2018/03/26/deploying-a-kubernetes-cluster-with-vagrant-on-virtual-box/

On my master vagrant vm, as root, I ran:

[root@master bin]# /vagrant/scripts/kubeadm-setup-master.sh

After more than 10 minutes, I still see "... Setup Master node -- be patient!" Tailing the log shows 0% complete:

[root@master bin]# tail -f kubeadm-setup.log 
Starting to initialize master node ...
Checking if env is ready ...
Checking whether docker can pull busybox image ...
Checking access to container-registry.oracle.com/kubernetes ...
v1.9.1-1: Pulling from kubernetes/kube-proxy-amd64
Digest: sha256:f525d06eebf7f21c55550b1da8cee4720e36b9ffee8976db357f49eddd04c6d0
Status: Image is up to date for container-registry.oracle.com/kubernetes/kube-proxy-amd64:v1.9.1-1
Checking whether docker can run container ...
Checking iptables default rule ...
Checking br_netfilter module ...
Checking sysctl variables ...
Check successful, ready to run 'up' command ...
Waiting for kubeadm to setup master cluster...
Please wait ...
| - 0% completed

Running on macOS 10.12.6:

VirtualBox 5.2.12 r122591 (Qt5.6.3)
Vagrant 2.1.1

How "patient" should I be? And/or what am I doing wrong?

For the Oracle Database 12.2.0.1 box, would you consider an enhancement to allow optional configuration of the system time zone via an environment variable in the Vagrantfile? When the OS default (UTC) is used, it can lead to confusing SYSDATE/SYSTIMESTAMP results when querying the database (unless one is in the UTC time zone, of course). Allowing configuration of the system time zone would make it easier for developers to get results that are consistent with their production databases.

This proposed enhancement would involve adding a bullet point at the end of the Customization section of README.md, and adding a block similar to the following in the install.sh script:

# set system time zone if requested
if [ "$SYSTEM_TIMEZONE" ]; then
   sudo timedatectl set-timezone $SYSTEM_TIMEZONE
   echo "INSTALLER: System time zone set to $SYSTEM_TIMEZONE"
fi

For the Oracle Linux Vagrantfile, SSH port forwarding isn't necessary as this is done automatically and dynamically by Vagrant. Also, Vagrant boxes for Oracle Linux have SSH password authentication turned off by default. The only way to SSH into the VM would be using the command vagrant ssh. It might also be worthwhile updating the README.

Warning Failed 46m kubelet, worker2.vagrant.vm Error: failed to start container "redis": Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "process_linux.go:402: container init caused "rootfs_linux.go:58: mounting \"/var/lib/docker/containers/580067f71fdb3e160cccd4cb0c11b2a50e625f2db8ba974677ed43ad839897e0/resolv.conf\" to rootfs \"/var/lib/docker/btrfs/subvolumes/9e0aa231ac7e714db5f7a496cfe0c3836d1b28326085f3eeb532747afff1b3bd\" at \"/var/lib/docker/btrfs/subvolumes/9e0aa231ac7e714db5f7a496cfe0c3836d1b28326085f3eeb532747afff1b3bd/etc/resolv.conf\" caused \"open /var/lib/docker/btrfs/subvolumes/9e0aa231ac7e714db5f7a496cfe0c3836d1b28326085f3eeb532747afff1b3bd/etc/resolv.conf: read-only file system\""": unknown

Hi Team:

Is there a Vagrant box available for Oracle BCC (Business Control Center) ? I could not find it in this repository. Will be very helpful if it can be added.

Thanks.
Sachin

In Kubernetes vagrantfile changed MANAGE_FROM_HOST flag to true to access Kubernetes from vagrant host. Using admin.conf generated in vagrant host to connect to kubenetes cluster from kubectl.
Command:
$ kubectl get nodes
Output:
Unable to connect to the server: x509: certificate is valid for 10.96.0.1, 192.168.99.100, not 127.0.0.1

Please help to resolve this issue.

I build a Pracle XE 18 c box straight from the vagratnt file in '18.4.0-XE'.
When I try ti log in in EM I get several times the message box 'Critical Error LOGGIN_FAIL_ACCESSABILITY' and when I try to log in I get 'Critical Error fail to parse data returned by server'.

I have no prblem to log into the atabase with SQL Developer.
Any ideas what is going on here ?

The install.sh script for the Oracle Database 11.2.0.2 box unzips the installer file (oracle-xe-11.2.0-1.0.x86_64.rpm.zip) to /vagrant. This creates a directory called /vagrant/Disk1. After Oracle XE is installed, install.sh tries to remove this directory. However, two of the files under /vagrant/Disk1 are extracted without write permissions:

[vagrant@oracle11g-xe-vagrant ~]$ ls -l /vagrant/Disk1/response/xe.rsp /vagrant/Disk1/upgrade/gen_inst.sql
-r-xr-xr-x. 1 vagrant vagrant  2748 May 16  2011 /vagrant/Disk1/response/xe.rsp
-r-xr-xr-x. 1 vagrant vagrant 10285 Aug 29  2011 /vagrant/Disk1/upgrade/gen_inst.sql

As a result, the rm -rf /vagrant/Disk1 command doesn't fully remove the directory. The following messages are shown during vagrant up when install.sh tries to remove the directory:

oracle11g-xe-vagrant: rm: cannot remove ‘/vagrant/Disk1/response/xe.rsp’: Operation not permitted
oracle11g-xe-vagrant: rm: cannot remove ‘/vagrant/Disk1/upgrade/gen_inst.sql’: Operation not permitted

This causes a couple of problems:

• After a vagrant destroy, the user must change permissions on the two files and remove /vagrant/Disk1. If this isn't done before a subsequent vagrant up operation, unzipping the installer will fail, and Oracle XE won't be installed.
• It's easy to accidentally commit the two files in git.

A simple solution is to change permissions on the directory /vagrant/Disk1 before removing it. Adding the command chmod -R o+w /vagrant/Disk1 in install.sh immediately before the rm -rf /vagrant/Disk1 command fixes the issue.

Since this is a minor change, I'll go ahead and submit a pull request.

Is there a possibility to provision Oracle Linux with Oracle Database 11.2.0.4 EE?

Thanks