The packages repository https://www.adobe.com/go/coldfusion-packages is not accessible

[Rafael Martines]

Hi, since yesterday I'm getting the following error when trying to install packages on Coldfusion 2021

cfpm_audit.log

The packages repository https://www.adobe.com/go/coldfusion-packages is not accessible. You can only load the packages that are available locally in the /usr/local/lib/CommandBox/server/serverHome/adobe-2021.0.04.330004/WEB-INF/bundles directory.

https://www.adobe.com:443: Connection Reset on the imagem attached

I tried to install on my personal computer at home and at company computer.

[Dave Watts]

Normally, this indicates a network error of some sort rather than a CF-specific problem. Can you use wget or curl while logged into the shell (not as root) to go to the packages repository? If not, you or your network administrator may have blocked direct access. Can you see if there's a proxy server being used? CF won't know about that in some cases. In the short term, you can download the packages manually, then point CF to the internal location instead of the default one.

If this just happened immediately after a CF update, look for update-specific issues or bugs. You might be able to do that at the official Adobe bug tracker (https://tracker.adobe.com/). You should tell us if that's the case, too.

[Rafael Martines]

Hi, thanks for the answer this didn't happened after an update I was just deploying some new code on homologation server and this happened on the images attached

[Dave Watts]

Yeah, that's definitely an error with the Adobe site specifically. It looks like there are two redirects:

https://www.adobe.com/go/coldfusion-packages 

redirects to

https://cfmodules.adobe.com/cf2023/bundlesdependency.json

https://cfmodules.adobe.com/cf2023/bundlesdependency.json

redirects to

https://cfmodules.adobe.com/bundlesdependency.json

I've seen cases where too many redirects will break some user agents. Maybe that's what's happening here.

[Rafael Martines]

Interesting, if I use https://cfmodules.adobe.com/bundlesdependency.json I can install 2021 patches 🙂

[Dave Watts]

I just noticed you specified "connection reset" as the error, too. That typically means the client (CF) isn't able to validate the certificate, usually because it or one of the certificates in the validation chain has expired. I'm not sure if CF does anything in that case to fix the problem, but if it can't get there and you can (from the console using wget or curl and a non-root user), that's what I'd look for.

[Priyank Shrivastava. · Accepted solution]

Hi All,

We are aware of it and we are working on it. There is a redirection issue with the URL. 

If you want to install the packages, here is the workaround. 

Copy this URL - https://cfmodules.adobe.com/cf2023/bundlesdependency.json in Packages Settings and Submit.

It will directly hit the URL and install the packages.

[thumbo]

This redirection issue, can it cause issues with ColdFusion not starting up?

I've been seeing a weird issue in my dev environment that seems to have started early today,

where it simply won't start because it's timing out, with an error like "https://www.adobe.com:443: The target server failed to respond". I.e. it seems to be timing out trying to reach some adobe services (I'm guessing).

[Rafael Martines]

Hi, thanks for the answer, this solution only works if I install the 2023 version of the packages, but not with 2021 versions

[cindyt72591385]

We are having the same issues on CF 2021 as well.  We also cannot get the CF server to start up after installing this on Azure App Service.  We've not had issues with previous versions of CF2021, just with CF2021 update 16 and 17.  Once it is installed and we use Kudu to install the packages, we start the app service.  Confirm that the app service is running and then look at any packages not installed.  When we try to "install all" again, it gives us the notice that the ColdFusion service is not running and the packages will be installed once the server is up and running again.

[billr33588170]

We had multiple CF2021 servers failing to startup today as well. coldfusion-out.log indicated it could not reach www.adobe.com. 

[date time] Information [main] - Package spreadsheet started...
[date time] INFO [main] - I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {tls}->https://www.adobe.com:443: The target server failed to respond
[date time] AM Information [main] - I/O exception (org.apache.http.NoHttpResponseException) caught when processing request to {tls}->https://www.adobe.com:443: The target server failed to respond

We contacted Adobe support and worked with Ravi.  The fix for us was to edit this file: 

{cf_root} \cfusion\lib\neo_updates.xml and change the packagesurl to use {cf_root} \bundles\bundlesdependency.json instead of the online file www.adobe.com/go/coldfusion-packages  

<packagesurl>C:\ColdFusion2021\bundles\bundlesdependency.json</packagesurl>

Note - we did not change defaultpackagesurl 

We copied C:\ColdFusion2021\cfusion\lib\neo_updates.xml to each server and they all came up succesfully.

[cindyt72591385]

we have updated this on our file and the server still did not start.  To clarify - we are accessing the server through Kudu on Azure.  It is not a standalone server installation - it's installed on the Azure App Service.

We have double checked all parameters and we can get CF Admin page to load in a browser but through Kudu it still says CF server is not running.  There are 9 packages out of the 49 that will not install until the server is up and running.  Any other thoughts on why the CF server will not start?  Again - we have not had this issue with any previous patch or update except for update 16 and 17.

[Priyank Shrivastava.]

@cindyt72591385  Could you please send an email at cfsup[at]adobe[dot]com and we will take a look.

[cindyt72591385]

Update as of 12/26/2024

We created the update 18 WAR file on 12/23 when the update was released.  We have deployed this WAR and tried to install the packages with the same error that we received with update 16 and 17.  

The initiall "install all" says all packages and their dependencies have been downloaded successfully and will be installed once the CF server is up and running. 

At this point, we start our Azure App Service and wait for the package installation to complete.  We monitor in Kudu and continue to do "list" to see what packages have installed.  Out of the 49 packages, we are only able to get 37 installed with update 18.  When we try to install the other 12 packages, we get the message stating that the CF server is not running and the packages will install once the server is running.

We are able to access CF Admin page via the browser and we're able to access our website without any issue.  The only issue we have is with reports or functionality that requires the remaining packages to be installed.  Example, report is a package that has yet to install so if we try to run a report with our website, we get errors because the package is not installed.

If the CF server is not running, then how are we able to access the CF Admin page in a browser, connect our database and mail servers, and load/interact with our website?  There are no error messages in the .\cfpm or any of the logs, just the continual message that the remaining packages will install once the CF server is up and running.

[Charlie Arehart]

Cindy, it's possible that the problem your encountering is not caused by Adobe or any mistake with the recent updates. Let me offer first what may be amiss, then how you may be able to easily fix things. I also offer how you (or others) could get into this situation. I don't KNOW this is your situation. I'm guessing it from some of the info you've shared, and my experience helping others.

1) Can you please look in your CF Admin (which you said you can get to), and look at the "Package Manager" page, and its "Settings" option (at the top of that page), and tell us the value of the "Packages Site" field. Is it pointing to some file? If so, that might be something someone changed previously...not realizing it could need to be reset to the default for later updates. (More on "why" one might change that value, in a moment.)

But here's good news: note that there is a button there called "restore default url", which will do just that. FWIW, with your CF2021, that default is https://www.adobe.com/go/coldfusion-packages (which technically redirects to https://cfmodules.adobe.com/bundlesdependency.json), whereas CF2023 (for the sake of other readers) sets it  instead to https://www.adobe.com/go/cf2023_packages (which technically redirects to https://cfmodules.adobe.com/cf2023/bundlesdependency.json).

Anyway, is your value different than the default? If so, I would recommend you first take note (copy/paste) the current value, then click that "restore default url". Then click "submit changs" to implement that change.

Then finally without even needing to restart the CF instance, try doing your "install all" of the packages (right there in the CF Admin, though you could also do it via cfpm).

Does that end up getting all the package updates properly implemented for you?

If not, consider setting that "packages site" value back to what you had...though you may want to also take a look at the files in that folder. Note how most of the files  are .jar files which start with a package name, then have an indication of the CF version and update level. Do any of them have update values greater than the update 16 where you started having trouble? My guess is that they don't, but let us know.

2) If restoring that default DOES work for you, you may wonder "how did that change happen in the first place?". There are two things to consider, one for everyone who may find it changes, and one for you in your deploying of CF as a WAR file.

First, if you look at the CF update technotes section on "Install the update in offline mode manually", updating that field  is one of the steps they discuss, to point it to a folder where you manually download the updates instead. I am always afraid people will do that "this time" but forget "next time", not realizing that the next update which includes package updates will now fail to work, as now the update mechanism can't FIND the updated packages (even if they WERE downloaded online this time). 

Second and finally, you also say at the start that you "created the war" that you're deploying: you could create that either of a few ways. And if you did it by starting with an existing CF instance (using its "Packaging & Deployment">"JEE Archives" feature, not available in CF Standard), then note that that configures the WAR based on that instance from which you created it.

As such, if you DID create the WAR this way, then you'd want to consider also changing  that "Packages Site" setting on that original CF Admin. That way if you create the WAR again, it will have this problem corrected.

I'd love to hear if this helps. If not, apologies for the long note. If this stuff was easy (and if everyone always did everything the same way as everyone else), it would certainly be a lot easier to explain and solve problems. Since it's not, sometimes we need to dig further than most would ever expect.

[yelena_0974]

@Priyank Shrivastava. will there be an official Adobe CF report on this issue? Our management requested a copy of your incident report when available.  Thank you!

[Priyank Shrivastava.]

Hi Everyone,

Apologies for taking time to resolve the issue and thanks for your patience. 

We have identified the issue, and the team has handled it. We have verified from our side that it is working now. 

Please let me know if you face any issues. 

@yelena_0974  We are working on the RCA, once we have the complete details from the team, I will let you know. 

[Rafael Martines]

Sorry for the delay about this, but everything is back to normal here in the company since the fix on the redirecting issue, I just want to know if possible, in case of this happens again, is there an option to startup a server with the url of packages already configured? Like an env variable? I tried to find on docs and got nothing.

[Charlie Arehart]

I agree with Rafael: any mechanism to automate setting this would be very much appreciated (setting the package update url, by other than the admin or editing the xml file holding it). There are a couple of possible means. 

First, an env var would certainly benefit both those familiar with adding such to the jvm.config (via the -D arg), as well as those running the cf docker/container image.

Even more valuable could be the ability to control it via the cfsetup tool (added in cf2021). This could help both those audiences, as well being another means to promote use of the cli cfsetup tool. For those not aware, it lets you change virtually any cf admin setting, removing the need to use the cf admin or edit xml files. It can also export or import settings via json (similar to Commandbox cfconfig, a still more powerful tool that long preceded cfsetup). It also lets you easily import that json into the startup of a container. Either way, it could have really helped here, but I found it had no support for this package url setting. 

Adobe folks, do you need us to add an ER for this, or are you perhaps already working on it given this repeated update problem?

[Priyank Shrivastava.]

Hi Everyone, 

I sincerely apologize for the delay in providing the RCA.

The issue originated due to updates made by the our internal IT team. While mapping additional URLs as part of their testing, they enabled monitoring, which logged scripted calls (e.g., those from /go/coldfusion-packages). However, this caused the evaluation of further rules to stop, which meant that the "Browser Impersonator" functionality was not in effect. As a result, redirection stopped working.

Unfortunately, since no alerts were triggered at the time, our web team was unable to proactively address the issue. Once the problem was raised, the team quickly identified the root cause, especially after we highlighted the specific URLs causing the problem.

We deeply regret the outage and the inconvenience caused. To prevent such occurrences in the future, we have implemented additional monitoring measures to ensure that any similar issues can be promptly identified and resolved the issue.

Thank you for your patience and understanding.

@Charlie Arehart @Rafael Martines  I am checking with engineering if this will happen again if there are mitigation steps. This is the first time, it has happened as no one touched the rules that were added, but that should not impact the server start. 

Please give me a couple of days to get back and update the thread. 

[Rafael Martines]

Thanks for your reply, since the server has the option to change that, many projects for security reasons for example would benefit on having that config setted up on deploy 🙂 anyway thank you guys again 😄 Happy Holidays.