Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Added ssh namespace #2240

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

libmonsoon-dev
Copy link

Tested on Linux. I would be grateful if someone could see if it works on Windows, I don’t have that option

Signed-off-by: Daniil Stepanenko <[email protected]>
@hairyhenderson
Copy link
Owner

Hi @libmonsoon-dev, sorry for the delay in reviewing.

For major features like this I prefer if you file an issue first so we can discuss the specifics before you spend time on it. See https://github.com/hairyhenderson/gomplate/blob/main/CONTRIBUTING.md for details.

It seems to me that you've added a new SSH sub-namespace inside the crypto namespace? Is there a reason for that? It's unusual and has no precedent.

From a quick scan at what you've added, it seems most of these should just be functions in the crypto namespace, since all they're doing is reformatting public keys into OpenSSH-compatible formats.

Can you explain in greater detail what you need to accomplish?

@libmonsoon-dev
Copy link
Author

Hello. Everything is fine, there is no rush. I solved my problem by compiling a binary from my own fork with this functionality.

For major features like this I prefer if you file an issue first so we can discuss the specifics before you spend time on it. See https://github.com/hairyhenderson/gomplate/blob/main/CONTRIBUTING.md for details.

Okay, next time I'll create an issue first. But is it necessary to create one in this case, or can we discuss these changes right here?

It seems to me that you've added a new SSH sub-namespace inside the crypto namespace? Is there a reason for that? It's unusual and has no precedent.

Yes, that's right. I wanted to recreate the structure similar to the packages in the standard library (and in golang.org/x/...). There ssh is separated into a subpackage, and in my opinion that makes sense.
This ties in with the universal programming advice I often hear, that namespaces are good in themselves and recomended to have more of them when it makes sense.
But for me this is not a fundamental point, if you think that this complicates the use of the tool - I can remake it to a flat structure or even transfer it all to crypto

From a quick scan at what you've added, it seems most of these should just be functions in the crypto namespace, since all they're doing is reformatting public keys into OpenSSH-compatible formats.

Not exactly. I initially read keys in OpenSSH format from the directory where OpenSSH stores them.

Can you explain in greater detail what you need to accomplish?

The initial problem that I solved with this functionality is the creation of a universal config for cloud init, each cloud has its own specifics, for example, for the current one that I use, you need to run a special script that will install and run the Zabbix agent so that the metrics are displayed in the web interface. But I digress. I would like the template not to contain a specific key, but instead, when generating the config from the template, the current key of the user who started the generation will be used

@hairyhenderson
Copy link
Owner

Okay, next time I'll create an issue first. But is it necessary to create one in this case, or can we discuss these changes right here?

We can discuss here - just keep in mind that I may require significant changes for this to be merged if it's merged at all (no guarantees).

Yes, that's right. I wanted to recreate the structure similar to the packages in the standard library (and in golang.org/x/...). There ssh is separated into a subpackage, and in my opinion that makes sense.

gomplate's function namespaces are not really intended to mirror the stdlib. There's only a single level of namespaces currently, and I'm not convinced there's a compelling reason to support additional layers.

I would like the template not to contain a specific key, but instead, when generating the config from the template, the current key of the user who started the generation will be used

The goal is still a bit unclear to me, but it seems to me that you probably don't need to parse the public key at all, but rather to simply include it?

Wouldn't something like gomplate -d mykey=$HOME/.ssh/id_rsa.pub -I '{{ include "mykey" | base64.Encode }}' work for this use-case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants