I’m not familiar with DO but one approach to the secret zero thing that works elsewhere is the VPS gets assigned an OIDC identity by the provider (or the VPS has access to one if it asks). That identity is in turn used to sign in to Vault.

I’d appreciate one if you still have spare

Tyro | Platform Engineer | Full time | ONSITE Sydney, Australia (with WFH flexibility)

We're hiring for my area at Tyro (www.tyro.com) for the first time in a long time. Tyro delivers next generation cloud-based, integrated and mobile payments, deposits and lending banking solutions to Australia’s small and medium enterprises. We were the first technology company to become a banking institution in Australia and our environment is changing constantly as we grow.

We are organised as a foundational platform engineering function providing a secure and reliable self-servicable cloud platform for Tyro's 20+ product engineering teams to build and run their workloads on.

Our technical infrastructure is centred around SaaS like AWS, GitHub, Buildkite and OSS like Kubernetes, Istio, Vault, Prometheus, ArgoCD and Kafka. I'm interested in hearing from security-oriented platform engineers. Ping mbaillie@ the company domain.

I somehow find myself commenting on these threads the most on this site purely to bring up vterm. I think the combination of a well-polished Emacs (like DOOM), evil-mode for vi modal editing everywhere and critically vterm/emacs-libvterm make for a great workflow[1].

Sure there's all the regular Emacs value-adds (Org-mode, Magit, TRAMP etc.) and there's no rush to start learning them, but navigating local/remote codebases all the while treating Dired filesystem views, regular files AND terminal ptys as buffers with full modal editing I find to be something of a special power. This has been possible for a long time with eshell/shell etc. but vterm really takes the lag out of it IMO. This workflow was certainly my gateway drug to Emacs. It displaced nearly two decades of vim for editing and tmux for terminals. YMMV.

[1] I wrote a bit about the workflow and continuing to train better with vim bindings using Emacs https://martin.baillie.id/wrote/evil-motion-training-for-ema...

> This has been possible for a long time with eshell/shell etc. but vterm really takes the lag out of it IMO. This workflow was certainly my gateway drug to Emacs.

Wait... wait... vterm works with TRAMP? How?

If this lets you navigate remote filesystems as in eshell without the lag on each command that results in... I'm sold.

EDIT: Oh, I found https://github.com/jixiuf/vterm-toggle which seems to open a vterm pane and ssh into the remote host. Which is close enough, I suppose! (Though I would miss being able to just `cp` from a remote path to a local path as if they were both local.)

FWIW Neovim has shipped with libvterm as a built-in terminal emulator for years now, I think since 2015? It's the main reason I switched from vim to neovim. Vim itself integrated libvterm somewhat later, too.

Agreed! I've emigrated to Australia and have taken to shipping over butchers rusk to make my own Lorne (I'd call it slice) sausage.

Check out emacs-libvterm. I’ve replaced all terminal emulators with it. All the benefits of an Emacs buffer and no issues with curses or lag.

It's right there

> One of the earliest and most popular was github.com/jteeuwen/go-bindata and its forks

Can confirm—vterm is very stable now. I've ditched separate terminal applications and exclusively use Emacs+vterm.

Thanks

Is there a way to get fuzzy searchable history ala bash Ctrl+r?

Also I've noticed that if I use any emacs movement command (say jump to start of line) vterm looses internal sync and my edits edit the wrong text. Is that an issue specific to my config, or do you have it as well?

you should be able to leverage normal bash/zsh/&c. functionality.

the emacs movement issue I don't have, so perhaps that's a configuration issue.

(one perhaps useful tip: `vterm-copy-mode`, by default bound to C-c C-t, let's you navigate the buffer with normal emacs movement in order to copy)

> It opens you up to a literally undetectable attack.

This is the crux of it for me. This is why it is dangerous. The author appears to have overlooked this attack vector entirely.