Using IceGrid like an improved DNS

in Help Center
Hello, I want to use IceGrid for the location of the Ice servers instead of a dns because of the oppurtunity to specify the port and the protocol in the endpoint
and the load balancing.
But during the activation the server registers itself to the locator with an AdapterId, how can I secure this over internet an avoid that another server registers with the same AdapterId an overwrites my server?
Thanks.
and the load balancing.
But during the activation the server registers itself to the locator with an AdapterId, how can I secure this over internet an avoid that another server registers with the same AdapterId an overwrites my server?
Thanks.
0
Comments
It seems I should use the property:
IceSSL.TrustOnly.Server.IceGrid.Registry.Server
but I need a rule on the registry that states this:
"If a server with id AS137_1 is activating one of its adapters on the registry, it has to have CN=AS137 in the distinguished name"
The servers are not activated on-demand, but manually.
Do I need to insert property tags in the server tag of the xml description of the application?
I tryed with
<adapter name="Facade" endpoints="ssl -h xxxx -p 10001" replica-group="AS137Facade"/>
but the problem was still the same.
If you are mostly concerned about security then you would likely want to give all of your servers the same identity and then only allow that identity to connect to the relevant port (see my article for details).
If you are concerned about programming errors and want to prevent a buggy server from registering an incorrect adapter id then at present you cannot do this with IceGrid as it stands today. I'd suggest more testing
Otherwise I don't want the server activation at all and I want to set the server endpoints during the deployment (if possible).
It is possible to disable on-demand server activation & set the endpoints directly. However, how do you see this solving your problem?
How can I disable the need of server activation?
I've tried in this way, I've set in icegrid.config
IceGrid.Registry.Server.Endpoints=ssl -p 12001
Ice.Plugin.IceSSL=IceSSL:createIceSSL
IceSSL.VerifyPeer=1
IceSSL.DefaultDir=certs
IceSSL.CertAuthFile=cacert.pem
IceSSL.CertFile=Registry_cert.pem
IceSSL.KeyFile=Registry_key.pem
IceSSL.TrustOnly.Server.IceGrid.Registry.Server=CN=Registry
and I've deployed this application
<icegrid>
<application name="BGP2P">
<server-template id="AS137">
<parameter name="index"/>
<server id="AS137_${index}" exe="python" activation="manual">
<adapter name="Facade" endpoints="ssl -h tocai.dia.uniroma3.it -p 10001" replica-group="AS137Facade"/>
</server>
</server-template>
<replica-group id="AS137Facade">
<load-balancing type="round-robin"/>
<object identity="sFactory" type="::BGP2P::SessionM::BGP2PSessionFactory"/>
</replica-group>
<node name="localhost">
<server-instance template="AS137" index="1"/>
</node>
</application>
</icegrid>
I've commented:
#Facade.AdapterId=AS137_1.Facade
so the server doesn't try to activate the adapter to the registry
but when I try to locate [email protected] I get NoEndpointException
In fact if I see the status of the adapter AS137_1.Facade, it's Inactive
I fail to see how either static endpoints or manual server activation really help you. Static endpoints are not a very good idea as they are hard to administer. How does disabling on-demand server activation help you? Are you assuming that all servers startup on system startup and never crash? If this is the case its pretty risky and if the environment really is hostile is definitely not a good idea.
What are id are you trying to locate? You wrote: [email protected] Do you, however, really mean [email][email protected]_1.Faca[/email]de?
If the server is actually active and IceGrid shows otherwise this generally means you used the wrong adapter name when you created the OA.
It looks to me like you have a rather complex deployment with replica-groups, templates, variables and other things. If I were you I'd take the IceGrid simple demo and modify the code and deployment descriptor to do what you want as this eliminates many variables. However, before doing any of this you should address what I said above and ensure that what you are doing is going to solve your problem.
The server startup has not to be controlled by me, because they are on computers of other people and can be in different geographical places and if they crash they are responsible to respawn them. I want to use IceGrid only to locate them.
It's not an error, I meant the AS137Facade, the replica group of the Facade adapter.
No, If I uncomment the line
Facade.AdapterId=AS137_1.Facade
on the server
all works well, but I don't want server activation (if possible, how to do that?)
That's because I called this thread "Using IceGrid like an improved DNS", when you start a server you don't have to communicate to the DNS Server that you are started and if you ask it to resolve a name, it returns the ip even if the server is not active.
It's not possible to set the endpoints at deployment time. The endpoints you specify in the deployment descriptor are just used to generate the object adapter endpoints property in the server configuration file. The server will always register these endpoints on startup regardless of the activation mode.
To do what you want, IceGrid would need to allow static endpoint registration but as Matthew mentioned, such a setup could be difficult to administrate as you would have to assign the endpoint information at deployment time for each server. It seems to me that the best would be to have IceGrid check for the DN of the server before to accept the endpoint registration, we'll consider this for addition on our TODO list for IceGrid!
Btw, you could also consider implementing the Ice locator and locator registry yourself instead of using IceGrid (or you could also delegate the implementation to IceGrid and add all the security checks you need). See the Ice manual for more information on the locator interface.
Cheers,
Benoit.
now I'm going to change the architecture and use a simple DNS Server, for dynamic updates I'll use an Ice adapter that accepts update requests, verifies the certificate and, if allowed, makes a dynamic update to the dns server.