http://coldfusion.com logo
Join Slack
Powered by
Have a scripted commandbox, Lucee server install t...
# box-products
d
Have a scripted commandbox, Lucee server install that we use for all our servers, today it started throwing the error that I'll post in the thread....
Copy code
|   |-----------------------------------------------------
   | √ | Loading CFConfig into server
   |   |-------------------------------------------
   |   | Found CFConfig JSON in "CFConfigFile" server.json key.
   |   | Importing luceeserver config from [E:\lucee-tools\commandbox\config\lucee-cfconfig.json]
   |   | Config transferred!
   |   |-------------------------------------------
   | × | Loading FusionReactor
   |   |------------------------------------
   |   | × | Installing package [forgebox:fusionreactor@^8.0.0]
   |   |   | > net.lingala.zip4j.exception.ZipException: Zip headers not found. Probably not a zip file or a corrupted zip file
   |   |   |-----------------------------------------------------------------
   |   |   | Verifying package 'fusionreactor' in forgebox, please wait...
   |   |   | Installing version [8.7.6].
   |   |   | Verified entry in forgebox: 'fusionreactor'
   |   |   | Package found in local artifacts!
   |   |   | Decompressing...
   |   |   |-----------------------------------------------------------------

ERROR (5.4.2+00453)

net.lingala.zip4j.exception.ZipException: Zip headers not found. Probably not a zip file or a corrupted zip file
  caused by: net.lingala.zip4j.exception.ZipException
  net.lingala.zip4j.exception.ZipException: Zip headers not found. Probably not a zip file or a corrupted zip file
    caused by: net.lingala.zip4j.exception.ZipException
    Zip headers not found. Probably not a zip file or a corrupted zip file
      caused by: net.lingala.zip4j.exception.ZipException
      zip headers not found. probably not a zip file
I can disable the fusion-reactor part of the install and it works ok, so best guess is its downloading something that isnt a zip
b
@Dean That would defo appear there is an invalid zip,
And it's happening while installing a new FR version
Did you check forgebox to see if there is a recent new version of FR out?
Hmm, last version was Dec 9th, unless they pushed a version and then pulled it
Copy code
Installing version [8.7.6].
That's the Dec 6th version so no new version
Downloading that zip directly in my browser yields a valid zip file
message has been deleted
But I trust you already did these troubleshooting steps 😉
can you enable verbose errors in the CLI and try again so we can get the full stack trace?
Copy code
config set verboseErrors=true
Perhaps it's some other archive that's the one erroring
Also something to look at-- whether you've got a network appliance blocking access to the zip file or replacing it with some HTML challenge page. You say this just started today? @lmajano We didn't touch the Cloudflare bot rules today, did we?
You may also be able to look in CommandBox's temp folder. It looks like we don't clean up the zip files in a 
finally{}
block so there's a decent chance the downloaded zip is left in the temp folder after it blows up. It would be in 
~/.CommandBox/temp/tempXXXXXXXX-XXXX-XXXX-XXXXXXXXXXXXXXXX.zip
.
You can take a look at see if it's a zip file, or perhaps some HTML response from an intermediate network appliance
The zip file on my Windows machine is roughly 40 Megs
d
The temp files seem to be only folders, and the ones being created are empty. I cant see any zip files in there at all. Attached is the error with verboseErrors turned on
frdump.txt
I dont have a proxy or any other network device that would stop the zip being downloaded.
I might throw one in to see what its trying to get to though
b
I would put in some debugging code in the file endpoint to output the temp file name. The error is coming from the unzip operation here
Copy code
zip action="unzip" file="#package#" destination="#packagePath#" overwrite="true";
so the 
package
variable contains the zip file path
d
That sounds much easier than trying to get Java to trust to root cert of Fiddler 😐
b
I really don't understand how the temp zip file isn't still there
The code path doesn't have anything in place to remove it when there's an error
Unless the download step literally isn't writing the file for some reason
d
its creating a bunch of temp folders, they are empty
b
Yes, you mentioned that
but it should ALSO be creating temp zip files
The folders are just the location the zip file is supposed to be unzipped into
FWIW, you should be able to add your fiddler root cert to Lucee by running this from the CLI
Copy code
#sslcertificateinstall <http://domainThatProxiesThruFiddler.com|domainThatProxiesThruFiddler.com>
And then restart the CLI
you can use
Copy code
#sslcertificatelist <http://host.com|host.com>
to confirm what certs are 'seen' on that host
d
ah nice
b
I haven't used Fiddler in a long time-- used to be my go-to for inspection
but it all got harder to use when most stuff started using SSL
Also, I don't know if you're aware, but you can test JUST the download of FR in a vacuum without actually starting a server by just running this in the CLI
Copy code
install forgebox:fusionreactor@^8.0.0 --verbose
That's essentially what the FR module is doing behind the scenes when it starts the server
Actually, I just noticed something important in your last console dump
Copy code
Package found in local artifacts!
It's not downloading the package at all!
You have a bad local zip in your artifacts it appears
d
Copy code
install forgebox:fusionreactor@^8.0.0 --verbose
 × | Installing package [forgebox:fusionreactor@^8.0.0]
   | > net.lingala.zip4j.exception.ZipException: Zip headers not found. Probably not a zip file or a corrupted zip file
   |-----------------------------------------------------------------
   | Verifying package 'fusionreactor' in forgebox, please wait...
   | Installing version [8.7.6].
   | Verified entry in forgebox: 'fusionreactor'
   | Package found in local artifacts!
   | Decompressing...
   |-----------------------------------------------------------------

ERROR (5.4.2+00453)
b
Try running
Copy code
artifacts remove fusionreactor
Or, if you want, go look at the zip first
it will be in the 
artifacts
folder under the commandbox home
it's prob 0KB or something
You can see what you have like so
Copy code
artifacts list fusionreactor
I can't believe I didn't catch the 
Package found in local artifacts!
in the first place
I'm guessing you had a download interrupted or something the first time
@Dean
d
ah. its a zip file now, before that folder contained files
b
after clearing artifacts?
d
yeah
b
well yeah, because it actually downloaded fresh 🙂
Your local artifact was corrupted and just kept getting re-used
I could put in a check to test artifacts and if they're invalid, nuke them
The answer was right in front of us in the console output all along
• found in artifacts • decompressing • boom!
What was it decompressing? The file from artifacts!!
I was focused on the download logic and missed the fact it was just using a local file
d
during the commandbox install I do 
install --debug commandbox-bullet-train,commandbox-cfconfig,commandbox-fusionreactor,commandbox-cflint,commandbox-cfformat
it must have been screwed up during that?
b
That's completely irrelevant
You may as well tell me what you ate for breakfast, lol
d
Vegemite on toast FWIW 😛
👍 1
b
That install command has nothing to do with starting the server or downloading the actual FR jar (which is separate from the module)
d
Ok, let me nuke this server and try again. You think the original server setup got a borked zip and hung onto it?
b
Also 
--debug
isn't a valid param to the 
install
command
I assume you intended to use 
--verbose
Why are you nuking the server?
d
correct 😬
b
Just clearing the bad artifact (which you did) should be fine
d
because its nice to start fresh and go thru the whole process, it only take a minute or two
b
ok
well, check the artifacts folder in your template VM or whatever and see what's in there
make sure there isn't a corrupt zip cached in the artifacts
it would be here
Copy code
~/.CommandBox/artifacts/fusionreactor/8.7.6/fusionreactor.zip
That's where artifacts are stored, and that's where the bad zip file was getting pulled from over and over that couldn't be unzipped
d
yeah I definitely remember looking in that folder and seeing a bunch of FR related files, not a zip
b
Not the same folder
You're probably thinking of the one under the server home where FR actually installs to
The artifacts folder will only ever have zip files inside of it
d
the one in the server home wasnt being created
b
Hmm, I'd have to see it then
There shouldn't be anything bug zips showing up in artifacts unless something went terribly wrong, lol
You didn't use the 
--doom
flag did you? 😉
d
No, but I really want to now....
artifacts dir looks good on the new install
server is all good too
cool, so just a bad artifact downloaded then?
b
It would appear
I would be interested in seeing what the error message was the first time it never downloaded
if something got interrupted, etc
Since the error likely changed from that first time to all the subsequent runs when it was just using the bad artifact
d
No worries, at least I know where to look if that ever pops up again, thanks Brad 👍
👍 1
Open in Slack
PreviousNext
Powered by