Zero-to-jupyterhub-k8s: GRANT_SUDO on started servers

Created on 5 Mar 2018  Â·  25Comments  Â·  Source: jupyterhub/zero-to-jupyterhub-k8s

Hello
I don't seem to be able to grant SUDO permission on the started instance. The container should have the GRANT_SUDO environment variable and be started as root, and the later condition does not seem to be met.

I have put this env in extraEnv and does see in the started container:

  extraEnv:
    GRANT_SUDO: "yes"
question

Most helpful comment

@manics, @gsemet: I was able to get this working with:

singleuser:
   extraEnv:
      GRANT_SUDO: "yes"
   uid: 0
   cmd: null

By default, the chart's values.yaml hard-codes running jupyter-singleuser, rather than running /usr/local/bin/start-notebook.sh, which is the default container command for the jupyter/docker-stacks images that ultimately calls start.sh to do all the sudo magic. Setting singleuser.cmd to null restores the default behavior.

All 25 comments

so, it does not work because jupyterhub starts the user server using the user id and not root (see base-notebook/start.sh#L57.

My current mitigation is to overload the docker image with my own docker layer:

RUN echo "$NB_USER ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/notebook

Thanks for bringing this up! We should document how to do this!

You can grant sudo by:

singleuser:
   extraEnv:
      GRANT_SUDO: "yes"
   uid: 0

The uid:0 will start the notebook as root, and you won't need extra entries.

ok, and after it will still start the notebook server as joyvan as usual, right?

It should, yeah - at least with the default image / docker-stacks images.
The user id switching is done in the scripts in the image.

On Thu, Mar 15, 2018 at 12:51 PM, Gaetan Semet notifications@github.com
wrote:

ok, and after it will start the notebook server as joyvan as usual, right?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/562#issuecomment-373501824,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB23hg2-SqV7-Yu-5Ep75tZ9OUT06khks5tesYxgaJpZM4ScF3K
.

--
Yuvi Panda T
http://yuvi.in/blog

I get an error "Running as root is not recommended" when using uid: 0 and of course the extraEnv.GRANT_SUDO: "yes", like if "start-notebook.sh" isn't called, but it is, since it is the entrypoint of the image (using the base-notebook image)

ah I forgot about that, @gsemet! Would be awesome if you can open a docs PR :)

I don't have a proper solution yet, for the moment I hardcode the sudoers hack in a customized derived notebook docker image....

@manics got an idea for something to make us actionable in general about this issue?

@manics, @gsemet: I was able to get this working with:

singleuser:
   extraEnv:
      GRANT_SUDO: "yes"
   uid: 0
   cmd: null

By default, the chart's values.yaml hard-codes running jupyter-singleuser, rather than running /usr/local/bin/start-notebook.sh, which is the default container command for the jupyter/docker-stacks images that ultimately calls start.sh to do all the sudo magic. Setting singleuser.cmd to null restores the default behavior.

@manics, @gsemet: I was able to get this working with:

singleuser:
   extraEnv:
      GRANT_SUDO: "yes"
   uid: 0
   cmd: null

By default, the chart's values.yaml hard-codes running jupyter-singleuser, rather than running /usr/local/bin/start-notebook.sh, which is the default container command for the jupyter/docker-stacks images that ultimately calls start.sh to do all the sudo magic. Setting singleuser.cmd to null restores the default behavior.

Sadly this is not an option when wanting to use jupyterlab, as one normally should set jupyter-labhub as spawner.cmd which interferes with setting the cmd: null on singleuser.

Is there currently a different option than to set the NOPASSWD:ALL manually in the custom image as proposed by @gsemet when wanting to use both jupyterlab and sudo?

NEW UPDATE:
setting JUPYTER_ENABLE_LAB as an environment variable in the container image helps :
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/562#issuecomment-453974027

Seems a bit hacky to me altogether, but it works.

@manics Just a quick detail plug without reading the discussion up to this point. The JUPYTER_ENABLE_LAB env. variable is utilized by the docker-stacks images' start-notebook.sh script, but to get the jupyter server aware of the JupyterHub that spawned it, we have used start-singleuser.sh instead, why I have not looked into fully yet. That script is also utilizing the JUPYTER_ENABLE_LAB env variable though, and starting jupyter-labhub binary indirectly through jupyter labhub.

Yes that works. Thanks guys!

Maybe it would make the configuration work a bit more fluent, if instead of specifying jupyter-labhub as singleuser.cmd and singleuser.defaulturl in the config.yaml (or maybe adding to it), one would have a jupyterlab toggle, that when set to true will set the values in the jupyterhub configuration and set the environment variable.

On the other hand, that would make it less consistent with other usecases of defaulturl and the cmd, but jupyterlab also feels like a special case to me judging from its soon-to-be-default status.
(When setting it as default, usability of granting sudo should probably also be tested during the process.)

singleuser.uid=0 seems to throw "Running as root is not recommended. Use --allow-root to bypass." for me which prevents the container from coming up properly.

My use case is:

  1. Install editor, packages etc. to container via apt-get
  2. Easily run a start-up script from the command line without having to go the image registry route
  3. Do the above in jupyterlab

I still can't get sudo working for jovyan despite the comments above in this thread. @dkipping Am I missing something obvious? All the envs are set for singleuser, and none for hub - right?

I can get jupyterlab working nicely but again without sudo.

Very grateful for any and all help - many thanks

@jtlz2 can you paste or link to your configuration and Dockerfile? There are several suggestions in this thread, so please give us more detail on your current setup.

@manics Many thanks. Here you go:

helm upgrade --tiller-namespace=myns --install saturn jupyterhub/jupyterhub --namespace=myns --version=0.8.2 --values=config.yaml

config.yaml -

hub:
  # output of first execution of 'openssl rand -hex 32'
  cookieSecret: "secret1"
#  imagePullPolicy: Always
#  image:
#    name: jupyterhub/k8s-hub
#    tag: 0.8.2
  extraConfig:
    jupyterlab: |
      c.Spawner.cmd = ['jupyter-labhub']
      c.InteractiveShellApp.exec_lines = ['!pip install --upgrade pip']
proxy:
  # output of second execution of 'openssl rand -hex 32'
  secretToken: "secret2"
  service:
    type: ClusterIP
prePuller:
  continuous:
    enabled: false
  hook:
    enabled: false
cull:
  enabled: false
  # timeout:
  # every:
auth:
  admin:
    users:
      - jtlz2
  whitelist:
    users:
      - jtlz2
singleuser:
  defaultUrl: "/lab"
  #extraEnv:
  #  GRANT_SUDO:
  #    "yes"
  #uid: 0
  #cmd: null
  storage:
    extraVolumes:
    - name: secrets
      secret:
        secretName: secrets
    extraVolumeMounts:
      - name: secrets
        mountPath: "/secrets"
        readOnly: true
#  imagePullPolicy: Always
#  image:
#    name: jupyterhub/k8s-singleuser-sample
#    tag: 0.8.2
ingress:
  enabled: false

Thanks!

  extraConfig:
    jupyterlab: |
      c.Spawner.cmd = ['jupyter-labhub']
      c.InteractiveShellApp.exec_lines = ['!pip install --upgrade pip']

This sets the startup command to jupyter-labhub. Can you try removing that and setting singleuser.cmd: null as in https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/562#issuecomment-453968479?

I also cannot get this approach to work. I'm not trying to default to JupyterLab, so I just inserted the singleuser code. Do I need to do something else? My config file is as follows:

proxy:
  secretToken: "..."
  networkPolicy:
    enabled: true
  service:
    type: NodePort
  https:
    enabled: false

auth:
  whitelist:
    users:
      - efry
  admin:
    users:
      - admin

hub:
  image:
    name: ...
    tag: "0.8.2-0.2"

  extraConfig:
    myConfig.py: |
      c.JupyterHub.authenticator_class = 'firstuseauthenticator.FirstUseAuthenticator'

singleuser:
  storage:
    capacity: 1Gi
    extraVolumes:
      - name: mypvc
        persistentVolumeClaim:
          claimName: nfs-shared-pvc
    extraVolumeMounts:
      - name: mypvc
        mountPath: /home/jovyan/shared
  extraEnv:
    GRANT_SUDO: "yes"
  uid: 0
  cmd: null

  image:
    name: ...
    tag: 0.8

ingress:
  enabled: true
  hosts:
    - ...
  pathSuffix: '*'
  annotations:
    kubernetes.io/ingress.global-static-ip-name: jupyterhub-static-ip

@manics Extremely belatedly - just tested - your scheme works! Thank you so so much :)

JUPYTER_ENABLE_LAB not needed

Note, starting jupyter-labhub was meant to add a menu item about JupyterHub to JupyterLab. This is now done automatically with JupyterLab itself, and jupyter-labhub isn't needed any more and has been deprecated (see: https://github.com/jupyterhub/jupyterlab-hub).

Also, the JUPYTER_ENABLE_LAB interpreted by the docker-stack's start scripts are used to run jupyter-labhub. So, now we don't need that. See: https://github.com/jupyter/docker-stacks/blob/137a295ff71bcdaf36047e06ba724ab842f866ef/base-notebook/start-singleuser.sh#L37-L41

I understand it as we need to start jupyterhub-singleuser in order to let the notebook server itself be Hub aware though, and to start within jupyterlab, we need to have a defaultUrl set.

My best current understanding, on how to get JupyterLab running by default, with SUDO access for users, in z2jh, is like this:

singleuser:
  defaultUrl: /lab
  extraEnv:
    GRANT_SUDO: "yes"
    NOTEBOOK_ARGS: "--allow-root"
  uid: 0
  cmd: start-singleuser.sh

Note that GRANT_SUDO will be ignored by the start scripts unless it is started as the root user (uid=0).

UPDATE

I'm working to resolve this for myself currently, the configuration above isn't enough I think.

Based on comments above and this comment, the following config enabled JupyterLab with sudo access for users using the 0.9.0-beta.3 chart:

singleuser:
  extraEnv: 
    GRANT_SUDO: "yes"
    NOTEBOOK_ARGS: "--allow-root"
  uid: 0
  cmd: start-singleuser.sh
  defaultUrl: "/lab"
hub:
  extraConfig:
    jupyterlab: |
      c.Spawner.default_url = "/lab"

@ilhaan these parts are doing the same thing, only one is needed.

singleuser:
  defaultUrl: "/lab"
hub:
  extraConfig:
    jupyterlab: |
      c.Spawner.default_url = "/lab"

@consideRatio Thanks! I think I had that left over from an older config and didn't remove it since things were in working condition.

I'm closing this as it seems to be resolved.

Was this page helpful?
0 / 5 - 0 ratings