Users.aut modification

[mvargasp]

Hi,

We are currently working on a project based on your Professional Caster and have a question regarding the users.aut configuration file.

From our understanding reading the manual, adding N users does not require a restart of the caster since a rehash can be commanded; however, editing a username or removing an existing user are actions that require this restart.

Is it possible to not restart the Caster after a user has been removed for the change to take place? In case that the current version does not allow it, is this a functionality planned to be included in the future?

Thanks in advance!

[neumaier]

Replying to mvargasp:
Hi,
Adding, removing or changing a user or it's name does not require a restart of the caster software. A rehash command is always enough.
Best regards,
Peter

Hi,

We are currently working on a project based on your Professional Caster and have a question regarding the users.aut configuration file.

From our understanding reading the manual, adding N users does not require a restart of the caster since a rehash can be commanded; however, editing a username or removing an existing user are actions that require this restart.

Is it possible to not restart the Caster after a user has been removed for the change to take place? In case that the current version does not allow it, is this a functionality planned to be included in the future?

Thanks in advance!

[mvargasp]

Hi Peter,

Thanks a lot for the clarifications regarding user management.

We have a additional questions about mountpoint allocation. It is now our understanding that modifying this configuration with the rehash command is similar to the one explained for users.aut. The following use-cases come to mind and we would like to know when a rehash is enough and when a resync is needed:

1) If we add an additional mountpoint (with messages previously unallocated) and execute a rehash, service provision is not impacted and a new outgoing dataflow is created.
2) If we remove an existing mountpoint and execute a rehash, only users previously connected to this mountpoint are impacted, since the associated outgoing dataflow is removed.
3) If we remove messages allocated to an existing mountpoint and command a rehash, it is our understanding that the impact on users is that they will only see the remaining messages in the outgoing dataflow.
4) If we set messages previously allocated to mountpoint1 to mountpoint2 and command a rehash, the impact on users will be that now only those connected to mountpoint2 will be able to see these messages.

Thank you in advance!

[neumaier]

1) If we add an additional mountpoint (with messages previously unallocated) and execute a rehash, service provision is not impacted and a new outgoing dataflow is created.
=> Yes

2) If we remove an existing mountpoint and execute a rehash, only users previously connected to this mountpoint are impacted, since the associated outgoing dataflow is removed.
=> Yes and No. If you remove a mountpoint and you already stopped the dataflow, a rehash command will be enough to disable any new connection to this mountpoint. But if you remove a mountpoint while data are still flowing, the caster will likely continue to pull data. You should then either manually disconnect the source and listeners via menue "connections" (after a rehash command), or (if this doesn't work) restart the caster.

3) If we remove messages allocated to an existing mountpoint and command a rehash, it is our understanding that the impact on users is that they will only see the remaining messages in the outgoing dataflow.
=> I'm not sure to understand you, but in any case users will only see messages allocated to the mountpoint they are connected to.

4) If we set messages previously allocated to mountpoint1 to mountpoint2 and command a rehash, the impact on users will be that now only those connected to mountpoint2 will be able to see these messages.
=> Yes

[anonymous]

Hi,

Could you please add more details to Section 11 regarding which configuration parameters or types of configuration changes (additions, deletions, or modifications) require a rehash and which ones require a resync (e.g.. specific ntripcaster.conf parameters that cannot be changed with a reload)?
Thank you in advance for your support.

[neumaier]

Hi,
Thanks for the hint. I will update the manual.
In the meantime, you can proceed according to the following rule:
A resync is always necessary if an active change is to be stopped. This applies to the removal of access rights, the deletion of a relay in ntripcaster.conf or the removal of upload authorizations in sourcemounts.aut.
All changes that do not relate to an existing connection can be activated via a rehash.