Search

Top 60 Oracle Blogs

Recent comments

linux

Changing Your Bash Shell Prompt and Colors

I enjoyed the opportunity to test out my PASS Summit shell scripting session at SQL Saturday Denver.  It was the first run on it and Glenn Berry sat in my session.  Afterwards, this wise and long-standing member of the community had a very valuable piece of constructive criticism-  change the background on my bash terminal for Azure Cloud Shell, as the black background and colors could be troublesome for some attendees.

What’s new with Oracle database 19.5 versus 19.4

It seems that the most eye-catching difference between Oracle database versions 19.5 and 19.4 is three underscore parameters spare parameters being changed to specifically named underscore parameters, two of them have a bug number in them which is not publicly visible.

In v$sysstat/v$sesstat, a group of statistics are renamed from ‘OS %’ to ‘Server %’. All these statistics are about networking. One changed parameter directly points to networking (tcpinfo). These statistics are added in version 19.

One DBA view was added: DBA_DV_COMMON_OPERATION_STATUS. This view is specific and owned by to DVSYS.

Solving accountability for ssh/linux servers without creating personal accounts

One of the continuing issues that I see is accountability (who did what on what server) on Linux or other operating systems that are using ssh.

The traditional solution for this problem is personal accounts, which provides logon and logoff registration.
Personal accounts often do have the least amount of rights which means typical administration tasks can not be done with them, in order to actually do something you need to sudo to an application account or root, which is logged by sudo, on enterprise linuxes to /var/log/secure. So some important facts are logged (logon/logoff/switching users), but a lot of important things are not logged at all, or maybe can be indirectly derived by combining data of operating system audit together with application specific logging.

Hashicorp vault and ansible: using certificate based authentication for playbooks

In first steps with with hashicorp vault and ansible I explained how to setup Hashicorp vault for use with Ansible.

The authentication of the playbook with Hashicorp vault in the playbooks was done in two ways:
– using a username and password in the playbook itself (which I discourage; then the authentication is readable).
– using a “authentication token” in the playbook.

The “authentication token” is obtained from vault using a username and password, and expires, so specifying that in a playbook does only spill the token. Please mind an authentication token and expires after a specified time, so it needs to created and provided just before execution, and should expire thus not being usable anymore.

First steps with Hashicorp Vault and Ansible

This post is about using using hashicorp vault and ansible.

Everyone that has used ansible knows you sometimes can’t get around storing secrets (passwords mostly) in an ansible playbook because for example an installer requires them. Or even simpler, because authentication must be done via a username and password.

The ansible embedded solution is to use ansible vault. To me, ansible vault is a solution to the problem of storing plain secrets in an ansible playbook by obfuscating them. However, these secrets are static, and still require the actual decryption key on runtime. In a lot of cases, it is delivered by putting the password in a file.

What’s new with Oracle database 19.4 versus 19.3

The most notable thing here is an “official” (non-underscore) parameter has been introduced with 19.4, “ignore_session_set_param_errors”. The description is: ‘Ignore errors during alter session param set’. I did a quick check to see if I could set it to true or false, which I couldn’t (resulted in an error).

With the Oracle database version 19.3 patched to 19.4 on linux, the following things have changed:

orachk can now warn about unwanted cleanup of files in /var/tmp/.oracle

Some time ago @martinberx mentioned on twitter that one of his Linux systems suffered from Clusterware issues for which there wasn’t a readily available explanation. It turned out that the problem he faced were unwanted (from an Oracle perspective at least) automatic cleanup operations in /var/tmp/.oracle. You can read more at the original blog post.

The short version is this: systemd (1) – successor to SysV init and Upstart – tries to be helpful removing unused files in a number of “temp” directories. However some of the files it can remove are essential for Clusterware, and without them all sorts of trouble ensue.

What’s new with Oracle database 18.7 versus 18.6

With the Oracle database version 18.6 patched to 18.7 on linux, the following things have changed:

What’s new with Oracle database 12.2.0.1.190416 versus 12.2.0.1.190716

There are a couple of underscore parameters changed from spare to named ones.
It’s interesting to see that in sysstat, ‘spare statistic 2’ changed to ‘cell XT granule IO bytes saved by HDFS tbs extent map scan’. This obviously has to do with big data access via cell servers. What is weird is that this is the only version where this had happened.

What’s new with Oracle database 12.1.0.2.190416 versus 12.1.0.2.190716

There are a couple of undocumented spare parameters changed to named undocumented parameters, this is quite normal to see.

With the Oracle database version 12.1.0.2.190416 patched to 12.1.0.2.190716 on linux, the following things have changed: