Sunday, November 13, 2022

SQLNET.ORA file got modified by OCI VM DB System upgrade

 In my last post https://samappsdba.blogspot.com/2022/11/upgrade-oracle-db-to-1916-on-oci-vm-db.html, i explaained the steps on how we did the patchset upgrade from 19.7 to 19.6 for OCI VM DB System. The activity was performed through Console. All the steps were done seamlessly but what we observed after the upgrade was that the SQLNET.ORA file was being modified. Now the SQLNET.ORA contains the DB wallet location.




As the wallet location were modifed, we had issues on querying the DBA tables.




The wallet information stord in controlfile and the wallet information stored in ewallet.p12 file was not matching. And because of this mismatch, we were getting the issue.

We had one backup taken before the upgrade from the console. We used the same backup to create a separate a new VM DB System and then copied the correct wallets. Once the correct wallets were placed in the desinated directory, the SQLNET.ORA file was modified so that it points to correct wallet location. At last bounced the database and we then were able to query the DBA tables. From this post, i just want to emphasize some points which are not mentioned clearly in the documentations from oracle.

1. Have a full backup of the database taken before the upgrade

2. Take the full backup of the files placed under $ORACLE_HOME/network/admin, especially the sqlnet.ora file

3. Once the upgrade is complete, validate the files under $ORACLE_HOME/network/admin and take a full backup of the database.


I hope this post will help someone. Till then, happy learning Cloud



Monday, November 7, 2022

upgrade oracle db to 19.16 on OCI VM DB Systems

 This post describes the steps on how we can upgrade the Oracle Database release 19.7 to 19.16  running on Oracle Cloud Infrastructure VM DB Systems. At the time of writing this post, 19.6 was the latest patchset available on the console. It is always advisable to go through the official documentations Upgrade your database from console. Also this note is not applicable for database running on ExaCS.

Prerequisites

The following are required in order to upgrade a database on a bare metal or virtual machine DB system:

The DB system must use Oracle Linux 7 (OL7)

If your DB System uses ASM storage management software, the system must use Oracle Grid Infrastructure 19c


Your Oracle database must be configured with the following settings in order to upgrade:

The database must be in archivelog mode.

The database must have flashback enabled. Your DB Recovery Dest should point to +RECO Diskgroup.


Before you proceed with the next steps, it is always advisable to take the full backup of the database. We had faced one major issue related to wallets which is not documented anywhere and this fullbackup helped us. I will blog this in my future posts.

 



Precheck

The Precheck gives you an option to upgrade the component for Grid Infrastructure as well as for the Database running on DB System. 

First, we did the upgrade for Grid Infrastructure and then we did it for Db System.




The Precheck ran for 10 mins.





Once the precheck is complete, we will click on "Apply".


Once the GI is moved to latest patchset, we will go the DB system and follow the same process






Post Upgrade Activity:-

1.     Verify if there are any errors in alert log.

2.     Verify the dba_registry

3.     In my case, this was the patchset upgrade but if you are doing a major upgrade, you need to decide when can you change the Compatible parameter. I normally do it after 1 week of upgrade. 

4.     Update the .bashrc to reflect the new Oracle Home. The tooling doesn't update it

5.     Take the manual backup and enable automatic backups if required

6.     Remove the Old Oracle home using DBCLI

 

 References:- https://docs.oracle.com/en-us/iaas/dbcs/doc/upgrade-database1.html

                     Daniel has published a wonderful blog on the major upgrade in this blog VM DB System DB upgrade

 

 


Sunday, September 18, 2022

DNS Load balancing via Traffic Steering Policy

 The Traffic Steering policy is an important component of DNS. Traffic Management Steering Policies facilitates intelligent response to the DNS queries based upon the policies we define. Traffic Management Steering Policies can account for health of answers to provide failover capabilities, provide the ability to load balance traffic across multiple resources, and account for the location where the query was initiated to provide a simple, flexible and powerful mechanism to efficiently steer DNS traffic. For more details, you can visit Oracle Docs



Image Courtesy:-Oracle Blog


Enough of the  theory, let us now jump to the demonstration. 

I have two web servers. One in Ashburn and one in Frankfurt region. 









Now create a public DNS Zone. I have my domain dumka.tk registered against Domain Registrar

Next, we will do the load balancing using the traffic Steering Policy










Once the policy is created, open the new browser and hit the domain name. We can see the response coming from from the 2 webservers respectively.



Refresh it



That's it for this post. I hope this post will be helpful for someone. Till, then keep learning cloud.


Monday, August 8, 2022

Implement OCI IPSec Site to Site VPN

 

This post explains step by step the VPN IPSec tunnel configuration in Oracle Cloud Infrastructure and how we can leverage IPSec to establish the connectivity from On premises network to resources provisioned in Oracle Cloud Infrastructure. There are two types of modes supported by IPSec and this post, i have used Tunnel Mode and which is also supported by Oracle. The entire communication between the source and destination sites is encrypted, significantly lowering the chances of information theft.




My Source On premise addresses are as follows

Source CIDR:-10.0.0.0/29

Public Router Address:-140.238.226.118

Server IP Address:-10.0.0.0.146


OCI CIDR Range:-192.168.0.0/26



VCN Setup





Create DRG

Go to Networking>Customer Connectivity>Dynamic Routing gateways




Attach the DRG to VCN










Create Route Table




Destination is: On Premise CIDR


Create Security list and add the respective ingress/egress 






Create the Regional private Subnet









Create the CPE








Create an IPSec Connection to CPE














At this moment, the IPSec Status will be down.


Also, i have one compute instance running on private subnet. We can have Database or any services running on private subnet


Configuration on the On Premise host


Install libreswan in the on prem compute instance



[root@webserver opc]# yum install libreswan

[root@webserver opc]# ipsec version

Linux Libreswan 4.5 (XFRM) on 5.4.17-2136.307.3.1.el8uek.x86_64

[root@webserver opc]#


Turning Linux instance into a IP Router Now we will configure Libreswan and enable IP forwarding feature in order to turn our Linux Instance into a Router

[root@webserver opc]# cat /etc/sysctl.conf

# sysctl settings are defined through files in

# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.

#

# Vendors settings live in /usr/lib/sysctl.d/.

# To override a whole file, create a new file with the same in

# /etc/sysctl.d/ and put new settings there. To override

# only specific settings, add a file with a lexically later

# name in /etc/sysctl.d/ and put new settings there.

#

# For more information, see sysctl.conf(5) and sysctl.d(5).


# Enable Panic on VMs on NMI trigger

kernel.unknown_nmi_panic = 1

net.ipv4.ip_forward=1

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.eth0.send_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

net.ipv4.conf.eth0.accept_redirects = 0

net.ipv4.conf.default.accept_source_route = 0

net.ipv6.conf.default.accept_source_route = 0

net.ipv4.conf.all.accept_redirects = 0

net.ipv6.conf.all.accept_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

net.ipv6.conf.default.accept_redirects = 0


[root@webserver opc]# vi /etc/ipsec.d/oci-ipsec.conf

conn oracle-tunnel-1

 left=10.0.0.146

 leftid=140.238.226.118 # See preceding note about 1-1 NAT device

 right=193.122.171.48

 authby=secret

 leftsubnet=10.0.0.0/29

 rightsubnet=192.168.0.0/28----VPN Address for tunnel

 auto=start

 mark=5/0xffffffff # Needs to be unique across all tunnels

 vti-interface=${vti1}

 vti-routing=yes

 ikev2=no # To use IKEv2, change to ikev2=insist

 ike=aes_cbc256-sha2_384;modp1536

 phase2alg=aes_gcm256;modp1536

 encapsulation=yes

 ikelifetime=28800s

 salifetime=3600s

conn oracle-tunnel-2

 left=10.0.0.146

 leftid=140.238.226.118 # See preceding note about 1-1 NAT device

 right=129.213.168.243-----VPN Address for Tunnel

 authby=secret

 leftsubnet=10.0.0.0/29

 rightsubnet=192.168.0.0/28

 auto=start

 mark=6/0xffffffff # Needs to be unique across all tunnels

 vti-interface=${vti2}

 vti-routing=yes

 ikev2=no # To use IKEv2, change to ikev2=insist

 ike=aes_cbc256-sha2_384;modp1536

 phase2alg=aes_gcm256;modp1536

 encapsulation=yes

 ikelifetime=28800s

 salifetime=3600s



Create ipsec secrets file


[root@webserver opc]# cat /etc/ipsec.d/oci-ipsec.secrets

140.238.226.118 193.122.171.48: PSK "fpLnW7HwiuEf5Fzu1PzHMVEVeFIszSUoaB4x2zgWtZyaNnk4kUrKZ3z5NIVFcWET"

140.238.226.118 129.213.168.243: PSK "0XczQpGij8GPr3GwPnXt9FSvefgD1UC4wgpxUCDufeSX7QBh6Ern0nWBRwuTUa59"

[root@webserver opc]#


Note: We can get the secret value from the view details section of the respective tunnels.


Restart the IPSec services

[root@webserver opc]#

 service ipsec restart


Verify the IPSec services

[root@webserver opc]# ipsec verify

Verifying installed system and configuration files

 

Version check and ipsec on-path                         [OK]

Libreswan 4.5 (XFRM) on 5.4.17-2136.307.3.1.el8uek.x86_64

Checking for IPsec support in kernel                    [OK]

 NETKEY: Testing XFRM related proc values

         ICMP default/send_redirects                    [OK]

         ICMP default/accept_redirects                  [OK]

         XFRM larval drop                               [OK]

Pluto ipsec.conf syntax                                 [OK]

Checking rp_filter                                      [ENABLED]

 /proc/sys/net/ipv4/conf/all/rp_filter                  [ENABLED]

  rp_filter is not fully aware of IPsec and should be disabled

Checking that pluto is running                          [OK]

 Pluto listening for IKE on udp 500                     [OK]

 Pluto listening for IKE/NAT-T on udp 4500              [OK]

 Pluto ipsec.secret syntax                              [OK]

Checking 'ip' command                                   [OK]

Checking 'iptables' command                             [OK]

Checking 'prelink' command does not interfere with FIPS [OK]

Checking for obsolete ipsec.conf options                [OK]

 

ipsec verify: encountered 3 errors - see 'man ipsec_verify' for help


Update the firewall rules

 

 

[root@webserver opc]# firewall-cmd --add-port=500/udp

success

[root@webserver opc]# firewall-cmd --add-port=4500/udp

success

[root@webserver opc]# firewall-cmd --runtime-to-permanent

success

[root@webserver opc]#


Update the Firewalls

[root@webserver opc]# firewall-cmd --add-port=500/udp

success

[root@webserver opc]# firewall-cmd --add-port=4500/udp

success

[root@webserver opc]# firewall-cmd --runtime-to-permanent

success

[root@webserver opc]#



Verify the tunnel status from the OCI Console







Now, you will be in a position to Ping and SSH to the compute instance running on OCI Private subnet.



References:-

Libreswan configuration: https://docs.cloud.oracle.com/iaas/Content/Network/Reference/libreswanCPE.htm?Highlight=shared%20secret

Oracle Cloud Infrastructure VPN Connect:https://docs.cloud.oracle.com/iaas/Content/Network/Tasks/managingIPsec.html

 

 

 

  

 


 

 

 

 


Monday, July 18, 2022

OCI load balancer redirection using Routing Policies

In Layman terms, load balancers helps in distributing the requests to the backend servers based upon certain algorithms. OCI Load Balancers helps in achieving high availability and scalability. Based upon our requirement we can induce multiple policies and application level health checks in OCI Load Balancer. In this post, i am going to demonstrate how we can leverage routing policies to redirect requests to backend servers using certain conditions. If you want to know how to create a Load balancer, you can refer to my earlier post https://samappsdba.blogspot.com/2020/05/configuring-oci-load-balancer-for-ebs.html

 I have a webserver1 with Public IP:-X.X.X.65. This is registered under DNS as dumka.tk 
I have an another webserver2 with Public IP:-X.X.X.61. This is registered under DNS as dumka.ml




Now i will create the Load balancer





I will add the backend later









Load balancer will now be created.

Add the backends now






Create listener for two backends






Now create the hostnames






Edit the listener and add the respective hostnames








Now Define the Routing Policies










At last, add the Public IP of the Load balancer to the DNS Zones.


Perform the testing








There are many other advanced configurations which we can use with our OCI Load Balancer for which we can go through the Advanced OCI LB Concepts. You can also refer my earlier post OCI LB Redirection on how i had used Path Route set for Load balance Redirection. This post is all about how using one Network load balancer, we can serve multiple websites using hostname and Routing policies. Hope this post helps someone. Keep learning cloud.