When creating a user with an encrypted password with a startup-config, Truncation occurs
Steps to reproduce:
Created a topology that included some Junos vSwitch images -> Added a block config in the topology file -> the resultant encrypted password (if if contained . or / characters) would truncate.
startup-config: |
system {
login {
user someuser {
class super-user;
authentication {
encrypted-password "$6$8gNjhXy6$Vj69F.QdM.Nvz1fDDYhnwb27cMSXJmXxS23ti50z/liD3obqPRYs5UKHVbKFRtqZO.AoXJIVR6Um17RFfSwWm1"
}
}
}
}
What winds up happening is the encrypted password appears as ".QdM.Nvz1fDDYhnwb27cMSXJmXxS23ti50z/liD3obqPRYs5UKHVbKFRtqZO.AoXJIVR6Um17RFfSwWm1"
ContainerLab Version 0.56.0
Hi @lostdave containerlab/vrnetlab do not modify the contents of the provided startup config.
The way it works with junos is an disk with the startup-config is mounted to the VM, and junos should read the config from it
https://github.com/hellt/vrnetlab/blob/master/vjunosswitch/docker/make-config.sh
I suppose you should check the contents of that disk to verify that the encrypted string is there as it was in the yaml file
buuuut, I think what could have happened is that containerlab tried to expand variables :D $6, etc
Would you mind to try using the startup-config with a file, and not as embedded multiline string to confirm this theory?
Sorry ....slow to get back to this one..travel and training stuff.... i will have a look in the next couple of weeks and see what is going on
Yes, the issue stems from the fact that the https://github.com/a8m/envsubst package that we use to replace env vards in the topology file replaces the env vars that are not set or empty.
This leads to $foo to be replaced with "" if the $foo is not even set.
Unfortunately, the original package maintainer stopped maintaining the package and this particular feature request left dangling - https://github.com/a8m/envsubst/issues/56
I made a fork of a fork by @dnitsch that added some parts of this functionality, but it doesn't work when the env var is set with the default in the template. To demonstrate this use case I added a test case that currently fails:
https://github.com/hellt/envsubst/blob/50934c197f4028463435a6aa0e8556ca60b442e5/parse/parse_test.go#L179
Looking for brave contributors to see if they can crack it
I took a look @hellt. In the test you need to set the NoReplace flag to false and the test succeeds.
Not sure if I understand the flag correctly, but you want to replace the variable, correct... so NoReplace should be set to false I assume.
@steiler we can't set the NoReplace to false, because the goal of setting the NoReplace to true is to keep the env vars that are not set in the text body.
I just updated the test case with an additional input that shows demonstrates the effect of this.
check hellt/envsubst/pull/1
thanks @steiler
Now it should be fixed in the next release @lostdave