-- Leo's gemini proxy
-- Connecting to gemini.hitchhiker-linux.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en-US
I'm sure a lot of the capsules here have started out as totally hand written and managed, while slowly adding more automation as time goes by. My own capsule falls into that category as well. Currently I've got it down to two commands (plus the actual writing).
zond post "Title of Post" init -ept tag1,tag2,tag3 -s "A summarry of the post" make
My capsule generator, Zond, has added a few small but useful enhancements over time. The -e flag tells it to open the newly created file in my editor, while the -p flag tells it to go ahead and mark the file as published after closing the editor (which just involves turning the "published" field on the metadata struct from None to Some(datetime)). I'm not saying it's for everyone, but it definitely suits the way that I work.
The second command just runs the default target of the Makefile sitting in my capsule's source directory, which does the following:
calls `zond build`
scp's all of the generated files to the server
publishes the atom feed to Antenna using `openssl s_client`
calls `git add .`, `git commit` and `git push` to check the source into my gitea instance and a mirror on Codeberg
For those with less git-fu (a lot of folks came of age after git became synonymous with GitHub so they don't know the command line) you can add as many push url's as possible. It's easy enough I find myself scratching my head when folks ask how to mirror a repository or migrate away from GitHub.
git remote set-url --push origin <first url> git remote set-url --push --add <second-url>
> Since the server ran under a different user, I had multiple commands to copy, change ownership, etc. which also required typing in my sudo password multiple times. I thus enabled passwordless sudo, which is a terrible idea and gave me a reason to find a better way.
That reminds me of the terrible advice I've often seen for php web applications, where the web server needs write permissions to some directory, but the user wants to be able to upload changes via ftp or whatnot. No? Before your time again? Well anyway, lots of folks always loved to recomment just doing a `chmod -R 777` on the directory.
If you ask me, that's a great argument for static sites. The server for this capsule runs as one user, with read only permissions on the directory where the files reside. My own user actually owns the files, so I can just scp them as myself.
It also reminds me of my earlier post about sudo. The fact that sudo is seen as a nag, and gives one the option of turning off the nagging by enabling passwordless sudo, does in itself seem like it's encouraging insecure configuration. At least to me it does. Just an aside though.
> And that's it! it's wonderful (I have to type my ssh key passphrase a few times - but that's w.e). I'll likely get this running on my writing PC too!
The ssh-agent is your friend. You can put the following in your shell startup file (.bashrc or .zshrc).
eval $(ssh-agent)
Note: this will only work for the current shell. If you're running X11, you can add to ~/.xprofile:
if [ -z ${SSH_AUTH_SOCK+x} ]
then eval $(ssh-agent)
fi
This checks if you have the SSH_AUTH_SOCK set, and if not then it starts up ssh-agent as part of the Xorg startup process and adds the socket path to the environment. Wayland is a bit trickier. I've settled on using gnome-keyring since I keep Gnome installed for testing some of the graphical programs I've written. So in my .zshrc I have the following:
# if running X then we start ssh_agent from .xprofile, but if we're on Gnome and
# Wayland we need to use the Gnome keyring ssh agent
if [ ${XDG_SESSION_DESKTOP} = "gnome" ] || [ ${DESKTOP_SESSION} = "sway" ] && [ ${XDG_SESSION_TYPE} = "wayland" ]
then export SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
fi
Then it's just a matter of making sure that gnome-keyring-daemon is running after login. For Sway, I simply include `exec gnome-keyring-daemon` to my ~/.config/sway/config` file.
Any way that you do it, assuming the ssh-agent is running and the socket path is in your environment correctly, then you can just type `ssh-add` to unlock the keys and they'll stay unlocked for the lifetime of your login. Don't want to leave your keys unlocked if you step away from your desk? Run `ssh-add -d` to remove keys.
All content for this site is licensed as CC BY-SA.
© 2023 by JeanG3nie
-- Response ended
-- Page fetched on Mon May 20 12:32:06 2024