pdobsan
alpine linux build works but receive "secret-tool: createProcess: posix_spawnp: does not exist (No such file or directory)"
Spent some good time to get oama building on alpine linux with minimal configuration and have worked thru all snags. Do not see many people running this publicly at least, here is my Dockerfile:
\# Dockerfile
FROM alpine:edge
RUN set -ex; \
apk add --update --no-cache isync ca-certificates tzdata; \
update-ca-certificates;
RUN apk add --update --no-cache git musl-dev zlib-dev
RUN apk add --update --no-cache ghc cabal
RUN apk add --update --no-cache g++
RUN git clone https://github.com/pdobsan/oama
RUN cd oama; \
cabal update;
RUN cd oama; cabal install --install-method=copy --installdir=/usr/local/bin
\# next four commented out steps are where my thinking landed when stock from the error below...
\# RUN apk add --update --no-cache dbus openrc
\# RUN rc-update add dbus
\# RUN rc-update dbus start
\# RUN touch /run/openrc/softlevel
USER root
ENV HOME=/root
CMD ["tail", "-f", "/dev/null"]
- NOTE, I broke up the various steps because I had to look inside the intermediate docker images in order to find problems at each step.
- In order to get access to the intermediate docker containers, had to learn about turning off the buildkit:
- From CLI $ DOCKER_BUILDKIT=0 docker build .
- docker commit 3bd7904ed4d2 tmpname
- in the above, replace 3bd7904ed4d2 with whatever intermediate container docker generates
- From CLI $ docker run -ti --net=host --rm tmpname sh
- Then you may inspect where the build steps broke (I'm writing here in case anyone gets brave, has issues like this in the future)
- If using docker-compose, you need to make sure your localhost can see external network, make sure your docker-compose.ymal has line for the service: network_mode: "host"
Ok, all the above work got my docker oama ready so I can get my oauth2 sorted by running the commands:
$ oama authorize google [email protected] --nohint
Authorization to grant OAuth2 access to [email protected] started ...
Visit http://localhost:42763/start in your browser ...
\# NOTE: Visited and did the correct google oauth2 allow steps, and receive in web browser: "Something went wrong"
\# AND, receive the following in the commandline where oama running:
secret-tool: createProcess: posix_spawnp: does not exist (No such file or directory)
Digging into this more, looks like oama cannot find the secrets service and/or keyring.
Since Alpine does not have dbus running by default, which is needed for the "org.freedesktop.secrets.service" message and then a keyring software that respects that standard.
Anyway, I tried a little bit above on using dbus to get this working, and I'm still getting the same errors.
Is there just a simple keyring that saves to disk in a textfile? Why is all this secrets service needed?
My intended goal is to run offlineimap or isync + oama to get google mail oauth2 token and be able to refresh.
HELP!!!
On Mon, Jul 22, 2024 at 07:02:04PM GMT, githubbbie wrote:
Spent some good time to get oama building on alpine linux with minimal configuration and have worked thru all snags. Do not see many people running this publicly at least, here is my Dockerfile:
Actually, some people are using oama on alpine that's why I provide the pre-compiled completely static binary oama-0.14-Linux-x86_64-static.tgz which itself is built on alpine.
Not sure why you need a docker image for that.
# AND, receive the following in the commandline where oama running: secret-tool: createProcess: posix_spawnp: does not exist (No such file or directory) ```
If you configure KEYRING back-end then oama needs the secret-tool program installed. secret-tool executable usually is part of the libsecret package.
You might want to ask around on alpine linux forums, this is not really an oama problem.
If you configure KEYRING back-end then oama needs the secret-tool program installed. secret-tool executable usually is part of the libsecret package. You might want to ask around on alpine linux forums, this is not really an oama problem.
It's weird that it uses secret-tool instead of using the libsecret API, which would doubtlessly be faster than starting a new process. I did a quick web search and it seems that there is indeed a binding for Haskell.
It's weird that it uses secret-tool instead of using the libsecret API, which would doubtlessly be faster than starting a new process. I did a quick web search and it seems that there is indeed a binding for Haskell.
There is a discussion for this at https://github.com/pdobsan/oama/discussions/34
On Sat, Aug 17, 2024 at 09:48:04AM GMT, Liam Hupfer wrote:
It's weird that it uses secret-tool instead of using the libsecret API, which would doubtlessly be faster than starting a new process.
There is a discussion for this at https://github.com/pdobsan/oama/discussions/34
In addition to what I have earlier said in this discussion, speed is not really a concern for a program called maybe a few dozens of times per day consuming a fraction of a second by an invocation.
Considering the size of the dependency tree of the gi-secret Haskell library, robustness of maintenance and of runtime the current API (i.e. talking to a well defined external process over a pipe) seems to be good enough.
Using this method is just a design decision, and as such it is always a tradeoff, I would not call it "weird".
Having said that, it might change in the future.