Publish also images based on ltsc2016

[augi]

It would be great if you published also images based on older ltsc2016 tag (now your images are based on 1809).

I would like to prepare a new PR but I don't know how exactly the build process works, how to ensure the build.cmd would be executed twice.

[stellirin]

The build process is pretty dumb, it just builds all images unless you pass a specific keyword to build just that image, eg build.cmd pg12.

Notes to self:

See if a registry manifest can make this simple for the end user, use https://hub.docker.com/_/hello-world/?tab=tags as a reference. Specifically, tags nanoserver-1809 and nanoserver-1803 exist, but also nanoserver which references both images (and also latest which references even more).

https://docs.docker.com/engine/reference/commandline/manifest/

[stellirin]

there are no ltsc* tags for nanoserver, only for servercore.

Suitable nanoserver tags to build on:

• 1709 (EOL)
• 1803 (EOL)
• 1809
• 1903
• 1909

As I understand it, servercore:ltsc2016 is the same as servercore:1607 but there's no corresponding nanoserver:1607 image available (it used to exists but is no longer available to pull).

[augi]

Yes, we need the version compatible with 10.0.14393 OS version, thus ltsc2016 or 1607 tag for microsoft/windowsservercore image.

The nanoserver respective tag seems to be mcr.microsoft.com/windows/nanoserver:10.0.14393.2551, or simpler mcr.microsoft.com/windows/nanoserver:sac2016 (they have the same digest: sha256:2b783310e6c82de737e893abd53ae238ca56b5a96e2861558fb9a111d6691ddb).

So maybe the solution would be to have possibility to specify tag for nanoserver and servercore separately. It would be sac2016 and ltsc2016.

[stellirin]

It seems there could be an issue with the sac2016 image:

Step 13/22 : RUN mkdir "C:\\docker-entrypoint-initdb.d"
 ---> Using cache
 ---> ff03810dc36f
Step 14/22 : COPY --from=prepare /pgsql /pgsql
 ---> Using cache
 ---> 83a9310a4e4a
Step 15/22 : USER ContainerAdministrator
 ---> Using cache
 ---> 40f6c248d1e1
Step 16/22 : RUN setx /M PATH "C:\\pgsql\\bin;%PATH%"
 ---> Running in 1b83c62e938b
container 1b83c62e938b7595b7ec58c48ac6c1a633ac8306c72c5add6655e3cd721b2f58 encountered an error during CreateProcess: failure in a Windows system call: The user name or password is incorrect. (0x52e)
[Event Detail:  Provider: 00000000-0000-0000-0000-000000000000] extra info: {"CommandLine":"cmd /S /C setx /M PATH \"C:\\\\pgsql\\\\bin;%PATH%\"","User":"ContainerAdministrator","WorkingDirectory":"C:\\","CreateStdInPipe":true,"CreateStdOutPipe":true,"CreateStdErrPipe":true,"ConsoleSize":[0,0]}

[stellirin]

I pushed a rewritten build.cmd, you can probably reproduce the above error with build.cmd pg12 win1607.

[augi]

Thank you very much for solving this for me, very appreciated!

I tried to run the build.cmd pg96 win1607 and got the same error as you.

I found this interesting comment about change of the default user in the Windows base images.

[augi]

The instruction USER ContainerAdministrator doesn't work with 2016. It was introduced with 1709...

So the solution is not to perform the USER ContainerAdministrator in case of win1607. I confirmed this on my machine.

[augi]

I've just also tried to execute the image built and it seems that also the second USER directive is causing the same problem, but when executing the entrypoint.

So the correct solution is not to use the USER directives for these old base images.

EDIT: The image built without USER directives writes this when executed, and exits with exit-code 1:

The files belonging to this database system will be owned by user "ContainerAdministrator".
This user must also own the server process.

The database cluster will be initialized with locale "C".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory C:/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default timezone ... Europe/Belgrade
selecting dynamic shared memory implementation ... windows
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... child process was terminated by exception 0xC000001D
initdb: removing contents of data directory "C:/pgsql/data"
****************************************************
WARNING: No password has been set for the database.
         This will allow anyone with access to the
         Postgres port to access your database. In
         Docker's default configuration, this is
         effectively any other container on the same
         system.
         Use "-e POSTGRES_PASSWORD=password" to set
         it in "docker run".
****************************************************
authMethod: trust
The system cannot find the drive specified.
PostgreSQL init process complete; ready for start up.

[augi]

C:\Users\augustyn>docker run --rm mcr.microsoft.com/windows/nanoserver:sac2016 powershell Get-LocalUser

Name           Enabled Description
----           ------- -----------
Administrator  True    Built-in account for administering the computer/domain
DefaultAccount False   A user account managed by the system.
Guest          False   Built-in account for guest access to the computer/domain

[augi]

When I tried to execute the container as Administrator (-u Administrator) then the output is slightly different (but the container still exits):

The files belonging to this database system will be owned by user "Administrator".
This user must also own the server process.

The database cluster will be initialized with locale "C".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory C:/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default timezone ... Europe/Belgrade
selecting dynamic shared memory implementation ... windows
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... child process was terminated by exception 0xC000001D
initdb: removing contents of data directory "C:/pgsql/data"
****************************************************
WARNING: No password has been set for the database.
         This will allow anyone with access to the
         Postgres port to access your database. In
         Docker's default configuration, this is
         effectively any other container on the same
         system.
         Use "-e POSTGRES_PASSWORD=password" to set
         it in "docker run".
****************************************************
authMethod: trust
The system cannot find the drive specified.
pg_ctl: directory "C:/pgsql/data" is not a database cluster directory
pg_ctl: directory "C:/pgsql/data" is not a database cluster directory
PostgreSQL init process complete; ready for start up.
Execution of PostgreSQL by a user with administrative permissions is not
permitted.
The server must be started under an unprivileged user ID to prevent
possible system security compromises.  See the documentation for
more information on how to properly start the server.

[stellirin]

What's the specific reason you need an image based on 1607? Personally I don't think it's worth to continue with sac2016 since it's long EOL and the image is clearly lacking.

I'm also wondering if it makes sense to continue with nanoserver in general due to the lack of PowerShell.

A rebase on servercore gives the advantage of PowerShell and longer support periods for some images (it seems there's no concept of LTS on nanoserver).

Also, upstream significantly refactored the postgres entrypoint script and that's gonna be a pain to re-implement in batch script, if it's possible at all.

It'll take a bit of effort but it's probably worth to start from scratch with a PowerShell based entrypoint instead of batch script. We can still have smaller images using the nanoserver variants of https://hub.docker.com/_/microsoft-powershell

[augi]

The reason is that we are still running some workload on Windows Server 2016 (as native Windows Containers) and I think that we can run 1607-based images only (correct me if I'm wrong).

I agree that it's not worth the effort to support so old base images.