Happy new year!

By the Gregorian calendar the year 2014 is over...
So, welcome 2015!

I wish you all a happy new year!
I hope that the world become a better place for all!
In 2015 I hope that you at least try making the difference!
Happiness consists on making the others happier.

And yes I still think that Solaris is the #1 back-end infrastructure OS of choice!
And I'd like that industry standards get stronger and simpler;
both for enterprises and for low-end consumers!

Thank you!
Take care.

Breaking free

By the end of August I've finally broke free from almost 8 years of a sad workday routine.
A severe harassement left me out of options while I combated corruption and evil.
It took me a lot of courage, dignity and faith to resign from a proficuous career.
But when everythting is poisoned and doomed by others there's no way out.

Of course I can't make public the name of this company.
What I may say is that it's big and well-known on its segment.
The amount of money and resources they've been wasting is fabulous.
But, as everybody knows, unfortunately, there are those who benefit from chaos.

Of course that's why I moved to Solaris years ago and have stuck to it.
Solaris leaves few or no margin for the bad guys to cheat.
That's why the cheaters have come after me.
As a person of faith I pray for them.

I can say I've pursuited the best for the company and for people.
I can say I've respected Nature by taking into consideration natural resources.
I can say I posed no harm to anyone but acted Etically, with honesty and by the Law.
I've struggled to give a good example and God shall be my ultimate Judge and Witness.

I have peace of mind.
I continue to sleep very well.
My health is improving each day.
Now I live much better; and with much less.
I'm resuming advanced courses I left suspended years ago.
It may take a while for things to settle down, but chances are now I'll live longer.
After this critical transition I shall be happly resuming my posts.

Thank you.
Take care of yourself.
  

Another .inputrc feature

I'd also like to mention another useful application of .inputrc.
It's the ability to attribute a command to a key press: Command Binding.

The typical case is a frequent command and an unused function key.
Lets say, just for example, prtstat -J and the F5 key.
Initially, F5 is unbound.

Some .inputrc detail

I've passed by the .inputrc file sometimes in the past.
It's the file associated with the readline(3), stty(1) and termio(7I).

What I'd like to do now is to show how to use all of this to present one basic (suboptimal) setting to the behavior of the Del key, specially under the sun-color terminal. The case for the xterm terminal is easier to solve by tweaking .inputrc only.

The first command to note about is bind which is a bash built-in command.
It can set and display many bash key bindings and variables.
(not to mention commands bindings)
For all options:

$ help bind
...

$ bind -P |grep -v 'not bound' |less
...

Here's an example from a tweak for a xterm terminal:

$ bind -q delete-char
delete-char can be invoked via "\C-d", "\e[3~". 

Here's another example for a default sun-color terminal:

$ bind -q backward-delete-char
backward-delete-char can be invoked via "\C-h", "\C-?".

$ bind -q delete-char
delete-char can be invoked via "\C-d".

The above settings for sun-color could lead to a hard time until you figure out what's going on! This behavior of the Del key on a sun-color terminal is unacceptable! All that follows is related to the sun-color terminal type.

I was getting the following reading of the Del key:
  
$ read -n 1
^?

And the following reading for the Backspace key:

$ read -n 1
^H
 
And as seen above both "^?" and "^H" were set to backward-delete-char.
That's a nice way to drive you mad until you find out what to blame!
These default configurations may lock you in a tricky confusion.

NOTE

Some years later while investigating how to better adjust the layout of my keyboard while at the console, I've found out more about this issue around  "^?" and "^H".  In fact, I would have to dig more into terminal operations, but it may help to add that by default the backspace key must generate what terminal expect which is "^?" and not "^H". In fact, the best way to adjust this is not as I'll show below, but by reconfiguring the keyboard as shown on this other more recent post: Keyboard - Layouts.

SUB-OPTIMAL FIX:

To help our way out of this mess, here comes the stty shell command.
But if not used with care it may actually complicate matters even more.
This is because as per termio(7I) a DEL is supposed to be Backspace!
At the same time stty says that <BS> is "^H" and <DEL> is "^?".
For all stty options:
 
$ stty -h

The obscure solution is to tweak the terminal (tty) erase configuration.
This way, first, we restore the usual erase (Backspace) control sequence to "^h":
 
# stty erase '^h'

Or better yet, set it in the .bashrc:
 
...
if [[ "$TERM" = sun-color ]]; then
   stty erase '^h'  
fi
...
 
# stty -a
...
... erase = ^h; ...
...

Then we fix the Del key behavior by an appropriate entry in .inputrc:

...
$if term=sun-color
...
"\C-?":delete-char          # Del
...
$endif
...
     

Solaris 11.2 (General Availability)

Last Friday was a great day!
Solaris 11.2 General Availability (GA) was made available!

The main propaganda is around the integration with Open Stack.
That's a way to leverage the underlying Solaris technologies.
So far I haven't tried OpenStack but perhaps someday.
This is an interesting milestone:

Oracle was originally investing on its proprietary software.
I mean the Enterprise Manager Ops Center solution and add-ins.
Perhaps I should be glad I have invested almost no precious time on it.
According to my experience and first impressions I decided to wait.
But of course I have kept an eye on it as one never knows.
With Open Stack Oracle may have performed a clever step.
But of course things will depend on the Open Source community.
We'll see.

I hope this new release continues to be a solid step onwards.
I had to download around 8 GB of essential installers and repositories.
I'm expecting to meet newer versions of many pre-packaged software.
We'll see.
   

DNS configuration file

By default, the DNS configuration file is /etc/named.conf.
The location of this file is good and bad at the same time.
It's good because it's on a standard UNIX location.
It's bad because it isn't on dedicated directory.
 
In order to improve administration it's necessary to dedicate a more stable directory and decouple, as much as possible, configuration detail that are subject to more frequent changes (DNS zone data) from those that don't, such as global options.
 
Consider all the assumptions presented in my DNS configuration.
There are two scenarios, one of them specific to a DNS internal root.
 
I) The DNS internal root main configuration file could be:
    (This is for internal root servers A, B, C and D)
 
#
#       Business Corp.
#
#       DNS internal root main configuration file.
#       Global options should be gathered on this file.
#       last update:  August 1, 2014.
#
 
options {
  version none;
  directory "/var/named";
  # ...
};
 
# Internal root.
zone "." in {
  type master;
  file "db.root";
  recursion no;
};
  
# Loopback zone.
zone "0.0.127.in-addr.arpa." in {
  type master;
  file "db.127.0.0";
  notify no;
};
    
# End of File.
      
II) The internal DNS server main configuration file could be:
    (This is for internal top-level servers NS00, NS01 and NS02) 

#
#       Business Corp.
#
#       DNS internal server main configuration file.
#       Global options should be gathered on this file.
#       last update:  August 1, 2014.
#
  
options {
  version none;
  directory "/var/named";
  # ...
};
 
# Internal root.
zone "." in {
  type hint;
  file "db.cache";
  recursion no;
};

# Loopback zone.
zone "0.0.127.in-addr.arpa." in {
  type master;
  file "db.127.0.0";
  notify no;
};
  
# Zones data (more frequently changed)
include "named.zones";
  
# End of File.

As soon as I'm satisfied with the global options the file won't change.
This is precisely my intention: administration limited to /var/named.
  
The file /var/named/named.zones will have other nested includes.
Most probably or ideally one additional nesting (include file) per zone.
   

DNS zone data source files

There is a tedious aspect of setting up DNS zone data.
It how it will or should be organized within the file system.
This particular post seeks to address this specific point.

I'll take the same approach used for NIS maps' source files.
Please, visit that other post for a longer description and consideration.
 
# zfs create rpool/VARSHARE/named

# zfs list -t all -r rpool/VARSHARE
NAME                  USED  AVAIL  REFER  MOUNTPOINT
rpool/VARSHARE         52K  11.8G    40K  /var/share
rpool/VARSHARE/named   31K  11.8G    31K  /var/share/named

# chmod -R 750 /var/share/named

# ln -s /var/shared/named /var/named
# ls -lh /var | grep ^l
...
lrwxrwxrwx   1 root     root ... dns -> /var/share/named
...

For further organization no additional ZFS file systems are needed.
A simple directory structure within /var/named will do.
  
Configure the directory option accordingly in /etc/named.conf:

options {
  # ...
  directory "/var/named";
  # ...
};
  

DNS zone data

Apart from installing and configuring DNS itself, a crucial preliminary step is to structure and prepare the DNS zone data source files. In what follows, I assume that all the structure and contents have been addressed as defined on the preceding posts (previous links).
  
Take the internal DNS servers NS00 thru NS02 (below DNS internal roots).
Their named.zones included by /etc/named.conf could be as follows:
  
zone "business.corp" {
  type master;
  file "master/db.business.corp";
};
 
zone "10.in-addr.arpa" {
  type master;
  file "master/db.10";
};
 
zone "168.192.in-addr.arpa" {
  type master;
  file "master/db.192.168";
};
   
NOTE

Of course, it's not recommended to have a multi-master setup.
This means, just as example, that only NS00 should be master.
Hence, it suffices to substitute master for slave for NS01 and NS02.

The contents of each of the above zone data file in master is as follows:

I) business.corp

;
;       Business Corp.
;
;       Internal DNS (top-level) server forward zone.
;       last update:  August 5, 2014.
;
 
$TTL 3h 

@  IN  SOA  NS00.business.corp.  hostmaster.business.corp.  ( 
            1    ; Serial 
            3h   ; Refresh after 3 hours 
            1h   ; Retry after 1 hour 
            1w   ; Expire after 1 week 
            1h ) ; Negative caching TTL of 1 hour

; Authoritative name servers.

                    IN  NS  NS00.business.corp. 
                    IN  NS  NS01.business.corp.
                    IN  NS  NS02.business.corp.

; The internal root servers A records.

A                   IN  A  10.0.0.10
B                   IN  A  10.0.0.20
C                   IN  A  10.0.0.30
D                   IN  A  10.0.0.40

; The internal top-level servers A records.

NS00                IN  A  10.0.1.10
NS01                IN  A  10.0.1.20
NS02                IN  A  10.0.1.30

; Other internal hosts A records.

; ...
 
; End of File.

II) 10.in-addr.arpa

;
;       Business Corp.
;
;       Internal DNS (top-level) server reverse zone.
;       last update:  August 5, 2014.
;
 
$TTL 3h 

@  IN  SOA  NS00.business.corp.  hostmaster.business.corp.  ( 
            1    ; Serial 
            3h   ; Refresh after 3 hours 
            1h   ; Retry after 1 hour 
            1w   ; Expire after 1 week 
            1h ) ; Negative caching TTL of 1 hour

; Authoritative name servers.

                    IN  NS  NS00.business.corp. 
                    IN  NS  NS01.business.corp.
                    IN  NS  NS02.business.corp.

; The internal root servers PTR records.

10.0.0              IN  PTR A.business.corp.
20.0.0              IN  PTR B.business.corp.
30.0.0              IN  PTR C.business.corp.
40.0.0              IN  PTR D.business.corp.

; The internal top-level servers PTR records.

10.1.0              IN  PTR NS00.business.corp.
20.1.0              IN  PTR NS01.business.corp.
30.1.0              IN  PTR NS02.business.corp.

; Other internal hosts PTR records.

; ...
 
; End of File.

III) 168.192.in-addr.arpa

;
;       Business Corp.
;
;       Internal DNS (top-level) server reverse zone.
;       last update:  August 5, 2014.
;
 
$TTL 3h 

@  IN  SOA  NS00.business.corp.  hostmaster.business.corp.  ( 
            1    ; Serial 
            3h   ; Refresh after 3 hours 
            1h   ; Retry after 1 hour 
            1w   ; Expire after 1 week 
            1h ) ; Negative caching TTL of 1 hour

; Authoritative name servers.

                    IN  NS  NS00.business.corp. 
                    IN  NS  NS01.business.corp.
                    IN  NS  NS02.business.corp.

; Other internal hosts PTR records.

; ...

; End of File.

  

DNS loopback zone

The loopback zone is part of a DNS configuration.
Its purpose is to handle the 127.0.0.0/24 network.
By convention and good practice each DNS server must handle it.
Naturally, the above recommendation doesn't apply to DNS root servers. 
In general the localhost number is 127.0.0.1.
Hence, the zone file is called db.127.0.0.

Consider the example given on the post DNS internal root.
The top-level (below DNS internal roots) internal DNS servers are:

• NS00.business.corp
• NS01.business.corp 
• NS02.business.corp 

  
Each of them would have the following loopback zone configuration:
(the following are the contents of db.127.0.0)

;  
;       Business Corp.  
;  
;       The loopback zone.
;       last update:    July 31, 2014.  
;

$TTL 3h

@  IN  SOA  NS00.business.corp.  hostmaster.business.corp.  (
            1    ; Serial
            3h   ; Refresh after 3 hours
            1h   ; Retry after 1 hour
            1w   ; Expire after 1 week
            1h ) ; Negative caching TTL of 1 hour

; Authoritative name servers.
 
   IN  NS  NS00.business.corp.
   IN  NS  NS01.business.corp.
   IN  NS  NS02.business.corp.

; The localhost PTR record.
 
1  IN PTR localhost.

; End of File.
 
In this particular case /etc/named.conf must contain:

zone "0.0.127.in-addr.arpa." in {
  type master;
  file "db.127.0.0";
  notify no;
};
   

Internal DNS server

Internal DNS servers are those behind a firewall which provide host name resolution only within an organization's internal internetwork (or Intranet) and don't directly connect to the Internet. They differ from DNS internal root servers (that define their own root zone) and external DNS servers (that use a standard DNS root hints and directly connect to the Internet for external name resolutions).

The key distinctive configuration is regarding the contents of the (conventionally) so called db.cache containing a custom root hints with pointers to the organization's DNS internal root servers instead of a standard DNS root hints used for ordinary Internet-wide resolution.

Considering the examples given on the DNS internal root post as a base, the top-level internal servers (right below DNS internal root servers) are:
 

• NS00.business.corp
• NS01.business.corp 
• NS02.business.corp 

Each of them would have the following custom root hints configuration:
(the following is a partial excerpt of their db.cache)

;
;       Business Corp.
;
;       DNS internal root servers.
;       last update:    July 31, 2014.
;

.                     3600000  IN  NS    A.business.corp.
                      3600000  IN  NS    B.business.corp. 
                      3600000  IN  NS    C.business.corp. 
                      3600000  IN  NS    D.business.corp.
 
A.business.corp.      3600000  IN  A     10.0.0.10
B.business.corp.      3600000  IN  A     10.0.0.20
C.business.corp.      3600000  IN  A     10.0.0.30
D.business.corp.      3600000  IN  A     10.0.0.40  

; End of File. 

In this particular case, their (NS00 thru NS02) main configuration file, /etc/named.conf would contain:

zone "." in {
  type hint;
  file "db.cache";
  recursion no;
};
   

DNS internal root

A DNS internal root is a DNS configuration for an internal root domain ".". The DNS internal root servers are positioned within the organization's network and behind a firewall. Their configuration somewhat mimics that of a standard DNS root hints but deals only with internal servers and internal top-level domains.

Using an internal root is more flexible and secure.
It's also more scalable than extensively forwarding.

As an example, assume that:

• The internal DNS domain is business.corp.
  The company's name is Business Corp.
   
• The following networks are used:
• 192.168.0.0/16    (branch offices)
• 10.0.0.0/8        (headquarters)
   

• The internal root servers are:
• A.business.corp
• B.business.corp
• C.business.corp
• D.business.corp 
   

• The top-level (below root) internal servers are:
• NS00.business.corp
• NS01.business.corp
• NS02.business.corp

    
The internal root file conventionally called db.root could be:
   
;
;       Business Corp.
;
;       Internal DNS root and domains.
;       last update:    July 31, 2014.
;
 
$TTL 1d

.  IN  SOA  A.business.corp.  hostmaster.business.corp.  (
            1    ; serial
            3h   ; refresh
            1h   ; retry
            1w   ; expire
            1h ) ; negative caching TTL
  
; The internal root servers.

   IN  NS  A.business.corp.
   IN  NS  B.business.corp.
   IN  NS  C.business.corp.
   IN  NS  D.business.corp.

; The internal root servers addresses.

A.business.corp.    IN  A  10.0.0.10
B.business.corp.    IN  A  10.0.0.20
C.business.corp.    IN  A  10.0.0.30
D.business.corp.    IN  A  10.0.0.40  

; The internal domains and their authoritative servers.

business.corp.            IN  NS  NS00.business.corp. 
                          IN  NS  NS01.business.corp. 
                          IN  NS  NS02.business.corp.
  
10.in-addr.arpa.          IN  NS  NS00.business.corp.
                          IN  NS  NS01.business.corp.
                          IN  NS  NS02.business.corp. 
  
168.192.in-addr.arpa.     IN  NS  NS00.business.corp.
                          IN  NS  NS01.business.corp.
                          IN  NS  NS02.business.corp. 
  
; End of File.
  
Naturally, NS00 thru NS02 further delegate as necessary.
In this particular case, the /etc/named.conf of the root servers has:

zone "." in {
  type master;
  file "db.root";
  recursion no;
};

NOTE

Not all of the root servers must be master for the "." zone.
Of course, at a minimum, just one of them needs to be, as usual.

Other internal DNS servers must use these internal DNS root servers.
These specifics are covered on another post: internal DNS servers.