vnc xterm window appears without header

The program twm is "the window manager" that is responsible for the window header that appears on top of terminal windows of xterm.  In newer OEL 6 builds, when xterm is launched, the header doesn't appear as twm fails to launch.  If you try launching twm, it gives this error and exits to unix prompt:

twm: unable to open fontset "-adobe-helvetica-bold-r-normal--*-120-*-*-*-*-*-*"

I found a solution on http://ubuntuforums.org/archive/index.php/t-1596636.html :

It was reported here for fedora: https://bugzilla.redhat.com/show_bug.cgi?id=509639. The workaround is to execute it with a specific shell variable:

$ DISPLAY=:vnc port number
$ export DISPLAY
$ xhost +
$ LANG=C
$ export LANG
twm &

twm launches fine after this.

Oracle SSO Failure - Unable to process request Either the requested URL was not specified in terms of a fully-qualified host name or OHS single sign-on is incorrectly configured

Today, during a cutover when we were moving one of our ERP instance on Cisco UCS VMware VMs to Exalogic and Exadata, I got a call from Bimal.  The extranet iSupplier URL had been configured, but whenever any user logged in, they were seeing the following error instead of the iSupplier OAF Home page:

Oracle SSO Failure - Unable to process request Either the requested URL was not specified in terms of a fully-qualified host name or OHS single sign-on is incorrectly configured

A search on support.oracle.com showed many hits.  I went through a few of them and ruled out the solutions given. This article sounded promising: Oracle SSO Failure - Unable to process request Either the requested URL was not specified in terms of a fully-qualified host name or OHS single sign-on is incorrectly configured (Doc ID 1474474.1).

The solution suggested:

There is  a hardware load-balancer for a multi-tier environment on place, as well as an SSL accelerator.

     For R12, there is a context variable, s_enable_sslterminator, that was set to "#".

     This should be null for e-Business R12 using specific hardwarementioned before.


1. Set  context variable, s_enable_sslterminator to null,

2. Re-ran autoconfig,

3. Re-test Single sign-ons via IE and Firefox now works as expected.

I asked the DBAs to check the value of s_enable_sslterminator:

grep s_enable_sslterminator

and sure enough the value was #

As per article Enabling SSL or TLS in Oracle E-Business Suite Release 12 (Doc ID 376700.1), the value of s_enable_sslterminator should be made null if you are using an SSL accelerator.  In our case we use SSL certificate on the Load Balancer and never on Web servers.

The DBAs removed the #
Ran autoconfig
Deregistered SSO
Registered SSO

The user was able to login after that.

How To Install Latest Verisign G5 Root Certificates

Dhananjay pinged me today and told me that for their Paypal integration, they had to upgrade to Verisign G5 root certificate.  This was the message from Paypal:

Global security threats are constantly changing, and the security of our merchants continues to be our highest priority. To guard against current and future threats, we are encouraging our merchants to make the following upgrades to their integrations:

1. Update your integration to support certificates using the SHA-256 algorithm. PayPal is upgrading SSL certificates on all Live and Sandbox endpoints from SHA-1 to the stronger and more robust SHA-256 algorithm.
2. Discontinue use of the VeriSign G2 Root Certificate. In accordance with industry standards, PayPal will no longer honor secure connections that require the VeriSign G2 Root Certificate for trust validation. Only secure connection requests that are expecting our certificate/trust chain to be signed by the G5 Root Certificate will result in successful secure connections.

For detailed information on these changes, please reference the Merchant Security System Upgrade Guide. For a basic introduction to internet security, we also recommend these short videos on SSL Certificates and Public Key Cryptography.

There is a support.oracle.com article published on October 16, 2015 which has detailed steps for 11i and R12.1:

How To Install Latest Verisign Root Certificates For Use With Paypal SDK 4.3.X (Doc ID 874433.1)

The Verisign G5 root certificate can be downloaded from:

Paypal Microsite about this change: https://www.paypal-knowledge.com/infocenter/index?page=content&id=FAQ1766&expand=true&locale=en_US

Useful Links

• Download Symantec’s VeriSign G5 Root Certificate
• Download specific server SSL certificates, if required by your server
• Contact PayPal Technical Support

sftp failure due to newline character difference between windows and unix.

Recently I spent almost a full day struggling to make out, why an sftp connection would not work without password, after setting up ssh equivalence.  The keys were correct, the permissions on the directories were correct.  The authorized_keys file looked ok.  I copied the authorized_keys file of another account that was working fine.  When I replaced the authorized_keys after taking backup of original authorized_keys, it started working.  So then I proceeded to check the contents in a hex editor

On the left side you have the authorized_keys file created in Windows.
On the right side you have the same authorized_keys file created in Unix.

If you notice the ends of the lines in the Windows file it shows CR LF, where as unix shows LF.

This difference is well described in the wikipedia article on newline character.

The one mistake I had done this time was create the authorized_keys file in Windows notepad, as I was teaching a Developer how to create authorized_keys file.  Once I used vi on unix to create the authorized_keys file and pasted the same ssh key, sftp started working without prompting for password.  I know that Windows/DOS and Unix have different newline characters.  However, I was not able to apply that knowledge, till I compared the files in hex editor.

Whenever, a techie is able to get to the root cause of a problem, a deep sense of satisfaction is experienced.  I am glad I got the opportunity to troubleshoot and fix the issue by getting to the root cause of the issue.

Copycat blog

While doing a google search today I noticed that there is another blog that has copied all content from my blog and posted it as their own content and even kept a similar sounding name: http://oracleapps-technology.blogspot.com .  I have made a DMCA complaint to google about this.  The google team asked me to provide a list of URLs.  I had to go through the copycat's whole blog and create a spreadsheet with two columns. One column with URL of my original post and second column with the URL of the copycat's blog.  There were 498 entries.  I patiently did it and sent the spreadsheet to google team and got a reply within 2 hours:

Hello,

In accordance with the Digital Millennium Copyright Act, we have completed processing your infringement notice. We are in the process of disabling access to the content in question at the following URL(s):

http://oracleapps-technology.blogspot.com/

The content will be removed shortly.

Regards,
The Google Team 

Server refused public-key signature despite accepting key!

A new SFTP connection was not working, even though everything looked fine:

1. Permissions were correct on directories:
chmod go-w $HOME/
chmod 700 $HOME/.ssh
chmod 600 $HOME/.ssh/authorized_keys
chmod 600 $HOME/.ssh/id_rsa
chmod 644 $HOME/.ssh/id_rsa.pub
chmod 644 $HOME/.ssh/known_hosts

2. Keys were correctly placed

However, it still asked for password, whenever SFTP connection was done:

Using username "sftpuser".

Authenticating with public key "rsa-key-20150214"

Server refused public-key signature despite accepting key!

Using keyboard-interactive authentication.

Password:

I tried various things, none worked and I eventually went back to my notes for SFTP troubleshooting:

1. Correct Permissions

chmod go-w $HOME/

chmod 700 $HOME/.ssh

chmod 600 $HOME/.ssh/authorized_keys

chmod 600 $HOME/.ssh/id_rsa

chmod 644 $HOME/.ssh/id_rsa.pub

chmod 644 $HOME/.ssh/known_hosts

2. Make sure the owner:group on the directories and files is correct:

ls -ld  $HOME/

ls -ld  $HOME/.ssh

ls -ltr $HOME/.ssh

3. Login as root

chown user:group $HOME 

chown user:group $HOME/.ssh

chown user:group $HOME/.ssh/authorized_keys

chown user:group $HOME/.ssh/id_rsa

chown user:group $HOME/.ssh/id_rsa.pub

chown user:group $HOME/.ssh/known_hosts

4. Check for user entries in /etc/passwd and /etc/shadow

5. grep user /etc/shadow

When I did the 5th step, I found that /etc/shadow entry for the user didn't exist.  So I did these steps:

chmod 600 /etc/shadow

vi /etc/shadow

Insert this new line at the end

sftpuser:UP:::::::

Save File

chmod 400 /etc/shadow

It started working after that.