Brad: My point was not about the IP of the machine on which the VenueServer runs, but instead about the multicast addresses assigned to the Venues configured on the VenueServer.
Tom On 5/21/08 10:25 AM, Brad Viviano wrote: > Tom, > Both the new bridge and venue server use staticly assigned IP's on > the same VLAN as the old bridge/venue server. The problem is a 2.4 > client doesn't show the option when connected to the 2.4 venue server > for Unicast (grayed out). Its like the Venue server isn't aware there > is a Unicast Bridge, but the Bride has registered itself to the Venue > and got a list of Venues to provide Unicast for. I even tried having > it register to a specific Venue (default one), the Bridge shows it > registered, but the clients still do not see a Unicast bridge in that > Venue. > > -Brad > > Thomas D. Uram wrote: >> Hi Brad: >> >> Does the new VenueServer use statically-assigned addresses? If it >> did, then the BridgeServer would grab these and start QuickBridge >> instances for them immediately. If not, which I suspect may be your >> case, then addresses will be allocated as needed, and the >> BridgeServer will only then start QuickBridge instances for them. >> >> Static addressing is an option in VenueManagement, when configuring a >> Venue. >> >> Tom >> >> >> On 5/21/08 9:10 AM, Brad Viviano wrote: >>> Hello, >>> I apologize if this has been addressed else where. I searched >>> the archive and didn't find the answer. My group is in the process >>> of upgrading to 3.1 from 2.4. For various political reasons I've >>> been asked to keep a 2.4 server running for the near future. I've >>> had a 2.3/2.4 Venue/Bridge server operational under RHEL3 for over 3 >>> years now and am quite comfortable with setting up and maintaining >>> 2.X AG. >>> We've acquired new hardware for the 3.1 Venue/Bridge setup >>> running RHEL5 and I wanted to run both the 2.X and 3.X servers on >>> the same box to make my administrative life easier. Using the docs >>> from: >>> >>> http://www.vislab.uq.edu.au/research/accessgrid/software/rhel/ >>> >>> I installed all the AG3.1 RPM's (and pre-requirements) as well as >>> the 2.4 compatibility set. I have the new 2.4 Venue Server up and >>> operational and working fine from 2.X clients, but I can not get the >>> bridge server to connect to the new Venue Server correctly. >>> >>> Logs on the new bridge server when it connects to the new venue >>> server show: >>> >>> 05/21/08 09:43:33 46912496258912 Toolkit Toolkit.py:709 INFO >>> Service init: have profile None >>> 05/21/08 09:43:33 46912496258912 Toolkit Config.py:214 DEBUG >>> System hostname of bridge3.renci.org is valid >>> 05/21/08 09:43:33 46912496258912 CertificateManager >>> CertificateManager.py:269 DEBUG Opened repository >>> /opt/ag/.AccessGrid/Config/certRepo >>> 05/21/08 09:43:33 46912496258912 Toolkit Toolkit.py:738 INFO >>> Initialized cert mgmt. >>> 05/21/08 09:43:33 46912496258912 Toolkit Toolkit.py:753 INFO >>> Loaded profile and configured with it. >>> 05/21/08 09:43:33 46912496258912 CertificateManager >>> CertificateManager.py:759 DEBUG Configuring standard environment >>> 05/21/08 09:43:33 46912496258912 CertificateManager >>> CertificateManager.py:827 DEBUG Using default identity /O=Access >>> Grid/OU=agdev-ca.mcs.anl.gov/CN=VenueServer/venues.renci.org >>> 05/21/08 09:43:33 46912496258912 CertificateManager >>> CertificateManager.py:1083 DEBUG Initializing environment with >>> unencrypted cert /O=Access >>> Grid/OU=agdev-ca.mcs.anl.gov/CN=VenueServer/venues.renci.org >>> 05/21/08 09:43:33 46912496258912 CertificateManager >>> CertificateManager.py:1572 DEBUG done, success=1 >>> 05/21/08 09:43:33 46912496258912 Toolkit Toolkit.py:764 INFO >>> Initialized Globus. >>> 05/21/08 09:43:33 46912496258912 Toolkit Toolkit.py:782 INFO >>> Service Initialization Complete. >>> 05/21/08 09:43:33 46912496258912 Toolkit BridgeServer24:157 INFO >>> BridgeFactory.SetPortMin 30000 >>> 05/21/08 09:43:33 46912496258912 Toolkit BridgeServer24:161 INFO >>> BridgeFactory.SetPortMax 30999 >>> 05/21/08 09:43:33 46912496258912 Toolkit BridgeServer24:259 INFO >>> AddVenueServer: url = https://venues.renci.org:9000/VenueServer >>> 05/21/08 09:43:33 46912496258912 Toolkit BridgeServer24:274 INFO >>> AddVenue: url = >>> https://venues3.renci.org:9000/Venues/00000102403861290098001300a80081d1e >>> >>> 05/21/08 09:43:34 46912496258912 EventClient EventClient.py:158 >>> DEBUG Have callback handle _303002b4aa2a0000_p_callbackStruct >>> 05/21/08 09:43:34 1115699520 Toolkit BridgeServer24:612 INFO >>> Method Venue.RunQueueThread called >>> 05/21/08 09:43:34 46912496258912 Toolkit BridgeServer24:274 INFO >>> AddVenue: url = >>> https://venues3.renci.org:9000/Venues/00000102403832e40098001300a8008150a >>> >>> 05/21/08 09:43:35 46912496258912 EventClient EventClient.py:158 >>> DEBUG Have callback handle _30c5be1900000000_p_callbackStruct >>> 05/21/08 09:43:35 1147169088 Toolkit BridgeServer24:612 INFO >>> Method Venue.RunQueueThread called >>> 05/21/08 09:43:35 46912496258912 Toolkit BridgeServer24:274 INFO >>> AddVenue: url = >>> https://venues3.renci.org:9000/Venues/000001024035bd6c0098001300a80081bfc >>> >>> 05/21/08 09:43:36 46912496258912 EventClient EventClient.py:158 >>> DEBUG Have callback handle _d0c2c21900000000_p_callbackStruct >>> 05/21/08 09:43:36 1178638656 Toolkit BridgeServer24:612 INFO >>> Method Venue.RunQueueThread called >>> 05/21/08 09:43:36 46912496258912 Toolkit BridgeServer24:274 INFO >>> AddVenue: url = >>> https://venues3.renci.org:9000/Venues/000001024037fb040098001300a80081610 >>> >>> 05/21/08 09:43:37 46912496258912 EventClient EventClient.py:158 >>> DEBUG Have callback handle _50c101b4aa2a0000_p_callbackStruct >>> 05/21/08 09:43:37 1210108224 Toolkit BridgeServer24:612 INFO >>> Method Venue.RunQueueThread called >>> 05/21/08 09:43:37 46912496258912 Toolkit BridgeServer24:274 INFO >>> AddVenue: url = >>> https://venues3.renci.org:9000/Venues/000001024a6692130098001300a80081582 >>> >>> 05/21/08 09:43:38 46912496258912 EventClient EventClient.py:158 >>> DEBUG Have callback handle _20b800b4aa2a0000_p_callbackStruct >>> 05/21/08 09:43:38 1241577792 Toolkit BridgeServer24:612 INFO >>> Method Venue.RunQueueThread called >>> >>> The configuration file for the Bridge Server is: >>> >>> [BridgeServer] >>> name = RENCI3 >>> location = EUROPA >>> qbexec = /usr/bin/QuickBridge >>> portMin = 30000 >>> portMax = 30999 >>> >>> [https://venues3.renci.org:9000/VenueServer] >>> type = VenueServer >>> >>> Everything looks correct, the bridge connects to the server, >>> gets all the Venues, but QuickBridge never starts up. If I point >>> this same bridge server at my old 2.4 server (under RHEL3), it >>> establishes a connection, and will serve Unicast just fine, so I >>> don't think its the bridge server. I already dropped the firewall >>> on both the Venue and Bridge server just to be sure it wasn't a port >>> issue. >>> I have 2 things I think it could be: >>> >>> 1) conflict with certificate name. I am using the certificate from >>> my old server (venues.renci.org) on this test server >>> (venues3.renci.org). Thinking it might be a naming conflict, I >>> renamed the new server "venues.renci.org" and that didn't solve the >>> problem, and I see no complaints in the logs about certificate issues. >>> >>> 2) The newer wxPython (2.8.7.1) and associated pre-requirements for >>> AG 3.1 (downloaded from EPEL) are too new to correctly work with the >>> AG 2.4 setup. I ran into a couple of issues trying to start the 2.4 >>> Client, problems with wxPython compatability, but nothing on the >>> server side, and everything else on the 2.4 Venue Server is working >>> fine as far as Multicast (I can connect from a 2.4 clients and have >>> sessions just fine), its just the Unicast bridge won't connect and >>> start the QuickBridge for any of the Venues. >>> >>> Before I spend the time to rebuild the software stack myself >>> using older code on RHEL5 (wxPython 2.5.x, etc), I thought I would >>> ask if anyone has experienced this before, and knows of a quick >>> solution or can offer a direction for me to look in. >>> >>> Thanks, >>> -Brad Viviano >>> >>> >>> >
