Another feature introduced with Oracle Linux 7.1 is support for Secure Boot.
If Secure Boot is enabled on a system (typically desktop, but in some cases also servers) - the system can have an embedded certificate (in firmware). This certificate can be one that's uploaded to the system by the admin or it could be one provided by the OEM/OS vendor. In many cases, in particular newer desktops, the system already contains the Microsoft key. (there can be more than one certificate uploaded...). When the firmware loads the boot loader, it verifies/checks the signature of this bootloader with the key stored in firmware before continuing. This signed bootloader (at this point trusted to continue) will then load a signed kernel, or signed second stage boot loader and verify it before starting and continuing the boot process. This creates what is called a chain of trust through the boot process.
We ship a 1st stage bootloader with Oracle Linux 7.1 which is a tiny "shim" layer that is signed by both Microsoft and Oracle. So if a system comes with Secure Boot support, and already ships the microsoft PK, then the shim layer will be started, verified, and if it passes verification, it will then load grub2 (the real bootloader). grub2 is signed by us (Oracle). The signed/verified shim layer contains the Oracle key and will validate that grub2 is ours (signed), if verification passes, grub2 will load the Oracle Linux kernel, and the same process takes place, our kernel is signed by us (Oracle) and grub2 will validate the signature prior to allowing execution of the kernel. Once the kernel is running, all kernel modules that we ship as part of Oracle Linux whether it's standard included kernel modules as part of the kernel RPM or external kernel modules used with Oracle Ksplice, are also signed by Oracle and the kernel will validate the signature prior to loading these kernel modules.
Enabling loading and verification of signed kernel modules is done by adding enforcemodulesig=1 to the grub kernel option line. In enforcing mode, any kernel module that is attempted to be loaded that's not signed by Oracle will fail to load.
If a system has Secure Boot support but a sysadmin wants to use the Oracle signature instead, we will make our certificate available to be downloaded securely from Oracle and then this can be uploaded into the firmware key database.
One update in Oracle linux 7 update 1 that I wanted to point out is the convenience of upgrading to MySQL 5.6 at install time. Oracle Linux 7 GA includes MariaDB 5.5 (due to our compatibility commitment in terms of exact packages and the same packages) and we added MySQL 5.6 RPMs on the ISO image (and in the yum repo channels online). So while it was easy for someone to download and upgrade from MariaDB 5.5 to MySQL 5.6 there was no install option. Now with 7.1 we included an installation option for MySQL. So you can decide which database to install in the installer or through kickstart with @mariadb or @mysql as a group. Again, MariaDB 5.5 is also part of Oracle Linux 7.1 and any users that are looking for strict package compatibility will see that we are very much that. All we have done is make it easy to have a better alternative option (1) conveniently available and integrated (2) without any compatibility risks whatsoever so you can easily run the real standard that is MySQL. A bug fix if you will.
I have a little screenshot available here.
You can find an overview of the feature in the Oracle Database Administrator's Guide. Basically, if you have flash devices attached to your server, you can use this flash memory to increase the size of the buffer cache. So instead of aging blocks out of the buffer cache and having to go back to reading them from disk, they move to the much, much faster flash storage as a secondary fast buffer cache (for reads, not writes).
Some scenarios where this is very useful : you have huge tables and huge amounts of data, a very, very large database with tons of query activity (let's say many TB) and your server is limited to a relatively small amount of main RAM - (let's say 128 or 256G). In this case, if you were to purchase and add a flash storage device of 256G or 512G (example), you can attach this device to the database with the Database Smart Flash Cache feature and increase the buffercache of your database from like 100G or 200G to 300-700G on that same server. In a good number of cases this will give you a significant performance improvement without having to purchase a new server that handles more memory or purchase flash storage that can handle your many TB of storage to live in flash instead of rotational storage.
It is also incredibly easy to configure.
-1 install Oracle Linux (I installed Oracle Linux 6 with UEK3)
-2 install Oracle Database 12c (this would also work with 11g - I installed 22.214.171.124.0 EE)
-3 add a flash device to your system (for the example I just added a 1GB device showing up as /dev/sdb)
-4 attach the storage to the database in sqlplus
$ ls /dev/sdb /dev/sdb $ sqlplus '/ as sysdba' SQL*Plus: Release 126.96.36.199.0 Production on Tue Feb 24 05:46:08 2015 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 188.8.131.52.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> alter system set db_flash_cache_file='/dev/sdb' scope=spfile; System altered. SQL> alter system set db_flash_cache_size=1G scope=spfile; System altered. SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 4932501504 bytes Fixed Size 2934456 bytes Variable Size 1023412552 bytes Database Buffers 3892314112 bytes Redo Buffers 13840384 bytes Database mounted. Database opened. SQL> show parameters flash NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_flash_cache_file string /dev/sdb db_flash_cache_size big integer 1G db_flashback_retention_target integer 1440 SQL> select * from v$flashfilestat; FLASHFILE# ---------- NAME -------------------------------------------------------------------------------- BYTES ENABLED SINGLEBLKRDS SINGLEBLKRDTIM_MICRO CON_ID ---------- ---------- ------------ -------------------- ---------- 1 /dev/sdb 1073741824 1 0 0 0
You can get more information on configuration and guidelines/tuning here. If you want selective control of which tables can use or will use the Database Smart Flash Cache, you can use the ALTER TABLE command. See here. Specifically the STORAGE clause. By default, the tables are aged out into the flash cache but if you don't want certain tables to be cached you can use the NONE option.
alter table foo storage (flash_cache none);This feature can really make a big difference in a number of database environments and I highly recommend taking a look at how Oracle Linux and Oracle Database 12c can help you enhance your setup. It's included with the database running on Oracle Linux.
Here is a link to a white paper that gives a bit of a performance overview.
There are 2 ways to use the Ksplice service :
The RPM is updated whenever a new ksplice patch becomes available. So you always have 1 RPM installed for a given kernel, and this RPM gets updated. This was standard yum / rpm commands can be used to update your server(s) with ksplice patches as well and everything is nicely integrated.
The standard model is that an uptrack-upgrade command will apply all updates to current/latest on your server. This is of course the preferred way of applying security fixes on your running system, it's best to be on the latest version. However, in some cases, customers want more fine-grained control than latest.
We just did an update of the ksplice offline tools to add support for updating to a specific "kernel version". This way, if you are on kernel version x, you would like to go to kernel version y (effective patches/security fixes) but latest is kernel version z, you can tell uptrack-upgrade to go to kernel version y. Let me give a quick and simple example below. I hope this is a useful addition to the tools.
happy holidays and happy ksplicing!
To install the tools, make sure that your server(s) has access to the ol6_x86_64_ksplice channel (if it's OL6) :
$ yum install uptrack-offline
Now, in my example, I have Oracle Linux 6 installed with the following version of UEK3 :
$ uname -r 3.8.13-44.1.1.el6uek.x86_64
Let's check if updates are available :
$ yum search uptrack-updates-3.8.13-44.1.1 Loaded plugins: rhnplugin, security This system is receiving updates from ULN. =========== N/S Matched: uptrack-updates-3.8.13-44.1.1.el6uek.x86_64 =========== uptrack-updates-3.8.13-44.1.1.el6uek.x86_64.noarch : Rebootless updates for the ...: Ksplice Uptrack rebootless kernel update service
As I mentioned earlier, for each kernel there's a corresponding ksplice update RPM. Just install that. In this case, I run 3.8.13-44.1.1.
$ yum install uptrack-updates-3.8.13-44.1.1.el6uek.x86_64.noarch Loaded plugins: rhnplugin, security This system is receiving updates from ULN. Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package uptrack-updates-3.8.13-44.1.1.el6uek.x86_64.noarch 0:20141216-0 will be installed --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: uptrack-updates-3.8.13-44.1.1.el6uek.x86_64 noarch 20141216-0 ol6_x86_64_ksplice 39 M Transaction Summary ================================================================================ Install 1 Package(s) Total download size: 39 M Installed size: 40 M Is this ok [y/N]: y Downloading Packages: uptrack-updates-3.8.13-44.1.1.el6uek.x86_64-20141216-0.n | 39 MB 00:29 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : uptrack-updates-3.8.13-44.1.1.el6uek.x86_64-20141216-0.noa 1/1 The following steps will be taken: Install [b9hqohyk] CVE-2014-5077: Remote denial-of-service in SCTP on simultaneous connections. ... ... Installing [vtujkei9] CVE-2014-6410: Denial of service in UDF filesystem parsing. Your kernel is fully up to date. Effective kernel version is 3.8.13-55.1.1.el6uek Verifying : uptrack-updates-3.8.13-44.1.1.el6uek.x86_64-20141216-0.noa 1/1 Installed: uptrack-updates-3.8.13-44.1.1.el6uek.x86_64.noarch 0:20141216-0 Complete!
There have been a ton of updates released since 44.1.1, and the above update gets me to effectively running 3.8.13-55.1.1. Of course, without a reboot.
$ uptrack-uname -r 3.8.13-55.1.1.el6uek.x86_64
Now we get to the new feature. There's a new option in uptrack-upgrade that lists all effective kernel versions from the installed kernel to the latest based on the ksplice rpm installed.
$ uptrack-upgrade --list-effective Available effective kernel versions: 3.8.13-44.1.1.el6uek.x86_64/#2 SMP Wed Sep 10 06:10:25 PDT 2014 3.8.13-44.1.3.el6uek.x86_64/#2 SMP Wed Oct 15 19:53:10 PDT 2014 3.8.13-44.1.4.el6uek.x86_64/#2 SMP Wed Oct 29 23:58:06 PDT 2014 3.8.13-44.1.5.el6uek.x86_64/#2 SMP Wed Nov 12 14:23:31 PST 2014 3.8.13-55.el6uek.x86_64/#2 SMP Mon Dec 1 11:32:40 PST 2014 3.8.13-55.1.1.el6uek.x86_64/#2 SMP Thu Dec 11 00:20:49 PST 2014
So as an example, let's say I want to update from 44.1.1 to 44.1.5 instead of to 55.1.1 (for whatever reason I might have). All I have to do, is run uptrack-upgrade to go to that effective kernel version.
Let's start with removing the installed updates and go back from 55.1.1 to 44.1.1 and then upgrade again to 44.1.5 :
$ uptrack-remove --all ... $ uptrack-upgrade --effective="3.8.13-44.1.5.el6uek.x86_64/#2 SMP Wed Nov 12 14:23:31 PST 2014" ... ... Effective kernel version is 3.8.13-44.1.5.el6uek
And that's it.