mq-container icon indicating copy to clipboard operation
mq-container copied to clipboard

Container fails to Start on Windows 2k19 server

Open sidprasher opened this issue 5 years ago • 7 comments

I am trying to setup the IBM MQ container image on an azure windows 2019 server VM. I have enabled LCOW and set the experimental feature to true. Below are some of the important configurations -

    C:\Users\xyz>docker info
        Client:
         Debug Mode: false
         Plugins:
          cluster: Manage Docker clusters (Docker Inc., v1.2.0)

     Server Version: 19.03.5
...
     Storage Driver: windowsfilter (windows) lcow (linux)
      Windows:
      LCOW:
     Logging Driver: json-file
     Plugins:
      Volume: local
      Network: ics internal l2bridge l2tunnel nat null overlay private transparent
      Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
     Swarm: inactive
     Default Isolation: process
     Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
     Operating System: Windows Server 2019 Datacenter Version 1809 (OS Build 17763.1039)
     OSType: windows
     Architecture: x86_64
    ...
 Debug Mode: false
     Registry: https://index.docker.io/v1/
     Labels:
     Experimental: true
     Insecure Registries:
      127.0.0.0/8
     Live Restore Enabled: false

When i run the image it crashes after a few seconds. The log of the container is as below -

    2020-03-17T15:47:10.082Z CPU architecture: amd64
    2020-03-17T15:47:10.083Z Linux kernel version: 4.14.35-linuxkit
    2020-03-17T15:47:10.084Z Base image: Red Hat Enterprise Linux 8.1 (Ootpa)
    2020-03-17T15:47:10.095Z Running as user ID 0 (root) with primary group 0
    2020-03-17T15:47:10.095Z Capabilities (bounding set): chown,dac_override,fowner,fsetid,kill,setgid,setuid,setpcap,net_bind_service,net_raw,sys_chroot,mknod,audit_write,setfcap
    2020-03-17T15:47:10.095Z seccomp enforcing mode: disabled
    2020-03-17T15:47:10.096Z Process security attributes: none
    2020-03-17T15:47:10.097Z Detected '9p' volume mounted to /mnt/mqm
    2020-03-17T15:47:10.248Z Set password for "admin" user
    2020-03-17T15:47:10.321Z Set password for "app" user
    2020-03-17T15:47:10.369Z Using queue manager name: QM1
    2020-03-17T15:47:11.088Z Created directory structure under /var/mqm
    2020-03-17T15:47:11.089Z Image created: 2019-12-05T18:39:02+00:00
    2020-03-17T15:47:11.089Z Image tag: ibm-mqadvanced-server-dev:9.1.4.0-r1-amd64
    2020-03-17T15:47:11.478Z MQ version: 9.1.4.0
    2020-03-17T15:47:11.478Z MQ level: p914-L191127.DE
    2020-03-17T15:47:11.478Z MQ license: Developer
    2020-03-17T15:47:12.859Z Creating queue manager QM1
    2020-03-17T15:47:12.859Z Starting web server
    **2020-03-17T15:47:13.291Z Error 119 creating queue manager: AMQ7077E: You are not authorized to perform the requested operation.**

    2020-03-17T15:47:13.292Z /usr/bin/crtmqm: exit status 119

What additional privileges does it need? I am running these commands from an admin role

sidprasher avatar Mar 18 '20 13:03 sidprasher

MQ needs files on the volume to be owned by the mqm user, and from MQ 9.1.2, the container expects to be running as that user. One thing you can do is to try running the following:

docker run -d -e LICENSE=accept --entrypoint=runmqserver --user 0 --volume myvol:/mnt/mqm ibmcom/mq -i

This will run a container as root, and the -i will just initialize the volume (i.e. change the file permissions so everything's owned by mqm) and then exit. You should then be able to run the container as normal.

Alternatively, the problem could be related to the 9p filesystem which is being used for the Docker volume. It could be that it doesn't support the right characteristics for MQ. You could try this:

docker run -d --entrypoint=/opt/mqm/bin/amqmfsck ibmcom/mq /var/mqm

This will run a container using the MQ image, and run some basic filesystem checks.

arthurbarr avatar Mar 18 '20 16:03 arthurbarr

@arthurbarr :Thanks for the reply but i am not sure if i completely understood you. In the log that i shared it states that the process starts as user 0

2020-03-17T15:47:10.082Z CPU architecture: amd64
    2020-03-17T15:47:10.083Z Linux kernel version: 4.14.35-linuxkit
    2020-03-17T15:47:10.084Z Base image: Red Hat Enterprise Linux 8.1 (Ootpa)
    2020-03-17T15:47:10.095Z Running as user ID 0 (root) with primary group 0

docker run -d --entrypoint=/opt/mqm/bin/amqmfsck ibmcom/mq /var/mqm seems to fail. The logs give me the same authorization error AMQ7077E: You are not authorized to perform the requested operation.


Just to add the container runs perfectly on my Windows 10 pro laptop

sidprasher avatar Mar 19 '20 12:03 sidprasher

OK, so that indicates that the volume you're providing to the container doesn't have matching permissions to the user running inside the container. It ultimately just uses standard UNIX file permissions. You will be able to determine the permissions on the volume if you do this:

docker run -d --entrypoint=ls --volume myvolume:/mnt/mqm ibmcom/mq -la /mnt/mqm

If you do that, then look at the logs, you'll see who is authorized to write to that volume, which should help us make some progress.

arthurbarr avatar Mar 19 '20 14:03 arthurbarr

This is the output

total 4 drwxrwxrwx 1 root root 4096 Mar 19 16:42 . drwxrwxr-x 1 mqm root 4096 Dec 5 18:41 ..


docker run -d --entrypoint=ls --volume qm1data:/mnt/mqm ibmcom/mq -la /mnt/mqm

total 4 drwxrwxrwx 1 root root 4096 Mar 6 15:21 . drwxrwxr-x 1 mqm root 4096 Dec 5 18:41 .. drwxrwsr-x 1 mqm mqm 4096 Mar 6 15:21 data

sidprasher avatar Mar 19 '20 16:03 sidprasher

Is root in the "mqm" group?

davidjmccann avatar Mar 19 '20 18:03 davidjmccann

Sorry but how can i check this? I see the following results -

PS C:\Users\sysadmin> docker run -it --entrypoint="whoami" ibmcom/mq
root
PS C:\Users\sysadmin> docker run -it --entrypoint="id" ibmcom/mq
uid=0(root) gid=0(root) groups=0(root)
PS C:\Users\sysadmin> docker run -it --entrypoint="groups" ibmcom/mq
root

so does that mean root is not member of mqm?

sidprasher avatar Mar 19 '20 22:03 sidprasher

It doesn't look like it, no. I suspect you're getting authorization failures because only members of the "mqm" administrative group can start queue managers.

davidjmccann avatar Mar 20 '20 07:03 davidjmccann