E9.2 Apparent Contradiction of Open Ports

[tiradoj]

I am having an issue with JDE Server Manager trying to communicate with the agents on Dep Svr and Ent Server with Windows Server 2022.

Agents are not showing up in JDE Server Manager (9.2.7.1)

Getting this message in the e1Agent log on the Ent Server agent

2023-01-31 17:43:01 Apache Commons Daemon procrun stderr initialized.
Jan 31, 2023 5:43:08 PM com.jdedwards.mgmt.agent.E1Agent$UpdateAgentThread run

WARNING: Could not supply the remote agent with http hostname/port/protocol.

The client has not been connected.

java.io.IOException: The client has not been connected.

at javax.management.remote.generic.GenericConnector.checkState(GenericConnector.java:745)

at javax.management.remote.generic.GenericConnector.getMBeanServerConnection(GenericConnector.java:218)

at javax.management.remote.generic.GenericConnector.getMBeanServerConnection(GenericConnector.java:212)

at com.jdedwards.mgmt.agent.E1Agent$UpdateAgentThread.run(Unknown Source)

at java.lang.Thread.run(Thread.java:750)

Jan 31, 2023 5:43:08 PM com.jdedwards.mgmt.agent.E1Agent$UpdateAgentThread run

WARNING: Could not supply the remote agent with proper management server port/protocol. Hence the python scripts will not be updated

I have reviewed online Oracle docs and I have checked to make sure ports were open on BATMAN (where SM is) but getting contradictory readings on whether port(s) is actual open Free Port Scanner says for example 14502 is blocked while netsh says it is open and I created an inbound rule in Windows Firewall.

Seems to me there is still blocking going on. Anyone have any ideas why the apparent contradiction?

 

[tiradoj]

OK everyone, I figured out my bigger immediate problem of why the Mgmt Agents weren't being seen by the Mgmt Console in 9271 (took days!):

It was simplifying the OVERWRITTEN Oracle documentation!

Oracle Doc ID points out a KNOWN ISSUE:

'E1: SVM: Server Manager Console and Agent Issues With Oracle Java 1.8 Update 171 or Higher and IBM Java 8.0.4.1 or Higher (Doc ID 2621953.1)'

The answer lies in the over explained doc above.

All one has to do is comment out 3 lines in the java.security file used by Weblogic (in my case jdk1.8.0_341 jdk/jre/lib/security/java.security ) and the JDK the Agent is using. To wit!



# THE TLS section below needs to be commented out per Oracle Doc Doc ID 2621953.1 by Joe Tirado CNC 2-3-23
# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
# DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
# include jdk.disabled.namedCurves

This article goes into a twisted back and forth about how key algorithms used by Server Manager have been disabled in java.security and how the bug was fixed in various spots - if you were on this release and lower do that if you are on this release and higher do that blah blah blah.

Ignore all that confusion.

The explanation of what happened is nice but put that all at the END of the article and in more concise form.

Bang! Done!...and onward!

 

[tiradoj]

I am still looking for a better way to explained why ports look OPEN in DOS Windows when Free Port Scanner says they are closed---I did have to select a MUCH higher port range in Server Manager for the agents to use (or be allotted by Server Manager) like 49664 and above so the agent could connect and be seen and once I find the proper words to explain this I will post. I read a comment that if a service isn't listening on a port expected it will appear CLOSED...for lack of a better word but I am not sure I have that entirely right. Some processes will grab a port you may want to use or expect to use and you have to identify what process or program has that port and kill the process to free the port. But this is a mystery to be further clarified.

Anyone feel free to comment if you wish. I am not that proud!

 

[MFreitag]

OK everyone, I figured out my bigger immediate problem of why the Mgmt Agents weren't being seen by the Mgmt Console in 9271 (took days!):

It was simplifying the OVERWRITTEN Oracle documentation!

Oracle Doc ID points out a KNOWN ISSUE:

'E1: SVM: Server Manager Console and Agent Issues With Oracle Java 1.8 Update 171 or Higher and IBM Java 8.0.4.1 or Higher (Doc ID 2621953.1)'

The answer lies in the over explained doc above.

All one has to do is comment out 3 lines in the java.security file used by Weblogic (in my case jdk1.8.0_341 jdk/jre/lib/security/java.security ) and the JDK the Agent is using. To wit!

View attachment 19518

# THE TLS section below needs to be commented out per Oracle Doc Doc ID 2621953.1 by Joe Tirado CNC 2-3-23
# jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
# DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
# include jdk.disabled.namedCurves

This article goes into a twisted back and forth about how key algorithms used by Server Manager have been disabled in java.security and how the bug was fixed in various spots - if you were on this release and lower do that if you are on this release and higher do that blah blah blah.

Ignore all that confusion.

The explanation of what happened is nice but put that all at the END of the article and in more concise form.

Bang! Done!...and onward!

Depends on your Tools Release, but since you're using 9.2.7.x you could also use the new default which is TLS for the SVM/Agent communication as explained in the Server Manager Guide. The workaround you're using came up when JDK8 171 disabled depracated algorithms and ORACLE needed to react fast because SVM and Agents weren't ready. Today you can use the secure communication and don't really need that workaround anymore.

 

[tiradoj]

Depends on your Tools Release, but since you're using 9.2.7.x you could also use the new default which is TLS for the SVM/Agent communication as explained in the Server Manager Guide. The workaround you're using came up when JDK8 171 disabled depracated algorithms and ORACLE needed to react fast because SVM and Agents weren't ready. Today you can use the secure communication and don't really need that workaround anymore.

Thanks amigo for info. I got tired of trying to translate Oracle technical article into Plain concise English and I have lots more CNC components I want to configure so I can review setting other secure communication methods later. My "workaround" is just fine. The Oracle doc that is out there could have explained it a lot better and saved me a lot of time but that's why I have a job to flesh out these aspects of CNC.

 

[glen7x]

Would recommend that you run with TLS encryption on, since it imporves the performance of server manager a lot!
just dont use 1.3 if you are using SQL Server database.

 

[tiradoj]

Would recommend that you run with TLS encryption on, since it imporves the performance of server manager a lot!
just dont use 1.3 if you are using SQL Server database.

Hi Glen...this is a LAB ONLY NON PRODUCTION install. There are a million additional FIXES I have to put in place before I look at TLS to get this beautiful product running.

After 25 years of doing this there are STILL way too many things that have to be done to make this product ready to go. E1 has NEVER and never will be a product you can install "out of the box" and run with. Every fresh install requires HUNDREDS if not thousands of little pieces (ESUs, documentation corrections, opatches, incorrect/corrupt DLLs getting into GA release of software, etc) that need to be patched and/or configured to make it run with on a minimum level. The proof is demonstrated every release.

I have to hand it to LARRY ELLISON and team for being GREAT MARKETERS. Right now I am digging this LONG ID feature and LONG PASSWORD feature but check it out--the feature is not even in the list of available features. LOL -- I am sure someone will say "It is in ESU blah blah blah" to which MY response is, why is not in the BASE software package? How about NOT advertising/marketing a component that is not available working or tested until it actually has been?

No one loves this software than me but I do lament the inability of Oracle (or PeopleSoft and JDE when they owned the product) to REDUCE the number of patches and tweaks over time to make it run smoothly. To which someone else will respond "that's the software industry" lots of pressure/competition to get out new functionality constantly, never enough time to put it out clean. To which again I respond, 'I don't care if that's the software business' get your product solid before you put it out there.

Microsoft is the same way but at least you can use it quicker.

I've always had this disposition even when I was with JDE in 1997 trying to get JDE up and running on Oracle/Unix B714 with first ever customer in West region Pericom Semiconductor and I ain't going to change it now.

Peace.

 

[tiradoj]

Since someone might push back on my CNC laments...people always want "proof" LOL...ok, here you go!

This is from the "Explanation of scripts in this folder" text doc that comes with JN19891 ESU...

"The CCORE.dll shipped in this folder is to restore the CCORE.dll to GA version for non-Cloud customers. We inadvertently replaced it with a bad version in the PLANNER update at some point."

I am VERY GLAD and VERY appreciative someone at Oracle was kind enough to include this "little note" to save us CNCs what could be considerable time, but it is simple, easy example of what I mean about the challenge/pressure of getting product out the door before it is ready.

Here is another simple classic example:

E1: INST: Processing Option Template Error On All Applications (Doc ID 1532204.1)

'Occasionally, 9.2 OCX files are not registered during the Deployment Server or Client install.'

Huh? Occasionally? I thought computers either worked or they didn't. Why would OCX files 'occasionally' not register if steps are done in the proper order?

One or two missing/incorrect pieces not in place is not an issue with E1. The problem is there are MANY little things like this that come along with every release that have to be individually addressed.

Would recommend that you run with TLS encryption on, since it imporves the performance of server manager a lot!
just dont use 1.3 if you are using SQL Server database.

Thank you for tip btw!

 

[tiradoj]

I should probably start a new post but since this is part of original task of getting my 9271 instance up....

After 2-3 weeks of working setting up a 9.2.7.1 FULL TEST instance of JDE E1 fixing/deciphering/configuring E1 bits and pieces in my Home Lab on my off time...... Oracle database is VERY sensitive to power outages btw-db got corrupted when I had a storm and it knocked my power out--now I have my entire instance on a UPS --restoring Oracle db was a fairly major drag to fix (installing on VMWare or similar virtual platform is a MUST these days! you don't want to start from scratch with E1 ever!), getting the compiler settings perfect in jde.ini files to match up with VS 2022 directories and sub directories was pretty tedious --ran into another wall with Oracle database not auto extending on CO tables during application of Update 7 ASU.

NOW I have a perfectly clean full client server package (no BSFN errors), successful porttest and server manager also comes up clean.

JDV920 Environment HTML client comes up clean and yet....but I am unable to login to this beautiful beast.

What is strange is that the User Session parameter shows I have a session - that I am actually logged in

There is NO ERROR in the e1 root log either.

After I enter user id and password, E1 whirs for a few seconds, then clears the USER and PASSWORD fields and I am still sitting on the login page

Since I had no errors to work in log with and couldn't find anything on Oracle support site, I raised the white flag and opened a ticket with Oracle ! but hey I did 98% of this configuration on my own on the very latest E1 release (I had to consult with an Oracle dba on 2 db specific issues from hell but hey I never said I was an Oracle dba!)

I am proud of very proud of my achievement with the latest JDE and related components but I am not THAT proud! I am open to ideas from anyone on this.





I thought maybe the BACK BUTTON PROTECT in url might be a hint



this is what is in the e1 root log



Shows a user session--even though I am not logged in

 

[TFZ]

My best two guesses...

You're getting a callobj session, so I would guess something is goofed firewall wise. Maybe turn on predefined ports on ent, and add a firewall rule allowing traffic on 6017-6027 for every thing?

What version of WLS is it? Did you patch it?

 

[tiradoj]

I think it is a corrupt site key possibly since I cannot login to a E1 Dev client either--but I can login with system user JDE grrrrr!

 

[tiradoj]

My best two guesses...

You're getting a callobj session, so I would guess something is goofed firewall wise. Maybe turn on predefined ports on ent, and add a firewall rule allowing traffic on 6017-6027 for every thing?

What version of WLS is it? Did you patch it?

12212 and no I haven't patched it but I can/will look into those after I recreate site key and eliminate that possibility. Thank you TFZ!

 

[tiradoj]

12212 and no I haven't patched it but I can/will look into those after I recreate site key and eliminate that possibility. Thank you TFZ!

I am on 12212 but I assume you mean this patch?

Note:
WebLogic 12.2.1. . You must apply a mandatory Opatch after WebLogic Server 12.2.1.1.0 has been successful installed. This is described in the Oracle support document entitled:
E1: WLS: For JD Edwards EnterpriseOne HTML Server to run Oracle WebLogic Server 12.2.1.1.0 a Mandatory Patch is Required (Doc ID 2192375.1)

 

[TFZ]

That's the patch I was thinking of. And I would do that, and then use that new user to login to the web... and then try it on a fat client. I've seen that happen with 9.2.7.x in terms of the fat client looking for the favorites and it not being there - BUT it gets created just fine logging on to the web and fixes it.

 

[tiradoj]

grrr why can't they make things work out of the box I found patch for 12212--it is Patch 24521759

 

[tiradoj]

grrrr-- the reason I haven't applied the patch is because this is just a test instance and I thought I could get away with NOT having to = assuming BASIC functions of JDE would work out of the box but ...OF COURSE NOT.

running opatch is NOT a simple thing either: Oracle advises downloading a tool to make sure you have the latest version of opatch, make a backup of Oracle_Home and other folders/files, then they want you to run reports on whether the instance of WLS and server has all the prereqs yadda yadda....frankly it's a pain in the rear

I finally found the appropriate Doc Id (2185160.1) that addresses the exact problem I was having described above -- the title of the Doc Id was not ideally named to make it show up in Support a lot faster. Would have saved a LOT of time and trial and error.

I am backing up all my JDE servers at this point since I don't want to have to roll back after all this work...I am thinking/hoping/expecting installing the latest SQL Server db will be a lot easier but having to understand the latest Oracle bits and gotchas is necessary since that is what will be on clients and dep server only going forward.

 

[tiradoj]

This process can be a 3 stooges routine sometimes: running 'opatch apply patch_number -report' tells me that the patch isn't needed as I suspected (in fact it won't even apply the patch)

This is a permissions issue somehow accessing Oracle dbs/datafiles-maybe in that Database Privileges app.... I recreated the site key in the exact order Oracle doc stated-- no joy there either---reeeediculous

 

[MFreitag]

You could start by using a certified Weblogic version imho:

 

[TFZ]

I figured you were using 12.2.1.2 for a specific reason - but yeah - if you can do 14, do 14. If not, you should download whatever the last bundle patch for 12.2.1.2 available. I would think a sitekey / permission issue would show in your logs - which look clean. The behavior you are showing is exactly what used to happen in 12.2.1.2 without the 1 off - but good luck.

 

[tiradoj]

You could start by using a certified Weblogic version imho:
View attachment 19547

Sure I can! I am not opposed to it--nothing religious about 12212 but it has worked in several recent configs I've done with albeit DEMO 9.2.0.0 (base) and Oracle 19 so I didn't have a reason to be especially worried - this is MY test instance. I can test what and how I wish and make reasonable exceptions which I did.

Another possibility...the product could just WORK out of the box.....

It's not like there are bugs or workarounds or patches or misprints/contradictions in the documentation etc etc that have to be worked through staying strictly within the the MTRs that cause the product not to work

How about Oracle advising a patch is necessary in one doc for 122122 when opatch says it isn't? You saw my post on that or no?

If that's the reason why I can't login to HTML client is I am not EXACTLY on MTR (note in your link it says 12.2.1.4 is also supported--
so yeah a reasonable exception from my point of view)... I am fine with it

Thing is I am not able to login to regular full client either except with JDE user.

Nothing to do with WLS...sooo yeah.

Let's see what Oracle and further research says