Add PASSWORD contextualization string from user input

Community Support
#1

I have a template with a user input:

USER_INPUTS=[
  PASSWORD="M|text|Enter desired login password:| |" ]

When a user instantiates the VM and types in a good password, this line gets added to context.sh or one_env:

export PASSWORD="$PASSWORD"

Instead of ‘abc123’ the password gets set to “dollar sign - pee - ay - ess - ess…”. Obviously not what I want. I know I should use PASSWORD_BASE64 but the Windows contextualization script doesn’t understand this. It wants PASSWORD="abc123" in the context.sh file. How do I make it do this? Why does ONE add PASSWORD="$PASSWORD" - where does it get that from?

#2

Hi christaylor,

I’ve the same issue, have you find a solution for this issue ?

KInd regards

#3

Hi,

Did you add it to CONTEXT? Could you share the output of onevm show -x <vm_id> for the VM?

Cheers?

#4

On an Alpine Linux template I was able to get it to work using this:

TEMPLATE CONTENTS
CONTEXT=[
DNS_HOSTNAME=“YES”,
NETWORK=“YES”,
PASSWORD_BASE64="$PASSWORD_BASE64",
USERNAME="$UNAME" ]
CPU=“1”
DISK=[
IMAGE_ID=“99” ]
GRAPHICS=[
LISTEN=“0.0.0.0”,
TYPE=“VNC” ]
INFO=“Please do not use this VM Template for vCenter VMs. Refer to the documentation https://bit.ly/37NcJ0Y”
INPUTS_ORDER=“PASSWORD_BASE64”
LOGO=“images/logos/alpine.png”
LXD_SECURITY_PRIVILEGED=“true”
MEMORY=“128”
MEMORY_UNIT_COST=“MB”
NIC_DEFAULT=[
MODEL=“virtio” ]
OS=[
ARCH=“x86_64”,
BOOT="" ]
SCHED_DS_REQUIREMENTS="ID=“0"”
USER_INPUTS=[
PASSWORD_BASE64=“M|text64|Enter desired login password:| |” ]

#5

thank Christaylor,

I’ve test this solution and it’s works. But i can decode all of the password that my users are using when is deploy virtual machine.
Do you have a solution to secure the password and that no one can see the password on sunstone or in cli ?
i find juste one solution, it’s to delete the attribute PASSWORD_BASE64 after the deployment.

Kind regard

#6

Hmm, I’m not sure what the best way would be to keep people from looking at the password once they’ve logged into the VM. Perhaps, your solution of simply deleting the attribute.

I haven’t tried it, but maybe getting authentication and the password from LDAP, kerberos or some other mechanism?

I’d be interested in hearing other’s solution to this question.