"wait for unread message on broadcast channel" event and DG broker configuration

I had an issue with Data Guard the other day.

The configuration was in maximum availability mode. The network failure between primary and standby database caused the failure in transmitting the changes from primary with a lot of timeouts. 

The restoration of communication didn't change anything. There were no abnormally not-yet-opened-completely or not-yet-closed-completely network sockets from the perspective of operating systems on the servers. Any try from Data Guard Broker to view the status of physical standby or to change its property (logxptmode, for example) lead to unresponsive broker interface and event 'wait for unread message on broadcast channel' on the server where that change was attempted to apply. The 'disable configuration' or 'disable database' commands didn't work as well with the same result.

The options were to continue to work resolving gaps manually OR to try to do something with broker. 

Fortunately, simply re-enabling the broker configuration at primary at first and then on physical standby helped to resolve the issue. Suppose the simple killing of DG Broker processes like NSV0 and INSV could help also, but I didn't try it. The cause was in hanged DG broker processes on all servers involved in configuration.

Good Luck !

The adventure to enable back root ssh login on Solaris

There are some situations where root login must be enabled (permitted) over ssh. Sometimes it is a tricky task ))

First of all I enabled the 

PermitRootLogin yes

in /etc/ssh/sshd_config.

Then I got an error 

Received disconnect from server_ip port xx:2: Too many authentication failures

To overcome this, I've commented out the line  

#MaxAuthTries  3

It equals 6 by default.

But it wasn't the last step. The ssh daemon continue to ask the root password after entering it after the first attempt. To see what happened I ran ssh daemon in the console :

# svcadm disable ssh

# /usr/lib/ssh/sshd -D -d -f /etc/ssh/sshd_config
 
Around a lot of debug messages I saw the message 

PAM: User account has expired for root from client_ip

It was strange. The root account looked fine, not expired etc. The rambling over the server led me to /etc/user_attr file where root was presented like :

root::::type=role

According to man pages :

          type

              Can be assigned one of these strings: normal,  indicating  that
              this  account  is  for a normal user, one who logs in; or role,
              indicating that this account is for a role. Roles can  only  be
              assumed by a normal user after the user has logged in.

So I decided to change the type to normal:

# rolemod -K type=normal root

It was enough )). The root ssh login started to work after that.

 

Good Luck !