I spent nearly an hour trying to figure out what was wrong with the deployment package:
When I went to another tab in the browser, the answer became obvious:
© Scott S. Nelson
Things that help, hinder, or horrify happy developers at work. I used to call this category Development, but delicious has more tags for programming. “Go with the grain” – Jethro Gibbs
Oracle released Security Alert CVE-2015-4852 last night, their official security response to a much-publicized vulnerability with certain usage of the Apache Commons library with the major J2EE application servers.
If you have access to the Oracle Support Network, the best reference is https://support.oracle.com/rs?type=doc&id=2076338.1.
For an Apache POV of the situation, I suggest https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread.
Infoworld has a calmer dissertation of the issue at http://www.infoworld.com/article/3003197/security/library-misuse-exposes-leading-java-platforms-to-attack.html.
I personally heard about this first from /., where this is an informative thread (with the usual trolling between) at http://developers.slashdot.org/story/15/11/08/0346258/vulnerability-in-java-commons-library-leads-to-hundreds-of-insecure-applications.
Like many enterprises, the one I’m currently working with only provides developers with the Monitor role in production. This requires scripting tasks that are well-documented for manually performing but take some real thinking and testing to get right as a script.
One of my team members frequently says that code should be self-documenting, so rather a long blog entry I thought I would simply post the script along with some minimal comments and see if everyone finds that useful:
def configureAdfLogHandlers(): #The full script has multiple methods, so I print the currently running method to follow along print 'Start configureAdfLogHandlers()' managedServers=cmo.getServers() for managedServer in managedServers: sname=managedServer.getName() path = '/Servers/' + sname cd(path) lh = listLogHandlers(returnMap='true') for l in lh: lname = l.get('name') #Even with this script, the odl logs are quite verbose and we run an automated arciving process. #To simplify the process, we just put the logs in the archive path since the odl log handlers don't provide an archive location option odlfile = '${domain.home}/logs/LOGS/${weblogic.Name}-' + lname + '.log' print '%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%' print ' Setting log handler configuration for ' + lname print '%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%' #The custom code rarely uses any levels between debug and warning, and the notice level for Oracle code is too verbose for most trouble-shooting needs configureLogHandler(target=sname,name=lname,path=odlfile,rotationFrequency='daily',retentionPeriod='day',maxLogSize='1g',maxFileSize='100m',level='WARNING:7') print '%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%' print ' Setting logger configuration for ' + sname print '%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%' #The custom code used by the application sets of warnings in these packages that are not issues for the application, so we set the level to ERROR here setLogLevel(logger='oracle.webcenter.page',level='ERROR:1',target=sname,persist='1',addLogger='1') setLogLevel(logger='oracle.webcenter.framework.service.Utility',level='ERROR:1',target=sname,persist='1',addLogger='1') setLogLevel(logger='org.apache.myfaces.trinidadinternal.skin.SkinCSSDocumentHandler',level='ERROR:1',target=sname,persist='1',addLogger='1') connect(os.getenv('WLS_USER'),os.getenv('WLS_PW'),os.getenv('ADMIN_T3')) configureAdfLogHandlers() disconnect() exit()
It has been posted many times, but since I ran across it again and it made a significant improvement, I’ll repeat it for others.
Add the following to your WLS start up arguements:
-Djava.security.egd=file:/dev/./urandom
If you are interested in details, see https://bugs.openjdk.java.net/browse/JDK-6202721
I was having a frustrating situation yesterday where the WLS console would just hang after clicking the Servers link. Naturally I go to the Unix console to tail the logs and see what’s what, and these prompts for a password keep popping up. Entering the admin password is no help.
So I went to the next natural step of rebuilding the domain (the build is scripted, and yes, I backed up the domain first) and the problem is still there!
An email to a colleague more steeped in the dark arts of server administration than I results in the suggestion that this is due to a problem with SSH (the domain uses SSH Node Manager) and tells me test it with:
ssh username@hostname
to confirm connectivity and permissions. What I get back is:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0755 for '/app/home/username/.ssh/id_rsa' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: /app/home/username/.ssh/id_rsa Password:
With this new detail in mind, I went to an environment that was working, found it had the file permission set at 600, and preforming
chmod 600 /app/home/username/.ssh/id_rsa
Got me up and running again