> I had talked to Andres about doing exactly what you are mentioned with
> regards to using InstallSharedSecretScript.run but he said he didn't
> want us to go that route as user interaction for entering the shared
> key doesn't allow automation for using this command. I will run it by
> him and see if he still believes this to be the best route to take on
> this. Thanks for the review.
Fair enough, but both install-shared-secret and this new command are
trivial to automate:
echo shared-secret | maas-rack register
echo is a builtin in both sh and bash so this avoids revealing the
secret in /proc/*/cmdline.
This isn't just me being paranoid, it's a common practice. PostgreSQL's
psql command, for example, takes a --password flag but it consumes no
arguments; its effect is to force the prompt for a password. It allows
the use of an environment variable, PGPASSWORD, but recommends against
it for security [1].
> I had talked to Andres about doing exactly what you are mentioned with cretScript. run but he said he didn't
> regards to using InstallSharedSe
> want us to go that route as user interaction for entering the shared
> key doesn't allow automation for using this command. I will run it by
> him and see if he still believes this to be the best route to take on
> this. Thanks for the review.
Fair enough, but both install- shared- secret and this new command are
trivial to automate:
echo shared-secret | maas-rack register
echo is a builtin in both sh and bash so this avoids revealing the
secret in /proc/*/cmdline.
This isn't just me being paranoid, it's a common practice. PostgreSQL's
psql command, for example, takes a --password flag but it consumes no
arguments; its effect is to force the prompt for a password. It allows
the use of an environment variable, PGPASSWORD, but recommends against
it for security [1].
[1] http:// www.postgresql. org/docs/ current/ static/ libpq-envars. html