Linux CLI 0.3 Not Working
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
-
user: Current not implemented on linux/386
I wonder if this is the $Tempdir stuff. That is where we use
os/user
.0 -
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
0 -
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
withamd64
in the curl URL in the above images but it ends up sayingstandard_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
0 -
@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>
0 -
@agiletim "USER=root" does the trick, thanks!
0 -
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! :)
0 -
Updated the Docker CLI discussion with instructions for version 0.3 https://discussions.agilebits.com/discussion/comment/418060/#Comment_418060
0 -
Thanks for contributing that! :) :+1:
0 -
Thanks @dvalentiate!
Note that we also having a fix coming.
There are two things that both need to happen for the bug to appear.
The CLI is cross-compiled. When it is cross-compiled,
user.Current()
falls back toos.Getenv(USER)
instead of using the OS'sgetuid()
system call. Thus in these cases it expects$USER
to be in the environment. We don't natively compile for i386.$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
.0