hack your fridge or die trying: Windows

Friday, 15 February 2019

Pivotal Cloud Foundry - "access denied" for custom buildpacks written on Windows

Writing custom buildpacks on Windows can lead to some unnecessary frustrations. Today I would like to cover one of those frustrations: buildpack scripts not being executable on PCF. Creating buildpack scripts on windows can lead to cryptic errors during buildpack execution like "access denied" or "permission denied".

The problem is caused by the fact that any new file created on Windows is automatically set to mode 644 aka rw-r--r-- (linux standards), but at the same type is automatically executable (-rwxr-xr-x) by windows standards.

Result? Listing your buildpack scripts using git bash on windows you see:

drwxr-xr-x 1 Piotr_Justyna 1049089    0 Feb 13 20:46 ./
drwxr-xr-x 1 Piotr_Justyna 1049089    0 Feb 13 20:44 ../
-rwxr-xr-x 1 Piotr_Justyna 1049089  137 Feb 13 20:44 detect*
-rwxr-xr-x 1 Piotr_Justyna 1049089   40 Feb 13 20:46 finalize*
-rwxr-xr-x 1 Piotr_Justyna 1049089  102 Feb 13 20:44 release*
-rwxr-xr-x 1 Piotr_Justyna 1049089  135 Feb 13 20:46 supply*

While in fact all of them are by default mode 644 (rw-r--r--). Trying to execute those scripts on PCF will result in "access denied" errors. It is pretty annoying, so I prepared a little cheat sheet for those of you who work with custom buildpacks, windows and git bash:

Executable files:

DON'T:
```
chmod +x file
```
DO:
```
git update-index --chmod=+x file
```

List files with their access modes:

DON'T:
```
ls -la
```
DO:
```
git ls-files -s
```

Copying files:

DON'T:

cp file file_copy (that defaults the access mode of the copy to 644 even if the file is e.g. 755)

DO:

cp file file_copy *and then* git update-index --chmod=+x file_copy

chmod-calculator.com is a very handy tool, especially for those who don't work with linux too often.

Saturday, 30 September 2017

Docker image to build and run your Haskell Warp server code (built on Windows).

At the time of writing this, the most helpful resources I could find covering this were simply:

I played a bit with the two and came up with my own version, suitable to produce images able to build and host simple Haskell server code. This is no production setup, but will open the door to more fine-tuned experimentation.

Let's jump right into it!

First of all, here is the source code of a minimal Haskell Warp server I'm going to be hosting: haskell-warp.

Secondly, the dockerfile (also contained in the github repository from the previous point):

FROM ubuntu:16.04

MAINTAINER piotr - dot - justyna - at - gmail.com

# Install dependencies.
RUN apt-get update && \
    apt-get install --assume-yes curl gcc libgmp-dev make xz-utils zlib1g-dev

# Install Stack.
RUN curl --location https://www.stackage.org/stack/linux-x86_64-static > stack.tar.gz && \
  tar xf stack.tar.gz && \
  cp stack-*-linux-x86_64-static/stack /usr/local/bin/stack && \
  rm -f -r stack.tar.gz stack-*-linux-x86_64-static/stack && \
  stack --version

# Install GHC.
WORKDIR /haskell-warp
COPY haskell-warp/stack.yaml /haskell-warp
RUN stack setup && stack exec -- ghc --version

# Build.
COPY /haskell-warp /haskell-warp
RUN stack build --copy-bins --local-bin-path /usr/local/bin

# Run project.
ENV HOST 0.0.0.0
ENV PORT 3000
EXPOSE 3000
CMD /usr/local/bin/haskell-warp-exe

Now it's time to build my image (this will take a good while):
```
$ docker build -t haskell-ubuntu:16.04 .
```

Next, time to create a running container from the image:

docker run --name haskell-warp -d -p 80:3000 haskell-ubuntu:16.04

Finally, time to test the code we've just deployed:

And that's it! We've just built ourselves a working image able to host a Haskell Warp server.

Keep hacking!
Piotr