@SquirePug Can you share more details, which templates and parameters did you edit?

In T3896#107997, @Viacheslav wrote:

@SquirePug Can you share more details, which templates and parameters did you edit?

Hello,

I am the dev working on behalf of the @SquirePug. For our particular installation the template that was edited was located at

/usr/share/vyos/templates/ocserv/ocserv_config.tmpl

And the addition I made was the following two lines hardcoded into the template.

config-per-group = /etc/ocserv/config-per-group
default-group-config = /etc/ocserv/defaults/group.conf

I wasn't able to configure this directory via the cli using any of the

set vpn openconnect ...

commands so I browsed the source in order to see how it was generating the open connect configuration file and found the various config functions in vpn_openconnect.py and the template functions said file referenced which lead me to searching for the ocserv_config.tmpl file. This config allows us to pass groups in our RADIUS response to ocserv and forward routes on a per group level.

I am interested in contributing new commands listed below to optionally enable/disable group based configs and configure the directory for the per group configs, and the default group file:

set vpn openconnect config-per-group-mode <enabled|disabled> (default disabled)
set vpn openconnect config-per-group-directory <directory>
set vpn openconnect default-group-config <file>

If I could get some feedback as to whether this would be a welcome addition I can start working on a PR sometime soon, and I'll post an overview on how I plan to implement said commands.

Regards,
Jamie

For this we create text files as the group-config includes (they contain route and other per group config directives, generally around security).

Should we default the location of these files to somewhere in /config/ocserv/group-configs ?

Is there a preference on how to handle these additional end admin user created text files?

From memory, only files in /config persist after an update/upgrade?

I think that having the configuration stored exclusively in files outside the config file breaks portability as exporting system state through # show | commands won't produce an output sufficient for full state backup of a device.
If the configuration attributes were all in the CLI which then generated the relevant files in the FS, that would address the stateless backing filesystem concern by centralizing the device config as the source of truth.
@SquirePug - could you possibly provide a link to or the contents of the changes you made? Thanks