<@U06V253M4> I have an “interesting” command box s...
# box-products
d
@bdw429s I have an “interesting” command box scenario I could do with some guidance on how to proceed with. I am trying to get ACF 2021 using command box to run on AWS fargate - I have been doing this with command box and ACF 2018 for quite a while now. I assumed simply switching the cf engine to ACF 2021 would “just work” with a bit of loading modules etc. and it did - go command box for the win. I did notice however that the licensing server in ACF 2021 wasn’t enabling the enterprise license we have. After a bunch of investigation and a couple of hours with Adobe on a screen share it seems the license server isn’t getting a UID it needs from its environment. From what Adobe said I think it is assuming its running on an EC2 image and wants the VM’s UID from metatdata . This is not available via fargate as it abstracts all that stuff. Trying adobe’s official ACF 2021 container does seem to work in the same environment although it is much harder to work with compared to command box. So my guess is the WAR install behaves differently to what ever Adobe do in the “official” image or less likely the command box image is causing the issue. Have you come across this in your travels and any ideas how I could see if there is something command box is doing / blocking / missing that might help debug this?
j
CommandBox isn’t doing anything that way, as it just deploying the standard Adobe J2E war. It might be that ACF is relying on some Java options to determine if it is in a container and skips that UID check or gets the value from somewhere else. When you start the standard Adobe container, do you see any Java options in the initial startup?
You might try adding this JVM argument:
-XX:+UseContainerSupport
So here are the JVM args Adobe uses in their
jvm.config
file for their container:
Copy code
java.args=-server --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/sun.util.cldr=ALL-UNNAMED  --add-opens=java.base/sun.util.locale.provider=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED -Xms256m -Xmx1024m -XX:+UseParallelGC -Djdk.attach.allowAttachSelf=true -Dcoldfusion.home={application.home} -Djava.security.egd=/dev/urandom -Djava.awt.headless=true -Dcoldfusion.rootDir={application.home}  -Djava.security.policy={application.home}/lib/coldfusion.policy -Djava.security.auth.policy={application.home}/lib/neo_jaas.policy  -Dcoldfusion.classPath={application.home}/lib/updates,{application.home}/lib/,{application.home}/gateway/lib/,{application.home}/wwwroot/WEB-INF/cfform/jars,{application.home}/bin/cf-osgicli.jar -Dcoldfusion.libPath={application.home}/lib -Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=true -Dcoldfusion.jsafe.defaultalgo=FIPS186Random -Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.JavaUtilLog -Djava.util.logging.config.file={application.home}/lib/logging.properties -Dtika.config=tika-config.xml -Djava.locale.providers=COMPAT,SPI -Dsun.font.layoutengine=icu -Dcom.sun.media.jai.disableMediaLib=true
The ones I see possibly being relevant are: •
-Djdk.attach.allowAttachSelf=true
-Djava.awt.headless=true
I would try those as well.
I’m pretty sure the
UseContainerSupport
option sets the
java.awt.headless
option, though.
d
thanks @jclausen i’m just in the process of setting up a “minimum” environment in AWS to test the differences between Adobes container and my commandbox one - slow going though 😞
b
Hi @dougcain, I have no earthly freaking clue what Adobe is banging on about, lol. I'd need more information on this so-called
UID
, what it is, where it comes from, and how they are accessing it. If it's specific to AWS, I'm sort of clueless on how most of AWS works. Like Jon said, it's just a J2E WAR deploy. Can you connect me with the Adobe engineer who was talking to you?
The only information I've known Adobe to need to activate is the license key in the
license.properties
file
d
Thats what I thought - initially they said it’s a connectivity issue but it’s not - it’s assuming something about the infrastructure it’s running on I think when the license server calls back to Adobe
@jclausen FYI tried the jvm args - no change to behaviour - will have to see if Adobe can be helpful
j
If we knew what
UID
they were looking for, we could probably assist in troubleshooting, but what they are using under-the-hood to activate the licenses is a mystery to me.
☝️ 1
Also, their container doesn’t use a J2E deployment. I don’t really see any differences between the license.properties files that jump out at me. Adobe container:
Copy code
#CF License File
#Tue Mar 14 19:01:58 GMT 2023
vendor=0V\=LUFWP]J(Z^V)[G?G5'C@  \n
installtype=standalone
previous_sn=
appserver=0V\=LUFWP]J(Z^V)[G?G5'C@  \n
company=
sn=Developer
user=
listen=true
CommandBox container:
Copy code
#CF License File
#Tue May 02 20:49:29 UTC 2023
vendor=0V\=LUFWP]J(Z^V)[G?G5'C@  \n
installtype=j2ee
previous_sn=
appserver=0V\=LUFWP]J(Z^V)[G?G5'C@  \n
sn=
lte=1685652569586
listen=true
The LTE is just the unix timestamp for when the Trial expiration kicks it over to developer mode.
d
Fairly sure the Adobe container detects what it’s running on differently to the WAR somehow as in my tests I can see the Adobe container gets a UID from some where and sends it to the licensing server - the WAR version gets 000000 and sends that which causes the license server to go - no thanks - and evaluation version here we come. Both running on the same bare infrastructure. So some weird Adobe logic doing “something” seems to be the issue
j
Is your license a perpetual or annual license? We use
cfconfig_license
with ACF2021 and air-gapped servers all of the time and never have an issue - but those are perpetual licenses.
d
perpetual - think it is just making incorrect assumptions on what its running on which you would think should fail safe but in my case just goes to the evaluation license and you even get an error on the admin screen with a valid serial. Back with Adobe now - spent far too much time trying to track this down already…