Linux CLI 0.3 Not Working

dvalentiate
dvalentiate
Community Member

When trying to singin with 0.3 version of the cli I am getting:

user: Current not implemented on linux/386

A little googling reveals this is a Go cross compile issue

Command that produces the above error:
op signin <account>.1password.com <email> <secret-key>

Enviroment:
Alpine and Ubuntu linux

It looks like someone at 1Password will need to try again on the compilation of 0.3 for linux. I did not have this trouble with version 0.2.

The following is a docker container Dockerfile that can reproduce the issue:

FROM alpine:latest as build
ARG OP_CLI_VERSION
RUN apk --no-cache add curl && \
  curl -sS -o 1password.zip https://cache.agilebits.com/dist/1P/op/pkg/v${OP_CLI_VERSION}/op_linux_386_v${OP_CLI_VERSION}.zip && \
  unzip 1password.zip op -d /usr/bin && \
  rm 1password.zip
FROM alpine:latest
COPY --from=build /usr/bin/op /usr/bin/
RUN apk --no-cache add ca-certificates
ENTRYPOINT ["/usr/bin/op"]
docker build --build-arg OP_CLI_VERSION=0.3 -t 1password .
docker run -it --rm 1password signin <account>.1password.com <email> <secret-key>

For good measure I also tested against Ubuntu just to make sure it wasn't something about Alpine. It also throws the not implemented error. That Dockerfile looks like:

FROM ubuntu as build
ARG OP_CLI_VERSION
RUN apt-get update && apt-get install -y curl unzip ca-certificates && \
  curl -sS -o 1password.zip https://cache.agilebits.com/dist/1P/op/pkg/v${OP_CLI_VERSION}/op_linux_386_v${OP_CLI_VERSION}.zip && \
  unzip 1password.zip op -d /usr/bin && \
  rm 1password.zip
ENTRYPOINT ["/usr/bin/op"]

1Password Version: 0.3
Extension Version: Not Provided
OS Version: Linux
Sync Type: Not Provided
Referrer: forum-search:cli linux

Comments

  • jpgoldberg
    jpgoldberg
    1Password Alumni

    user: Current not implemented on linux/386

    I wonder if this is the $Tempdir stuff. That is where we use os/user.

  • Hi @dvalentiate,

    Ugh, that sucks. Thanks for the info, we'll dig in and try to figure out what we can do to make this better. You're right that we're cross-compiling. In this case the original machine is a Linux/amd64 setup.

    I assume you're running this on old hardware that isn't amd64 compatible?

    Rick

  • dvalentiate
    dvalentiate
    Community Member

    I'm on a Mac (x86) that is running docker and building a linux docker image. For distribution to other x86 hosts.

    I just tried substituting 386 with amd64 in the curl URL in the above images but it ends up saying standard_init_linux.go:185: exec user process caused "no such file or directory". To me this seems odd in that it appears to have tried to execute something. However I then tried removing the entry point and running /usr/bin/op from within the shell (/bin/sh) and then it just returns /bin/sh: /usr/bin/op: not found despite the file looking okish

    -rwxr-xr-x    1 root     root       6400128 Mar 21 21:05 /usr/bin/op
    
  • agiletim
    agiletim
    1Password Alumni
    edited March 2018

    @dvalentiate can you try adding
    -e "USER=root"
    to your command?
    so the full command looks like:

    docker run -e "USER=root" -it --rm 1password signin <account>.1password.com <email> <secret-key>
    
  • dvalentiate
    dvalentiate
    Community Member

    @agiletim "USER=root" does the trick, thanks!

  • AGAlumB
    AGAlumB
    1Password Alumni

    Excellent! Thanks for the update. On behalf of Tim, you are most welcome! It sounds like you should be all set, but don't hesitate to reach out if we can be of further assistance. Cheers! :)

  • dvalentiate
    dvalentiate
    Community Member

    Updated the Docker CLI discussion with instructions for version 0.3 https://discussions.agilebits.com/discussion/comment/418060/#Comment_418060

  • AGAlumB
    AGAlumB
    1Password Alumni

    Thanks for contributing that! :) :+1:

  • jpgoldberg
    jpgoldberg
    1Password Alumni
    edited March 2018

    Thanks @dvalentiate!

    Note that we also having a fix coming.

    There are two things that both need to happen for the bug to appear.

    1. The CLI is cross-compiled. When it is cross-compiled, user.Current() falls back to os.Getenv(USER) instead of using the OS's getuid() system call. Thus in these cases it expects $USER to be in the environment. We don't natively compile for i386.

    2. $USER is not defined. Which appears to be the case in docker environments.

    So in a forthcoming version, if user.Current() fails we assume that the CLI is running on "single user" system. Instead of just erroring out in that case, we just use a constant string (instead of a username) to the directory created in /tmp.

This discussion has been closed.