You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I made two changes in the pre-deploy steps for cRPD version 23.1 and newer:
The license file is no longer expected in /config/license/safenet/junos_sfnt.lic, but rather in the parent directory. So it becomes just /config/license/junos_sfnt.lic.
It is no longer required to edit the /etc/sshd_config directly and restart SSHD. The startup config for enabling SSH server and allowing root login are honored when the control plane starts.
Implementing this is straightforward, but I am having trouble coming up with a way of keeping backwards compatibility by conditioning behavior on the version. The current cRPD version is available the container image in /etc/junos/release.txt as a string on a single line. But reading this file requires a running container, so not available yet in the pre-deploy stage. Starting a (separate) container just to read the file and grab the would work, but feels very hacky ... WDYT?
The text was updated successfully, but these errors were encountered:
Regarding the license, it seems it should be possible to use the cli command (#1350) to load one.
Maybe this is version-agnostic enough to work with pre 23 and post 23 versions?
I made two changes in the pre-deploy steps for cRPD version 23.1 and newer:
/config/license/safenet/junos_sfnt.lic
, but rather in the parent directory. So it becomes just/config/license/junos_sfnt.lic
./etc/sshd_config
directly and restart SSHD. The startup config for enabling SSH server and allowing root login are honored when the control plane starts.Implementing this is straightforward, but I am having trouble coming up with a way of keeping backwards compatibility by conditioning behavior on the version. The current cRPD version is available the container image in
/etc/junos/release.txt
as a string on a single line. But reading this file requires a running container, so not available yet in the pre-deploy stage. Starting a (separate) container just to read the file and grab the would work, but feels very hacky ... WDYT?The text was updated successfully, but these errors were encountered: