I have created a script to add trusted certificate chains to an orapki wallet from the Linux command line, and there is no web browser needed. It reads sites from a list and adds the certificate chains of those sites to an
orapki (auto login) wallet.
Start the script with
./certs_to_wallet.sh <path to wallet> . This will prompt you for a NEW wallet (auto login) creation. The old wallet will be backed-up. In case of permission of password errors, the backup will be restored.
It reads a
wallet_sites.lst file from the current directory or the wallet directory. The wallet directory takes preference, so you can have a list of sites per wallet. A site per line will be processed and the certificate chain will be added to the given wallet (the last line should be empty).
This weekend Oracle updated to oVirt 4.3, Yeah! See instruction below how to upgrade to oVirt 4.3 and if/when you version locked the sos package.
Oracle was still using oVirt Release 4.2 repositories for Oracle Linux 7.7. The vdsm-4.20.46 conflicted with sos 3.7-11 from the ‘latest’ Oracle Linux 7 repository, which features Oracle Linux 7.7, not 7.6.
The fix is in vdsm-4.30.something, from the oVirt 4.3 repo’s, and now they are offering it!
When you get ‘Command returned failure code 1 during SSH session’ during adding a KVM host with the Oracle Linux Virtualization Manager, there might be something wrong with the libvertd deamon on the host you want to add.
I had this issue with adding a Oracle Linux 7.7 host.
Please check on the KVM host the following:
During an upgrade to 22.214.171.124 and in the step running GRID root scripts, the upgrade fails with:
[DCS-10001:Internal error encountered: Fail to run root scripts..]
After that if you run the upgrade again, you will get the following error:
[DCS-10001:Internal error encountered: Fail to extract the GI clone file.]
When I got there error’s, I found in the logging (/u01/app/126.96.36.199/grid/install/root_<host_name>_<date>_<time>-<more_numbers>.log) that there was no PKI trust set up between the ODA and ‘itself’ (aka passwordless login). The Oracle GRID upgrade works by accessing all the nodes in it’s cluster via ssh, including itself. But This was a single (non HA) machine (X6-2M), so did not expect it. Continue reading
Shown are the latest kernel versions as of the 9th of January which have Meltdown and Spectre patches.
Kernel versions can be found when running the `uname -r` command.
After the kernel is installed one can find the kernel/packages changelog and security info with the following commands and see in the page table isolation has been activated:
# yum updateinfo list
# yum updateinfo list cves
# yum updateinfo list kernel-uek
# yum updateinfo list --sec-severity=Important
# yum updateinfo info --sec-severity=Important
CVE-2017-1000407 Important/Sec. kernel-uek-4.1.12-112.14.13.el7uek.x86_64
# dmesg | grep isolation
[ 0.000000] Kernel/User page tables isolation: enabled
# rpm -q --changelog kernel | egrep 'CVE-2017-5715|CVE-2017-5753|CVE-2017-5754'
# rpm -q --changelog kernel-uek | egrep 'CVE-2017-5715|CVE-2017-5753|CVE-2017-5754'
Oracle Linux version 6
Kernel: 2.6.32-696.18.7 (errata: ELSA-2018-0008), 2018-01-04.
Kernel-uek: 4.1.12-112.14.10 (errata: ELSA-2018-4006), 2018-01-09.
Oracle Linux version 7
Kernel: 3.10.0-693.11.6 (errata: ELSA-2018-0007), 2018-01-04.
Kernel-uek: 4.1.12-112.14.10 (errata: ELSA-2018-4006), 2018-01-04.
Oracle VM version 3.4
Xen: 4.4.4-155.0.12.el6 (errata: OVMSA-2018-0006), 2018-01-08.
Following is tested with Oracle 12.1 on Linux 6 (on Exadata) and a Windows 10 client.
“Yet another blog on how to authenticate database users against Active Director using Kerberos…”
I have read and tried a view blogs on how to get this done, but somehow I have found them a bit limited because they talk about a simple configuration with one database on one host. When you have to deal with multiple hosts and multiple databases per host, you need to take some things into account.
Lets start with some explanations, a walk through is below that.
- Unsupported ParametersThe following parameters are no longer supported:
No it’s not!
If you leave it out, you will get:
Password for airell@[logging]:
In stead of:
Password for airell@DOMAIN.LOCAL:
If you leave it out, one must not use the MIT layout… but where is the non-MIT layout described? It looks like the domain must be present on the first line of the file… for now, I will still use the MIT layout.
REHL 7 and Oracle Linux 7 was not released when Oracle database 188.8.131.52 came out, so the installer does give some issues in the pre-requisites and when installing the software. I advice to do a software only installation first, because of an issue that you will need to fix with a patch after software installation, but before creating a database.
These issues popped-up when I was installing a 184.108.40.206 database on RHEL7 (not a Certified product combination!), but the solutions given for 220.127.116.11 worked for it as well:
- elfutils-libelf-devel package missing;
- compat-libstdc++ package missing;
- pdksh package missing;
- “Error in invoking target ‘agent nmhs’ of makefile” when installing.
- This one also counts for installing Oracle Fusion Middleware.
I ran into a situation where tnsping and other connections like ssh and such took at least 5 seconds (5000 msec) to establish:
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = host.domain.local)(PORT = 1521))
(CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = ORCL)))
OK (5010 msec)
Also connecting to ‘host.domain.local’ with ssh took about 5 seconds. At first I thought it had to with sshd and some authentication options which had to timeout first, but than I discovered tnsping also waits 5 seconds. When connecting to the ip address it took 0 msec… aha… a DNS thing?! Continue reading
I recently upgraded by OVM to 3.4.3(.1511), but now my Oracle Enterprise Linux 6.9 PVM guests won’t start up any more. They don’t finish the ‘Starting automount’ in the boot / startup screen. It does not fail, it just won’t continue.
There is nothing special in the /etc/fstab I guess… : Continue reading