> Hi All,
Please find below some thoughts about the internal user for a TLS Peer
and peeridentities.xml replication
> - I've looked at the existing SpecialUser and I found no mean to reuse
it as an internal TLS Peer user support (SpecialUser is more service >
related, meaning that a service is associated with (only) one special
user). Therefore I was thinking to use regular users and to add a new >
discriminator column to differentiate between admin configured users and
internal users (the query used in user table model will be modified not
to > include internal user instances).
+1. I happen to have thought through this while working on XX-7452. I
was thinking about the exact same approach. The SpecialUser, even the
name appears to be more applicable to this case, but from implementation
point of view, it does not. As the existing SpecialUser's permissions
are pre-determined and no configuration is needed, while in the TLS Peer
case, admin need to be able to configure the permissions for the user,
and permissions can be easily associated with user via user settings.
Using regular users and add a new discriminator makes sense. In this
way, while they share the same database table, but when query/display
users or peers, it can be easily distinguished.
> - I guess we don't have to bother about the internal user SIP password
and PIN token (they can be randomly generated or leaved empty)
+1.
> - per my understanding - peeridentities.xml will be declared as
<osconfig> resource in sipxbridge-process.xml.in and
sipXproxy-process.xml.in and > it will not require service restart after
replication. I think there is some additional work required on Operation
side to handle this new > > resource and also to pick up changes on the
fly?
Ever considering using IMDB option? Besides IMDB, I know that on the
Operation side, there is a mechanism that be used several places that a
background process monitors the timestamp of the configuration files, if
the file is ever changed, the process will re-parse the configurations
and pick up the changes on the fly, which does not require service
restart.
Huijun
_______________________________________________
sipx-dev mailing list [email protected] List Archive:
http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
