CM 3beta: compression/encryption - server-2-server - restrict client access

Openfire Openfire Dev
1

Hi,

I have more than one question about the connection manager so I feel sorry to behave bad and posting them all into one thread (;

a) Does the CM allows to work as a “proxy”? Does it support compression and encryption while the connection to Wildfire is unencrypted and not compressed? So one can take some load away from Wildfire into the CM?

b) While this is interesting for c-2-s it may also be interesting for outgoing and incoming s-2-s connections but the documentation I read so far seems to be c-2-s specific.

c) http://wildfire:9090/reg-settings.jsp allows to restrict logins based on the IP address. Do the CM’'s query this value or is it ignored?

display problem) As I did use pen as a TCP load balancer I did bind pen to the external IP address, Wildfire to 127.0.0.1, CM0 to 127.0.1.0 and CM1 to 127.0.1.1. The IP Address[/b] does display something completey different. It seems that this is the IP address of the CM which connects to Wildfire and not the one the clients connect to. It would be nice to see both.

Active Connection Managers for server: public-name.com

Name IP Address[/b] Client Sessions

1[/b] 127.0.0.1 / internal-server-name.com 0

0[/b] 127.0.0.1 / internal-server-name.com 0

feature request) manger.xml offers to enable SSL, it would be nice if one could do this using the web gui / http://wildfire:9090/connection-managers-settings.jsp instead of an editor. As the CM is connected to Wildfire this should be possible. Also managing the certificates could be possible using the central web console.

LG

2

Hey LG,

a) Does the CM allows to work as a “proxy”? Does it

support compression and encryption while the

connection to Wildfire is unencrypted and not

compressed? So one can take some load away from

Wildfire into the CM?

yes, connection to the server can be using compression and be encrypted while client connections may be unsecured and uncompressed or vice versa. In other words, there is no relation between CM-server and client-CM connections, both or any of them may be using compression and/or TLS.

b) While this is interesting for c-2-s it may also be

interesting for outgoing and incoming s-2-s

connections but the documentation I read so far seems

to be c-2-s specific.

agreed, a future version may add support for s2s and external components. For now the main focus is c2s connections since that is the main bottleneck for achieving great scalability.

c) http://wildfire:9090/reg-settings.jsp allows to

restrict logins based on the IP address. Do the CM’'s

query this value or is it ignored?

that is in the TODO list. there is an enhancement request that we will implement that will include again that feature.

feature request) manger.xml offers to enable SSL, it

would be nice if one could do this using the web gui

/

http://wildfire:9090/connection-managers-settings.jsp

instead of an editor. As the CM is connected to

Wildfire this should be possible. Also managing the

certificates could be possible using the central web

console.

All cool ideas. Future versions of CM will include easier administration and setup. Anyway, with just configuring 2 properties it is now possible to have a running CM.

Regards,

– Gato

3

Hi Gato,

now that I know that it is possible to configure the CM to enable / disable compression and encryption I wonder how to do this. Is there a manual available?

I did hope that you’'d say something to the display problem I did mention, seeing only the internal and not the internal and the external interfaces.

LG

4

Hey LG,

now that I know that it is possible to configure the

CM to enable / disable compression and encryption I

wonder how to do this. Is there a manual available?

These settings are controlled from the server and it will affect to all CMs that try to connect to the server. Currently there is no nice page in the admin console to configure these settings. You will need to set these system properties:

xmpp.multiplex.tls.policy = (required / optional / disabled)

xmpp.multiplex.compression.policy = (optional / disabled)

I did hope that you’'d say something to the display

problem I did mention, seeing only the internal and

not the internal and the external interfaces.

Oh, I missed that part of the inital post. As you noticed we are always showing the IP address of the CM instead of the real IP address of the user. Once we implement the pending enhancement to CM we will be able to show the real ip address since that information will be sent to the server while establishing the initial connection.

Regards,

– Gato

5

Hi Gato,

I’'m not interested in the real IP address of the user[/i] but in the external IP address of the CM. Listing all users IP addresses may be nice …

LG

6

I have a question about the Connection Manager stuff as well, I thought I might post it here just as well.

Where is the Connection Manager documentation? It says on the page that it’‘s being developed through the open JEP process, but I haven’‘t been able to find the discussion in the standards-jig list archives. Reason I’‘m asking is that LiveJournal has now rolled out its own XMPP server, and they have clustering pretty high in their priority list. I wanted to give them some hints about the Connection Manager stuff you’‘ve worked on, but I don’'t know where to point…

7

Hey Manuzhai,

Check out your mail box.

Regards,

– Gato

8

BTW, Brad from Live Journal was in our office a few weeks back and made some good suggestions about the CM JEP (which still need to be incorporated). So, they’'re definitely aware of the spec.

Thanks,

Matt

9

Oh, right! I remember him writing about some interop testing you guys had done. That’'s good, then.

I still wonder why the proto-JEP isn’‘t online anywhere… If it’‘s an open process, it should be, right? Even if it was just in some mailing list archives (I searched, but couldn’'t find it.)

10

The only reason the JEP isn’‘t out there yet is that we haven’'t done the work of putting it into actual JEP format yet. However, I attached a PDF that documents what we have so far.

Regards,

Matt
CM_JEP.pdf (67268 Bytes)

11

Hi Matt,

there’'s nothing about caching in your PDF, it may be interesting to know whether a CM is allowed to build up a cache of for example vcards, how to validate it and how the server may purge objects of a cache of a CM.

As we did learn the Wildfire database cache helps a lot to improve the performance so a CM cache should not hurt.

LG

12

LG,

I think caching would be out of scope for the JEP. It would certainly be possible to cache some things like vCard, but I’‘m not sure that would be a huge advantage. In general, I like the model of having very simple CM’'s.

Regards,

Matt

13

Hi Matt,

I agree that it should be possible to implement simple CM’'s without caching.

But it would be nice if a proxy or cache namespace or something like this within the connectionmanager namespace would be defined and one thinks now on how this could be realized. So one could write more complex CM’'s.

LG