Continue working on the Elastic Beanstalk section of Part Two

content/posts/OWASPJuiceShopDeployingSecuring/Two/index.md

@@ -293,3 +293,31 @@ Possibly it's something to do with the OJS zip upload.  To double-check that, I
 
 ##### Back to the OJS
 
+At this point, I know that the unhelpful error message from above related to the OJS zip, rather than any misconfiguration for EB.  I'm not really sure _what_ the problem with the zip is, however.  Now that the sample application deployment has gone through, EB has created an S3 bucket from which files can be drawn to run.  I tried uploading the OJS zip straight into the bucket, so that I can then tell AWS to retrieve it from there when trying to deploy the application, but I get back exactly the same error.  All I know for sure is that this is the totality of the error message:
+
+> InvalidPart
+> 
+> One or more of the specified parts could not be found. The part may not have been uploaded, or the specified entity tag may not match the part's entity tag.
+
+With all of this failing, I decided to try out uploading the Linux-specific, Node.js v18, version of the OSJ release v15.  I hit precisely the same result, however.  Let's see what ye olde search engine comes up with on that error message.  The [S3 docs](https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html) list it as a possible error message, but don't seem to link to any guidance on how to handle the problem.  [Another page](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) describes using the S3 Console to perform an upload, but just directs precisely what I am already doing. I found a couple of Stack Overflow posts and other things discussing the error message, but it looks like every single one of them is for when someone is using an AWS API to perform uploads, rather than just going through the Console.  I tried out a different browser, on the off-chance my regular browser had something to do with it, and it worked...  Zero clue what, precisely, the issue has been all along, but it appears to be something funky going on with my browser, rather than anything else.[^multipart-upload]
+
+[^multipart-upload]:  Of course, the S3 bucket is also filled with hidden pieces from failed multipart uploads, which you can't manually scrub.  I _think_ I followed the suggested instructions appropriately to sweep the bucket clean automatically.
+
+Now let's try all of that again.  This time, with the zip in a public S3 bucket, EB does indeed get further than before.  Eventually it all fails with the error "Instance deployment failed to generate a 'Procfile' for Node.js. Provide one of these files: 'package.json', 'server.js', or 'app.js'. The deployment failed.", then eventually I realise that was probably because the OJS zip contains an enclosing folder, whereas the AWS requires the relevant files to be at the top level of the zip.  At least, I think I read that somewhere.  Thus, I twiddle the zip to match that pattern and try again.  Unfortunately, it's not really clear to me how to update an EB environment's configuration to use a different file that's already stored in S3, so I'll have to do the whole process over again.  At least when I deleted the application out of EB, it did automatically terminate the associated EC2 instance that had been fired up.
+
+That also fails after a time, and after even more time I can finally figure out how to access the relevant logs from the EC2 instance, and find that the offending error message seems to be this:
+
+```shell
+[ERROR] An error occurred during execution of command [app-deploy] - [StageApplication]. Stop running the command. Error: Command /bin/sh -c /usr/bin/unzip -q -o /opt/elasticbeanstalk/deployment/app_source_bundle -d /var/app/staging/ failed with error exit status 1. Stderr:frontend/src/assets/public/images/uploads/my-rare-collectors-item!-[̲̅$̲̅(̲̅-͡°-͜ʖ-͡°̲̅)̲̅$̲̅]-1572603645543.jpg:  mismatching "local" filename (frontend/src/assets/public/images/uploads/my-rare-collectors-item!-[╠▓╠Е$╠▓╠Е(╠▓╠Е-═б┬░-═Ь╩Ц-═б┬░╠▓╠Е)╠▓╠Е$╠▓╠Е]-1572603645543.jpg),
+         continuing with "central" filename version
+frontend/src/assets/public/images/uploads/😼-#zatschi-#whoneedsfourlegs-1572600969477.jpg:  mismatching "local" filename (frontend/src/assets/public/images/uploads/ЁЯШ╝-#zatschi-#whoneedsfourlegs-1572600969477.jpg),
+         continuing with "central" filename version
+```
+
+Looking at this, I can see that there's some sort of issue around a couple of file names.  I don't fully understand what I'm looking at it, but it looks to me like the file names included non-ASCII characters (including an emoji one of them), and I think something somewhere (possibly the `unzip` utility?) has escaped or modified those file names, then when the original and modified file names don't match, AWS doesn't like it and fails.  Actually, [it](https://stackoverflow.com/q/42971779) [turns](https://stackoverflow.com/q/42971779) out that it's an error with unzip itself.  It [seemingly](https://topic.alibabacloud.com/a/unzip-unzipping-garbled-mismatching-local-filename-and-continuing_8_8_32447306.html) doesn't always like arbitrary UTF-8 in file names by default, and unfortunately I can't control the precise unzip command used.  At least it was a different error from before, suggesting that I did indeed address one issue.
+
+Out of curiousity, I dove into the rejigged zip file to see if I could find the relevant files.  It turns out they are indeed in the `/frontend/src/assets/public/images/uploads` directory.  Their _correct_ names are "😼-#zatschi-#whoneedsfourlegs-1572600969477.jpg" and "my-rare-collectors-item!-[̲̅$̲̅(̲̅-͡°-͜ʖ-͡°̲̅)̲̅$̲̅]-1572603645543.jpg" (that second one looks much better when viewed in 7zip as compared to here).  To see if I can get any further, I rename the files in that zip, upload it again to S3, and try deploying again.  For some reason, the first attempt eventually failed with a timeout after 16 minutes.  I really don't know what happened there.  In the hope that it's a stroke of misfortune, I try rebuilding the EB environment for the application.  Curiously, even just shutting down the existing running EC2 instance takes a long time.  Eventually it is terminated, however, and EB starts to make some progress again.  In the end, after the same 16 minutes, EB declares this one a success, even though it also considers it to have timed out.  The system status checks on the EC2 instance report that it's healthy, but also that no data has been received from the instance.  My attempt to SSH into the instance to try to check logs _eventually_ gets somewhere, but responses from the remote server seem to be very strongly delayed in arriving.  Moreover, attempts to navigate to the assigned public web address never resolve to anything.  Looking at the monitoring graphs, CPU utilisation seems to creep up a bit over time, but never gets close to maxing out as I might expect if everything was completely overloaded.
+
+I can eventually run `top` on the EC2 instance, and discover that, while `npm install` is taking a reasonable large chunk of the total memory, `kswapd0` is occupying a full vCPU core.  Which is slightly strange, since `top` seems to indicate that there isn't any swap space on the system.  Anyway, my best guess is that this another time where the available memory for OJS just isn't as large as required for starting it up, and so operations grind to a halt while it tries to handle that.  I'll give a little while longer, and see if it manages to get anywhere.  Perhaps using one of the release zips prebuilt for a given OS can help avoid much of this issue in the future.  If I remember correctly, once it is all fully installed, OJS doesn't require serious resources.  Setting up, however, may be another matter altogether...  Even after waiting around 90 minutes, it seemed like the application was still struggling, either because it was still dealing with memory issues, or for some other reason I couldn't see.  Either way, this clearly was not a successful deployment, so I just terminated the whole application.  Will have to try again with the pre-built Linux release, instead.
+
+