npm

Inspired by Micah P. Dombrowski's Node.js Environment.

• ceramicstudio/cli/idx-cli requires keytar from npm which requires libsecret.

apt update

sudo apt-get install libsecret-1-dev pass gnupg2 dbus default-dbus-session-bus dbus-x11 pass gnupg2 gnome-keyring

FILENAME="node-v${NODEJS_VERSION}-linux-x64.tar.xz"

FILEURL="https://nodejs.org/dist/v${NODEJS_VERSION}/${FILENAME}"

curl -O https://nodejs.org/dist/v${NODEJS_VERSION}/SHASUMS256.txt

wget --progress=dot:giga ${FILEURL}

grep $FILENAME SHASUMS256.txt | sha256sum -c -

cp $FILENAME /results/

mkdir -p /opt/nodejs

cd /opt/nodejs

tar -Jxf 
node-v14.16.0-linux-x64.tar.xz

ln -s node-v${NODEJS_VERSION}-linux-x64/ default

/opt/nodejs/default/bin/node --version

https://stackoverflow.com/questions/51811564/sh-1-node-permission-denied#53270214

npm config set user 0 &&

npm config set unsafe-perm true

npm install -g @ceramicnetwork/cli @ceramicstudio/idx-cli

Start a Server

ngrok

region: us

console_ui: true

tunnels:

  btf:

    proto: http

    addr: 7007

    subdomain: btf

echo 'authtoken:' $ngrok | cat - ngrok.yml > /tmp/out && mv /tmp/out ngrok.yml

Start ngrok.

nohup /ngrok start --all --config="/ngrok.yml" &> /tmp/ngrok.log & sleep 1

tail /tmp/ngrok.log

Ceramic

nohup ceramic daemon &> /tmp/ceramic.log & sleep 1

tail /tmp/ceramic.log

    dbus-launch --sh-syntax

dbus-launch

✖ Cannot autolaunch D-Bus without X11 $DISPLAY

D-BUS is an IPC (inter-process communication) mechanism that helps applications communicate with each other. D-Bus  (Desktop  Bus)

So libsecret won't work without an X11 host.

Did you ever figure out the issue with DBus? It's starting to come up more often. It's also a problem when running idx in a container.

As far as I can tell, IDX isn't going to work in a container or a windows linux subsystem because of libsecret. Libsecret wants to launch X11 when idx bootstrap happens. Has anyone found a workaround?

paul: The CLI is meant for development environments to get started quickly, it's not designed with CI or similar environments in mind. If you need to push the IDX config docs to a Ceramic node, using https://developers.idx.xyz/reference/idx-tools/#publishidxconfig is likely a better option.

Huh. That's pretty cool! So I could spin up ceramic in a container. Then from a more traditional local environment, I could run idx and push the example config docs over to the instance. Am I understanding that correctly, @Paul 3⃣ ?

That would work, in concept.

Then I could play around in this configuration, which is really ideal right now.

Once the config is pushed, i could also run IDX commands within the container as well.

If I'm understanding it correctly.

paul: It really depends on your use case, as long as you can provide a Ceramic instance to IDX it doesn't matter if it's running from the demon, docker or a remote server.

idx bootstrap

cat /tmp/ceramic.log

nohup dbus-daemon --session --nopidfile --nofork --address=unix:path=/tmp/dbus &> /tmp/ceramic.log & sleep 1

tail /tmp/ceramic.log

export DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus

export $(dbus-launch)

dbus-launch

env -u DISPLAY dbus-launch --sh-syntax

gnome-keyring-daemon --start --daemonize --components=secrets

# service dbus start

eval "$(dbus-launch --sh-syntax)"

https://github.com/ceramicstudio/idx-cli/issues/1

https://github.com/jaraco/keyring/issues/477

https://unix.stackexchange.com/questions/473528/how-do-you-enable-the-secret-tool-command-backed-by-gnome-keyring-libsecret-an

https://blog.ceramic.network/how-to-build-a-simple-notes-app-with-idx/

dbus-run-session -- sh

echo 'somecredstorepass' | gnome-keyring-daemon --unlock

IDX

idx index:get did:key:z6Mkw1Mpfejq2R76AsQo2qJoAVaF6HH5nLDoHrKrsW5Wdnei basicProfile

idx --help