This article's title is misleading, its rather solving issue with ssh key management under WSL.
ssh-agent management has been a non-issue on Linux.
- ssh-agent supports setting up custom socket path while starting up
-a bind_address
Bind the agent to the unix-domain socket bind_address. The default is /tmp/ssh-XXXXXXXXXX/agent.<ppid>.
- use SSH_AUTH_SOCK env var to instruct about the ssh-agent's socket path to programs that depend on it viz ssh and git.
- an option is available in ssh config (since 7.2) which lets you load the key when it is required (basically when you run ssh or git clone) or reload it when the ttl expires
AddKeysToAgent
Specifies whether keys should be automatically added to a running ssh-agent(1). If this option is set to yes and a key is loaded from a file, the key and its passphrase are added to the agent with the default lifetime, as if by ssh-add(1).
So start the ssh-agent with either xinitrc or systemd user units or even a simple shell conditional in bashrc/zshrc to check and start agent if its not already running. Now set SSH_AUTH_SOCK env var to the socket path set while running the agent.
Hey,
thank you for the insight! Setting SSH_AUTH_SOCK to a fixed path and binding it with -a indeed solves some of the problems. I will add this to the blog post. But then you have still the problem that you have to enter your password during startup for every key, right (even though you dont need it)? The advantage I see with gpg-agent, is that it only asks for a password, the first time the key is needed. Also it solves two problems (gpg and ssh keys) at once. And well, you still have to check if it is not already running.
I am not sure this would only apply to WSL though, I use the same approach on my Linux machine.
> If I recall correctly, CentOS and RHEL will use the device-mapper driver by default and CoreOS the btrfs
CentOS & RHEL uses device-mapper with loopback device by default (and logs "Usage of loopback devices is strongly discouraged for production use. Either use --storage-opt dm.thinpooldev or use --storage-opt dm.no_warn_on_loop_devices=true to suppress this warning". Also related article [1]
CoreOS uses overlayfs by default now from a while [2]
The main advantage against shipyard is that you only need to deploy one container to run Portainer, it's really simple and quick. Shipyard deployment is more complex.
Have you ever thought about adding support for kvm/QEMU/virsh-based virtual machines as well?
I've been looking for a easy to use interface that gives a comprehensive overview of virtual machines as well as containers as I'm often using a mix of both.
Cockpit [1] too, although that might be a bit more focused on single machine management than on clusters (don't use any of those - so I can't tell for sure)
It's Peter-Paul Koch. He's well known for providing painstakingly detailed tests and compatibility tables on browser capabilities and web standards support, particularly js.
I'm not sure what stats are like for users of the specific devices he's looking at here, but India's a big market: I'm guessing browser compatibility here is going to be of some interest to more than one or two folks.
I think the problem is that out of the context of the blog, the title makes it sound like it's going to be more interesting to the average reader than it actually is.
If you're reading his blog anyway, you'll probably be aware that much of it is about compatibility questions in browsers and wouldn't be surprised that an article on Indian phones is likely to be related to that.
Just seeing the headline in isolation, I was (and I suspect you were) expecting much more "weirdness" - odd shapes, strange keyboard choices, obscure OS options etc.
That's not a fault of the blog, just a result of seeing a headline outside its context.
You should try doing two seconds of research before making stupid statements like that. The work that Peter-Paul Koch does is actually very valuable for many web developers, and people care about his perspective. But I guess if you're lazy, you can just call it bizarre random blog crap.