Linux: Changing IP Address and Other Network Configurations in Linux.

Changing Network IP and Other Network Configurations:
Chadap: Nov6, 2018.

1: Open Terminal.

2: Open network configuration file. In this example, it’ll configure on interface ens160 in our example. Type
vi /etc/sysconfig/network-scripts/ifcfg-ens160

Opens NIC’s configuration file

3: The current configuration.
TYPE=”Ethernet”
PROXY_METHOD=”none”
BROWSER_ONLY=”no”
BOOTPROTO=”none”
DEFROUTE=”yes”
IPV4_FAILURE_FATAL=”no”
IPV6INIT=”yes”
IPV6_AUTOCONF=”yes”
IPV6_DEFROUTE=”yes”
IPV6_FAILURE_FATAL=”no”
IPV6_ADDR_GEN_MODE=”stable-privacy”
NAME=”ens160″
UUID=”2441c82d-bdd0-425c-bff7-71ddda1f2af2″
DEVICE=”ens160″
ONBOOT=”yes”
IPADDR=”XXX.XX.XXX.XX”
PREFIX=”26″
GATEWAY=”—.–.—.-”
DNS1=”—.–.—.-”
DNS2=”—.–.—.-”
DOMAIN=”—————”
IPV6_PRIVACY=”no”

4: Modify the file by press ‘i’ to enter insert mode. Change BOOTPROTO to static and add IP Address and Net mask as new lines if they’re not existed yet..
BOOTPROTO=static
IPADDR=172.17.254.20
NETMASK=255.255.255.0

Save the configuration file.
Exit the vi editor

5: Restart the network interface card. Type
service network restart.

Please note you will be disconnected from your session.
Give it a few min and reopen the terminal session.

7: See if the changes went into effect. Type
ifconfig

The new changes should be in effect for the NIC in question.

Oracle Security: Setting the AUDIT_SYSLOG_LEVEL Parameter. Oracle 11g.

Nov 11, 2018.
Setting the AUDIT_SYSLOG_LEVEL Parameter. Oracle 11g. REHL6 (Onwards).

APPLIES TO:
Oracle Database – Enterprise Edition – Version 10.2.0.1 to 11.2.0.4 [Release 10.2 to 11.2]
ALL platforms.

ISSUE:
Because of Infosec dictate we are required to port/export our DB logs to OS rsyslog.
Example: If the ‘Connect’ audit trail is enabled in the DB, the requirement would be to write these connect logs to OS rsyslogs.

SOLUTION:
AUDIT_SYSLOG_LEVEL parameter. When the AUDIT_TRAIL parameter is set to OS, writes DB audit records to the system audit log using the rsyslog utility.

To enable syslog auditing for all the users (privileged or not privileged), you assign a value of OS to the AUDIT_TRAIL initialization parameter, as described in “Setting the AUDIT_TRAIL Initialization Parameter”.  You assign to the AUDIT_SYSLOG_LEVEL parameter a facility and priority in the format AUDIT_SYSLOG_LEVEL=facility.priority. The facility argument describes the part of the operating system that is logging the message while the priority argument defines the severity of the message. The syslog daemon compares the value assigned to the facility argument of the AUDIT_SYSLOG_LEVEL parameter with the rsyslog.conf file in order to determine where to log information. For example, the following statement identifies the facility as local1 with a priority level of warning:

AUDIT_SYSLOG_LEVEL=local1.warning

Setting the AUDIT_SYSLOG_LEVEL initialization parameter to the default value
(NONE) will result in DBAs gaining access to the OS audit records.

To enable syslog auditing, follow these steps:

Assign a value of OS to the AUDIT_TRAIL initialization parameter:

For example:

SQL> ALTER SYSTEM SET AUDIT_TRAIL=OS SCOPE=SPFILE;
Options available for us:
Values:< BR>NONE

Disables standard auditing. This value is the default if the AUDIT_TRAIL parameter was not set in the initialization parameter file or if you created the database using a method other than Database Configuration Assistant. If you created the database using Database Configuration Assistant, then the default is db.

OS
Directs all audit records to an operating system file. Oracle recommends that you use the os setting, particularly if you are using an ultra-secure database configuration.

DB
Directs audit records to the database audit trail (the SYS.AUD$ table), except for records that are always written to the operating system audit trail. Use this setting for a general database for manageability.
If the database was started in read-only mode with AUDIT_TRAIL set to db, then Oracle Database internally sets AUDIT_TRAIL to os. Check the alert log for details.

DB, EXTENDED
Performs all actions of AUDIT_TRAIL=db, and also populates the SQL bind and SQL text CLOB-type columns of the SYS.AUD$ table, when available. These two columns are populated only when this parameter is specified.
If the database was started in read-only mode with AUDIT_TRAIL set to db, extended, then Oracle Database internally sets AUDIT_TRAIL to os. Check the alert log for details.

XML
Writes to the operating system audit record file in XML format. Records all elements of the AuditRecord node except Sql_Text and Sql_Bind to the operating system XML audit file.

XML, EXTENDED
Performs all actions of AUDIT_TRAIL=xml, and includes SQL text and SQL bind information in the audit trail.

Also set the AUDIT_SYSLOG_LEVELparameter.

SQL> ALTER SYSTEM SET AUDIT_SYSLOG_LEVEL=”local1.warning” SCOPE=SPFILE;
Set the AUDIT_SYSLOG_LEVEL parameter to specify a facility and priority in the format AUDIT_SYSLOG_LEVEL=facility.priority.
facility: Describes the part of the operating system that is logging the message. Accepted values are user, local0–local7, syslog, daemon, kern, mail, auth, lpr, news,uucp, andcron.

The local0–local7 values are predefined tags that enable you to sort the syslog message into categories. These categories can be log files or other destinations that the syslog utility can access.

priority: Defines the severity of the message. Accepted values are notice, info, debug, warning, err, crit, alert, and emerg.

The syslog daemon compares the value assigned to the facility argument of the AUDIT_SYSLOG_LEVEL parameter with the syslog.conf file to determine where to log the information.  The decision where to write the syslog entries does not belong to the Oracle services, but to the syslog daemon.

For example, the following statement identifies the facility as local1 with a priority level of warning:

AUDIT_SYSLOG_LEVEL=local1.warning

Add the audit file destination to the rsyslog configuration file /etc/rsyslog.conf.

For example, assuming you had set the AUDIT_SYSLOG_LEVEL to local1.warning, enter the following:

local1.warning    /var/log/audit.log

This setting logs all warning messages to the /var/log/audit.log file.

Comment: separate the entries in syslogd.conf by using TAB rather than spaces, otherwise it may not work for all syslogd versions, so the above would really be:

local1.warning<tab><tab>/var/log/audit.log

Also pre-create the file as follows (as root):

# touch /var/log/audit.log

The facility line for your messages in the file rsyslog.conf should appear before the “catch all” setting and you should include appropriate .none entry to “catch all” also.

Once the changes are made to the rsyslog.conf, restart the rsyslog service.

#systemctl restart rsyslog.servic

If you get a message like so:
Redirecting to /bin/systemctl restart syslog.service
Failed to restart syslog.service: Unit not found.

Then you are actually running rsyslog.
Make sure the changes are made to /etc/rsyslog.conf
#service rsyslog restart

 

 

 

 

 

 

Linux: Changing Hostname on a Linux Server.

10/22/2018
Changing Hostname On a Linux Server.

The manual method
This method will work on nearly any Linux distribution.

Before we get into this method, do note it will require you to reboot the server. Otherwise,
the new hostname will not go into effect and you could wind up with some random issues—depending
upon what your server is used for.

Open up a terminal window. We can find out what our current  hostname is by issuing the command hostname.

To modify the hostname, we need to modify two files.

vi /etc/hostname.
In this file you will see a single line that contains your system hostname. Edit that line to reflect the new hostname.
Once you’ve done that, save and close the file.

Now We modify  /etc/hosts file.
vi /etc/hosts
In this file, you’ll want to change any instance of the old hostname to reflect the new hostname.
There should only be one entry/line to change.

Save the file.
Exit.
Reboot.

Once it is up the new hostname should take effect. Open a terminal window. Issue hostname command.
You will see the new name within the prompt.

Notes on VM Linux node existing within a windows infrastructure.
When we change the hosts file and the hostname above the DNS entries local to the Linux VM node will change to the new name, BUT, if we are
connecting to this from a Windows system, say, a remote putty session or any other remote session connect, then the DNS entries withing the
Windows domain need to be changed to point at at the new hostname.

10/22/2018

Oracle PSU and CPU Security Patching.

Oracle: PSU and CPU Patching for Oracle Databases.
September 27, 2018

Oracle provides Critical Patch Updates every qtr.
The dates for these updates, in 2018/2019, are:

October 16, 2018
January 15, 2019
April 16, 2019
July 16, 2019

We are going to look at PSU (Patch Set Update) and CPU (Critical Patch Update) released on July 17, 2018
for Linux x86-64 system and Oracle Version 11.2.0.4.0.

1: PSU Patch:
Patch 27734982: DATABASE PATCH SET UPDATE 11.2.0.4.180717
You will need oracle Support.
https://support.oracle.com/epmos/faces/PatchHome

Download the complete ‘Read Me’ document for expanded instructions when you are downloading the patch. Below are shown some important steps for Installation.

A: Environment checks:
Ensure that the $PATH definition has the following executables: make, ar, ld, and nm.
The location of these executables depends on your operating system. On many operating systems, they are located in /usr/ccs/bin, in which case you can set your PATH definition as follows:
export PATH=$PATH:/usr/ccs/bin

B: One-off Patch Conflict Detection and resolution:
Determine whether any currently installed one-off patches conflict with the PSU patch as follows:
unzip p27734982_112040_<platform>.zip
cd 27734982
opatch prereq CheckConflictAgainstOHWithDetail -ph ./

The report will indicate the patches that conflict with PSU 27734982 and the patches for which PSU 27734982 is a superset.
Note that Oracle proactively provides PSU one-off patches for common conflicts with this patch.

C: Patch Installation:
*** Ensure that you shut down all the services running from the Oracle home (listner, DB, whatever)
1. If you are using a Data Guard Physical Standby database, you must install this patch on both the primary database and the physical standby database, as described by My Oracle Support Document 278641.1.
2. If this is an Oracle RAC environment, install the PSU patch using the OPatch rolling (no downtime) installation method as the PSU patch is rolling Oracle RAC installable. Refer to My Oracle Support Document 244241.1 Rolling Patch – OPatch Support for RAC.
3. If this is not a Oracle RAC environment, shut down all instances and listeners associated with the Oracle home that you are updating. For more information, see Oracle Database Administrator’s Guide.
4. Rollback any patches found during the One-off Patch Conflict Detection.
5. Set your current directory to the directory where the patch is located and then run the OPatch utility by entering the following commands:
6. unzip p27734982_112040_<platform>.zip
7. cd 27734982
8. opatch apply
9. Install all resolutions to conflicts found during the One-off Patch Conflict Detection.

D: Post Patch:
Loading Modified SQL Files into the Database
The following steps load modified SQL files into the database. For an Oracle RAC environment, perform these steps on only one node.
1. For each database instance running on the Oracle home being patched, connect to the database using SQL*Plus. Connect as SYSDBA and run the catbundle.sql script as follows:
2. cd $ORACLE_HOME/rdbms/admin
3. sqlplus /nolog
4. SQL> CONNECT / AS SYSDBA
5. SQL> STARTUP
6. SQL> @catbundle.sql psu apply
7. SQL> QUIT
Running the above may make some objects invalid. To correct that:
8. cd $ORACLE_HOME/rdbms/admin
9. sqlplus /nolog
10. SQL> CONNECT / AS SYSDBA
11. SQL> @utlrp.sql

2: CSU Patch:
Patch 27923163: DATABASE PATCH SET UPDATE 11.2.0.4.180717

Download the complete ‘Read Me’ document for expanded instructions. Below are shown some important steps for Installation.

A: Environment checks:
Ensure that the $PATH definition has the following executables: make, ar, ld, and nm.
The location of these executables depends on your operating system. On many operating systems, they are located in /usr/ccs/bin, in which case you can set your PATH definition as follows:
export PATH=$PATH:/usr/ccs/bin

B: One-off Patch Conflict Detection and resolution:
Determine whether any currently installed one-off patches conflict with the PSU patch as follows:
unzip p27923163_11204_<platform>.zip
cd 27923163
opatch prereq CheckConflictAgainstOHWithDetail -ph ./

The report will indicate the patches that conflict with CSU 27923163 and the patches for which CSU 27923163 is a superset.
Note that Oracle proactively provides CSU one-off patches for common conflicts with this patch.

C: Patch Installation:
*** Ensure that you shut down all the services running from the Oracle home (listner, DB, whatever)
1. If you are using a Data Guard Physical Standby database, you must install this patch on both the primary database and the physical standby database, as described by My Oracle Support Document 278641.1.
2. If this is an Oracle RAC environment, install the PSU patch using the OPatch rolling (no downtime) installation method as the PSU patch is rolling Oracle RAC installable. Refer to My Oracle Support Document 244241.1 Rolling Patch – OPatch Support for RAC.
3. If this is not a Oracle RAC environment, shut down all instances and listeners associated with the Oracle home that you are updating. For more information, see Oracle Database Administrator’s Guide.
4. Rollback any patches found during the One-off Patch Conflict Detection.
5. Set your current directory to the directory where the patch is located and then run the OPatch utility by entering the following commands:
6. unzip p27923163_11204_<platform>.zip
7. cd 27923163
8. $opatch apply
9. Verify whether the patch has been successfully installed by running the following command:
10. $ opatch lsinventory
11. Install all resolutions to conflicts found during the One-off Patch Conflict Detection.

D: Post Patch :
Loading Modified SQL Files into the Database
1. Install the SQL portion of the patch by running the following command for a single instance environment.
2. cd $ORACLE_HOME/sqlpatch/27923163
3. sqlplus /nolog
4. SQL> CONNECT / AS SYSDBA
5. SQL> startup upgrade
6. SQL> @postinstall.sql
7. SQL> shutdown
8. SQL> startup
For an Oracle RAC environment, reload the packages on one of the nodes using the following commands. Make sure no other instance of the database is up on the remote nodes.
cd $ORACLE_HOME/sqlpatch/27923163
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> alter system set cluster_database=false scope=spfile;
SQL> SHUTDOWN
SQL> STARTUP UPGRADE
SQL> @postinstall.sql
SQL> alter system set cluster_database=true scope=spfile;
SQL> SHUTDOWN
SQL> STARTUP
Running the above may make some objects invalid. To correct that:
8. cd $ORACLE_HOME/rdbms/admin
9. sqlplus /nolog
10. SQL> CONNECT / AS SYSDBA
11. SQL> @utlrp.sql