Linux Annoying Defaults, and changes when moving to RH/OEL7

So why does Linux have an alias for “ls” which turns on colour, by default, making some text impossible to read? eh?

alias ls=’ls –color=auto’

To stop this temporarily, you can “unalias ls”, but to stop it permanently for everyone:

vi /etc/profile.d/colorls.sh

comment out the line:

alias ll='ls -l --color=auto' 2>/dev/null
alias l.='ls -d .* --color=auto' 2>/dev/null
# alias ls='ls --color=auto' 2>/dev/null

And that’s it. Cured for life.

While I’m on, why oh why has so much pointlessly changed between RH/OEL6 and RH/OEL7.

Switching off the firewall is now

systemctl stop firewalld
systemctl disable firewalld

And changing the hostname now has a dedicated command all to itself, instead of just amending /etc/sysconfig/network (which you can still do)

hostnamectl set-hostnane new-host-name-here

And what does it do? It creates a /etc/hostname file (and sets the hostname so you don’t need to reboot, so you should use this method)

And another thing. Why has the ifconfig command vanished ?

ifconfig
-bash: ifconfig: command not found

pifconfig
lo
          inet addr:127.0.0.1   Mask:255.0.0.0
          inet6 addr: ::1/128 Scope: host
          UP LOOPBACK RUNNING

enp0s3    HWaddr 08:00:27:75:c8:1e
          inet addr:192.168.56.200 Bcast:192.168.56.255   Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe75:c81e/64 Scope: link
          UP BROADCAST RUNNING MULTICAST

enp0s8    HWaddr 08:00:27:58:20:01
          inet addr:10.10.0.1 Bcast:10.255.255.255   Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe58:2001/64 Scope: link
          UP BROADCAST RUNNING MULTICAST

or more correctly:

ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s3:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 12:00:00:00:00:11 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.201/16 brd 192.168.255.255 scope global enp0s3
    inet 192.168.56.211/24 brd 192.168.56.255 scope global enp0s3:1
    inet6 fe80::1000:ff:fe00:11/64 scope link
       valid_lft forever preferred_lft forever
3: enp0s8:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 12:00:00:00:00:21 brd ff:ff:ff:ff:ff:ff
    inet 10.10.0.1/24 brd 10.10.0.255 scope global enp0s8
    inet 169.254.249.91/16 brd 169.254.255.255 scope global enp0s8:1
    inet6 fe80::1000:ff:fe00:21/64 scope link
       valid_lft forever preferred_lft forever

The whole of (the unmaintained) net-tools has been deprecated. No more:

[root@rac12c01 ~]# netstat
-bash: netstat: command not found

We now need to learn to use the iproute2 suite of commands instead:

ifconfig -> ip addr (or ip link - e.g. ip link set arp on)
route    -> ip route
arp      -> ip neighbor (e.g. ip n show)
vconfig  -> ip link
iptunnel -> ip tunnel (add/change/del/show)
brctl    -> bridge
ipmaddr  -> ip maddr
netstat  -> ss (or a bunch of ip commands)

(or you could just yum install net-tools to get the old tools back, but that’s just not the right thing to do, is it)

You might want to yum install lsof and yum install nmap though. They aren’t there by default in OEL7

And another thing – tempfs being in memory being default. Why? It’s too small to be any good for anything really. To switch is back to being a real filesystem (and get your memory back)

systemctl mask tmp.mount
(outputs) ln -s '/dev/null' '/etc/systemd/system/tmp.mount'
... and reboot

and another thing – why is grep (and egrep and fgrep) now aliased to colourise your search results? To be honest, I happen to agree with this. Nice new default feature:

alias
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'

cat /etc/passwd  | grep oracle
oracle:x:500:500::/home/oracle:/bin/bash

More mini-rants will appear in this blog post as I fall across/remember the issues

DROP DATABASE command

I have been DBA-ing for a while now, and I today I used a “new” command which I have never used in the previous 20+ years I have worked with Oracle: DROP DATABASE. It’s amazing what you miss sometimes!

So, what does it do? As the name implies, it drops the database. That is, it deletes all of your database files. This is significantly safer than using traditional Operating System methods (assuming you even have access and are not using ASM), and for added safety you have to be running the database in RESTRICT MOUNT mode.

What a lovely command. It goes to all the trouble of locating and removing those troublesome files that were put into the wrong place by another DBA that you would have missed if cleaning up manually.

It certainly made the pre-production clone script (cloning from the Physical Standby) that I have just written quite a bit easier to code.

Does anybody know if there is any other reason for running the database in RESTRICT MOUNT mode, or was it designed just for this command?

EDIT: I was just informed via Twitter (@chandlerdba) by @pfierens that this also takes out your SPFILE. If you are using an SPFILE (you should be!) and want to keep your db parameters for a db rebuild, I would recommend creating a pfile from the spfile first…

Has anyone ever done an RMAN “drop database including backups” ?   You REALLY need to be sure you don’t want it back to run that one!

My alert.log is broken

Well, not mine, but a recent post on the oracle-l mailing list which I thought was worth linking to and repeating. Firstly, because it’s interesting, and secondly, because it shows some good problem solving skills by both the poster and the wider Oracle community.

The poster in question was experiencing a problem whereby his alert log was not updating…

We have an alert.log that was last updated by the database on May 6th.
Strangely enough, the log.xml in the alert directory of the diag destination
is being updated normally, it is just the plain text alert.log in the trace
directory that is not updated. We have bounced the database, changed the
diag_destination parameter and I have even grepped all the file descriptors
in /proc/*/fd for traces of a possibly opened alert.log - nothing, the alert.log
is still not being updated. I tried dbms_system.ksdwrt to force a write to
the alert.log - again, the log.xml is updated, the plain text is not.

Read more of this post

%d bloggers like this: