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.
Personal notes and recipes, views and opinions.
If it must run, it runs on Solaris!
Friday, September 5, 2014
Wednesday, August 13, 2014
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.
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
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
...
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>
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
...
Monday, August 4, 2014
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:
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.
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 hope this new release continues to be a solid step onwards.
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 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.
Friday, August 1, 2014
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.
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.
Subscribe to:
Posts (Atom)