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