October 2007 - Ag-tech - mailman3.cels.anl.gov

text chat not working on argonne lobby
by Lassi Ylikojola 30 Oct '07

30 Oct '07

Hi ! Can not get or input any data on text chat right now on Argonne national lobby nor Argonne lobby using 3.02 or 3.1 beta2 client. Lassi

1 0

Re: [AG-TECH] Problems with Access Grid 3.0.2
by Christoph Willing 30 Oct '07

30 Oct '07

On 31/10/2007, at 2:59 AM, Nico wrote: > Hi Chris! > > Sorry, I was quite busy and I couldn't answer, but at the end I > tried the other solution you gave me: > ---------------------------------------------------------------------- > ---------------------- > change the line in /etc/rc.d/init.d/functions: > $nice runuser -s /bin/bash - $user -c "$corelimit >/dev/null > 2>&1 ; $*" > to: > $nice runuser -s /bin/bash $user -c "$corelimit >/dev/null > 2>&1 ; $*" > > Then change your init.d script line: > daemonAG --user ag VenueServer -c /home/ag/venue_server3/ > VenueServer.cfg -p 9000 > to: > cd /home/ag/venue_server3 && daemonAG --user ag VenueServer -c / > home/ag/venue_server3/VenueServer.cfg -p 9000 > ---------------------------------------------------------------------- > ------------------------------- > > Doing this I obtain the same problems than before, nothing change > after rebooting. VenueServer3 and 24 run at the startup but doesn't > work when you connect a client. In fact, I've just realized that > when I rebooted VenueServer.dat content for AG24 changed for > content of AG3 but is not the same content of /home/ag/ > venue_server3/VenueServer.dat. > > So that you can see better: > > /home/ag/VenueServer.dat before rebooting: > > # AGTk 2.4 [snip] > > /home/ag/VenueServer.dat after rebooting: > > # AGTk 3.0.2 [snip] > It seems after rebooting, new information is added related to a AG3 > Venue (pay attention to the header). Uncomprenhensible. Nico, From the above, its clear that the AG3 server is still running in the same directory as the AG2 server. In that case it looks like it will be best to bypass the "convenience" functions altogether and use something like (for AG3 server): cd /home/ag/venue_server3 && su ag -c /usr/bin/VenueServer & and for AG2 server: cd /home/ag && su ag /usr/bin/VenueServer24 & You will need to include a different -p portnumber option for each server and also ensure that any port numbers specified in each server's VenueServer.cfg is different from the other's. Another solution altogether could be to run each server as a different user - perhaps user 'ag' for the AG2 server (as before) and user 'ag3' for the AG3 server. Then all configuration files would be in the separate home directories of ag and ag3. You'd still have to ensure that all the port numbers being used are different chris > Respect to AG3, the same problem, since a client I can't enter any > venue. > > I keep trying things, but there is no improvement and running the > services manually seems to be the only valid solution. > > Any help would be appreciated. Thank you very much! > > > Nico. > > > Christoph Willing escribiï¿½: >> >> On 23/10/2007, at 1:37 AM, Nico wrote: >> >>> Hi Chris again! >>> >>> Well, I don't where to start but I'll try to explain all my >>> problems as well as I can because I have some difficulties with >>> English. >>> >>> I didn't try all the solutions you gave me in the last email, but >>> I tried the last solution changing the address in >>> "persistenceFilename" entry as this: >>> >>> persistenceFilename = /home/ag/venue_server3/VenueServer.dat >>> (The same for the Data folder) >>> >>> Then, I rebooted the machine and it didn't work, in fact I think >>> I obtained some errors, but I'm not sure. So I correct >>> VenueServer.cfg again. >> >> >> Nico, >> >> I've now tried this method myself and found that it does not work >> correctly yet. The server will use the different data store and >> persistenceFilename if they are specified in the cfg file, however >> the data written to the .dat file is incorrect - a bug for fixing >> sometime. >> >> >> >>> After that I started to have problems with Access Grid 2.4 too (I >>> have another script on the startup for VenueServer24). At any >>> way, is not the first problem I have with AG2.4. The problem I >>> have is that VenueServer.dat (for AG2.4) become corrupt file and >>> VenueServer24 runs but with problems, when I execute it I have >>> this messages: >> [snip] >>> File "/usr/lib/python2.4/ConfigParser.py", line 520, in get >>> raise NoOptionError(option, section) >>> ConfigParser.NoOptionError: No option 'cleanuptime' in section: >>> 'c190248c0648459db8c5401e80b4f0a0' >> >> This means that the VenueServer.dat file being used now by your >> AG2 server was sometime also used by the AG3 server, at which time >> a new venue was created. The new venue did not include a >> 'cleanuptime' feature (because it is not used by AG3) but it is >> expected to to be there by the AG2 server which then complains >> when the feature is not found. >> >> >>> Traceback (most recent call last): >>> File "/usr/lib/python2.4/logging/handlers.py", line 62, in emit >>> if self.shouldRollover(record): >>> File "/usr/lib/python2.4/logging/handlers.py", line 132, in >>> shouldRollover >>> self.stream.seek(0, 2) #due to non-posix-compliant Windows >>> feature >>> ValueError: I/O operation on closed file >>> >>> Therefore the quick solution is deleting Data folder and >>> VenueServer.dat, then I run VenueServer24 and I go to >>> VenueManagement24 to create a default Venue with multicast >>> addresses for video and audio. I press Ok to save the >>> configuration and close the program. Then to check the >>> configuration I connect a client to the server and I see all I >>> configured is ok, however I make a cat to VenueServer.dat and the >>> information about the default Venue doesn't appear, the file >>> didn't change so it's quite uncomprenhensible. I was trying to >>> get some aditional information from Logs and all I could find was >>> this clue: >> >> The changing configuration is kept in memory and occasionally >> written out to the VenueServer.dat file. If the server is shut >> down before the new configuration is written out then the >> VenueServer.dat file may not contain the correct configuration. >> >> You can force writing of the configuration from the >> VenueManagement tool from the Server->Checkpoint menu. Wait until >> this has completed and then it is safe to close down the server. >> Hopefully your VenueServer.dat file will then be correct. >> >> >> >>> For now I removed the VenueServer script from the startup. First, >>> it must work fine manually, then I'll try to find a solution for >>> the startup of the services. >> >> I think the manual starting will always work because you cd into >> the correct directory before you start the server. This cd into >> the correct directory must also be part of any startup script you >> use. >> >> >> chris >> >> >> >>> Christoph Willing escribiï¿½: >>>> >>>> On 18/10/2007, at 5:24 PM, Nico wrote: >>>> >>>>> Hi Chris! >>>>> >>>>> When I start VenueServer manually I use the same command as in >>>>> the script file. The syntax is the same. I have a little script >>>>> (called venue_server) in /home/ag/venue_server3 with this line: >>>>> >>>>> VenueServer -c VenueServer.cfg -p 9000 & >>>>> >>>>> So, I just execute at this way: ./venue_server with "ag" user. >>>>> >>>>> The entry for 'persistenceFilename' in VenueServer.cfg is >>>>> 'VenueServer.dat' >>>>> >>>>> persistenceFilename = VenueServer.dat >>>> >>>> Nico, >>>> >>>> From this information, I'm pretty sure your problems are related >>>> to the VenueServer being run from the incorrect directory. >>>> >>>> When the server is started manually from the venue_server3 >>>> directory, it runs correctly. That directory contains the >>>> correct VenueServer.dat file (and also a Data directory). The >>>> persistenceFilename set in the VenueServer.cfg file says >>>> 'VenueServer.dat' but note that this is a relative (not >>>> absolute) path name. The problem is that it is relative to the >>>> location the server is running from, _not_ relative to the >>>> location of the VenueServer.cfg file. If the server is run, for >>>> instance, from /var/tmp then a VenueServer.dat is expected to be >>>> in /var/tmp even when you specify the correct VenueServer.cfg >>>> file somewhere else. If no VenueServer.dat file is found, a new >>>> one is created containing just a default lobby. If the server is >>>> run from /home/ag/venueserver3 directory then the correct >>>> VenueServer.dat file is found. >>>> >>>> When you run from the init.d script, you're using a 'daemonAG' >>>> command which I presume is based on the plain 'daemon' command >>>> which is sourced from /etc/rc.d/init.d/functions. If you look at >>>> the definition of the 'daemon' function in that file, you'll see >>>> that it is just a wrapper for the 'runuser' command (which >>>> itself is a cut down version of the more traditional 'su' >>>> command). You'll also see that runuser is invoked with the '-' >>>> option i.e. it runs in a login shell of the specified user ('ag' >>>> in this case). That means that when the VenueServer command is >>>> run, it is run from ag's home directory /home/ag, not /home/ag/ >>>> venue_server3 as you intend. >>>> >>>> My guess is that you see your previous venues because you used >>>> to run your AG2 venue server the same way and so /home/ag >>>> already contains a useable VenueServer.dat file (even if its not >>>> the one you intend, which is in the venue_server3 directory). >>>> >>>> Was the AG2 server running at the same time you ran the AG3 >>>> server from the init.d script? I think this would be a big >>>> problem with both the AG2 and AG3 servers attempting to use the >>>> same .dat file simultaneously! >>>> >>>> The solution is to have your script cd to the correct directory >>>> before running VenueServer && preventing it from running from a >>>> login shell. If your daemonAG is largely a copy of the 'daemon' >>>> function in /etc/rc.d/init.d/functions, then you could edit >>>> daemonAG command to remove the '-' option from the invocation of >>>> 'runuser' i.e. change the line: >>>> $nice runuser -s /bin/bash - $user -c "$corelimit >/dev/null >>>> 2>&1 ; $*" >>>> to: >>>> $nice runuser -s /bin/bash $user -c "$corelimit >/dev/null >>>> 2>&1 ; $*" >>>> >>>> Then change your init.d script line: >>>> daemonAG --user ag VenueServer -c /home/ag/venue_server3/ >>>> VenueServer.cfg -p 9000 >>>> to: >>>> cd /home/ag/venue_server3 && daemonAG --user ag VenueServer - >>>> c /home/ag/venue_server3/VenueServer.cfg -p 9000 >>>> >>>> If you use this line, you don't really need to specify the >>>> VenueServer.cfg location since the VenueServer will look for the >>>> cfg file in the directory in which it is running i.e. the line >>>> could be: >>>> cd /home/ag/venue_server3 && daemonAG --user ag VenueServer -p >>>> 9000 >>>> >>>> >>>> Another possible solution (untried) is to specify an absolute >>>> path name for the persistenceFilename entry in the >>>> VenueServer.cfg file i.e. instead of >>>> persistenceFilename = VenueServer.dat >>>> try: >>>> persistenceFilename = /home/ag/venue_server3/VenueServer.dat >>>> >>>> BTW this problem will also occur with the server's data store >>>> which is under the 'Data' directory. This is also specified in >>>> the VenueServer.cfg file as the 'dataStorageLocation = Data' entry. >>>> >>>> >>>> chris >>>> >>>> >>>> >>>>> Christoph Willing escribiï¿½: >>>>>> >>>>>> On 18/10/2007, at 12:33 AM, Nico wrote: >>>>>> >>>>>>> Hi Chris! >>>>>>> >>>>>>> Thanks for answering! When I start from the script in init.d >>>>>>> and I connect a client and I can see all Venues, but I can't >>>>>>> enter in any of them because I obtain the error messages I >>>>>>> mentioned in the first mail. >>>>>>> >>>>>>> In the script I have a line different than you to execute >>>>>>> VenueServer, but I've specified the "ag" user: >>>>>>> >>>>>>> daemonAG --user ag VenueServer -c /home/ag/venue_server3/ >>>>>>> VenueServer.cfg -p 9000 >>>>>> >>>>>> Nico, >>>>>> >>>>>> When you start the server manually and clients can connect to >>>>>> all venues, which directory are you starting from? With the >>>>>> line above there may be a problem with which VenueServer.dat >>>>>> file is used. What is the entry for 'persistenceFilename' in >>>>>> your /home/ag/venue_server3/VenueServer.cfg file? >>>>>> >>>>>> >>>>>> chris >>>>>> >>>>>> >>>>>>> Maybe our scripts are different. I used the syntax from this >>>>>>> forum: http://www-unix.mcs.anl.gov/web-mail-archive/lists/ag- >>>>>>> tech/2006/02/msg00023.html >>>>>>> >>>>>>> VenueServer for version 2.4 runs ok with the same syntax. >>>>>>> >>>>>>> Thanks again for your help! See you soon! >>>>>>> >>>>>>> Nico. >>>>>>> >>>>>>> Christoph Willing escribiï¿½: >>>>>>>> >>>>>>>> On 17/10/2007, at 9:53 PM, Nico wrote: >>>>>>>> >>>>>>>>> Hi! >>>>>>>>> >>>>>>>>> In our company we have an AG Server on a Linux Fedora Core >>>>>>>>> 4 machine with Access Grid 3.0.2 installed. We have several >>>>>>>>> Venues configured. During these days I've been configuring >>>>>>>>> start scripts on the /etc/init.d folder to automatically >>>>>>>>> run Venue Server at the start of the system. So the >>>>>>>>> proccess VenueServer is ok when I reboot the machine, but >>>>>>>>> when I connect a client I can connect to https://server: >>>>>>>>> 9000/Venues/default but I can't enter in any configured >>>>>>>>> Venue on the server, I try it, but I receive the following >>>>>>>>> error message: "Error entering venue". >>>>>>>>> >>>>>>>>> So the quick solution is start Venue Server again manually, >>>>>>>>> then I can enter in any Venue. >>>>>>>>> >>>>>>>>> Could somebody tell me what can happen? >>>>>>>> >>>>>>>> >>>>>>>> Nico, >>>>>>>> >>>>>>>> Are the additional venues you've created actually visible to >>>>>>>> the client when the server is started from the init.d script? >>>>>>>> >>>>>>>> If not, then my guess is that whenever the server is started >>>>>>>> from the script in init.d directory, it is being run by the >>>>>>>> root user instead of the ordinary user who created the >>>>>>>> additional venue structure. In that case the server starts >>>>>>>> in the wrong directory and doesn't find the VenueServer.dat >>>>>>>> file that contains your venue structure (which was created >>>>>>>> when you ran the server as an ordinary user). >>>>>>>> >>>>>>>> Your init.d script should explicitly cd to the directory >>>>>>>> containing the correct VenueServer.dat file. It should also >>>>>>>> su to an ordinary user account to actually run the venue >>>>>>>> server. >>>>>>>> >>>>>>>> Here is the crucial line in our startup script which starts >>>>>>>> the server. You can see the cd to the directory which >>>>>>>> contains the VenueServer.dat file and if that succeeds it >>>>>>>> runs VenueServer3.py as the user 'ag' (not root). >>>>>>>> >>>>>>>> cd /var/lib/ag/server_HALL && su ag -c /usr/bin/ >>>>>>>> VenueServer3.py & >>>>>>>> >>>>>>>> Since you run Fedora, I think your executable will be just >>>>>>>> 'VenueServer' (rather than 'VenueServer3.py') Christoph Willing +61 7 3365 8350 QCIF Access Grid Manager University of Queensland

1 0

Re: [AG-TECH] Problems with Access Grid 3.0.2
by Nico 30 Oct '07

30 Oct '07

Hi Chris! Sorry, I was quite busy and I couldn't answer, but at the end I tried the other solution you gave me: -------------------------------------------------------------------------------------------- change the line in /etc/rc.d/init.d/functions: $nice runuser -s /bin/bash - $user -c "$corelimit >/dev/null 2>&1 ; $*" to: $nice runuser -s /bin/bash $user -c "$corelimit >/dev/null 2>&1 ; $*" Then change your init.d script line: daemonAG --user ag VenueServer -c /home/ag/venue_server3/VenueServer.cfg -p 9000 to: cd /home/ag/venue_server3 && daemonAG --user ag VenueServer -c /home/ag/venue_server3/VenueServer.cfg -p 9000 ----------------------------------------------------------------------------------------------------- Doing this I obtain the same problems than before, nothing change after rebooting. VenueServer3 and 24 run at the startup but doesn't work when you connect a client. In fact, I've just realized that when I rebooted VenueServer.dat content for AG24 changed for content of AG3 but is not the same content of /home/ag/venue_server3/VenueServer.dat. So that you can see better: /home/ag/VenueServer.dat before rebooting: # AGTk 2.4 [00000115d19508c100c100900024008c71c] type : Venue name : CESGA's Lobby uri : 00000115d19508c100c100900024008c71c description : Servidor de salas do CESGA (Centro de Supercomputacion de Galicia) encryptMedia : 0 cleanupTime : 300 streams : 00000115d1e2a33200c100900024008cefd:00000115d1e2a33200c100900024008cef6 authorizationPolicy : <?xml version="1.0" ?><LF><AuthorizationPolicy><Role name="VenueUsers"><Subject auth_data="" auth_type="x509" name="/O=Access Grid/OU=agdev-ca.mcs.anl.gov/CN=ServiceManager/DDJK232J.cesga.es"/></Role><Role name="Administrators"><............... /home/ag/VenueServer.dat after rebooting: # AGTk 3.0.2 [c190248c066b4b5f256f73e6418d426f] type : Venue name : Venue Server Lobby uri : c190248c066b4b5f256f73e6418d426f description : This is the lobby of the Venue Server, it has been created because there are no venues yet. Please configure your Venue Server! For more information see http://www.accessgrid.org/ and http://www.mcs.anl.gov/fl/research/accessgrid. encryptMedia : 0 authorizationPolicy : <?xml version="1.0" ?><LF><AuthorizationPolicy><Role name="AllowedEntry"/><Role name="VenueUsers"/><Role name="Administrators"><Subject auth_data="" auth_type="x509" name="/O=Access Grid/OU=agdev-ca.mcs.anl.gov/CN=VenueServer/agserver.cesga.es"/></Role><Role name="Everybody"/><Action name="Enter"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="Exit"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetStreams"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="UpdateLifetime"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="NegotiateCapabilities"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetStaticStreams"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetUploadDescriptor"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetRolesForSubject"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="CreateApplication"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="UpdateApplication"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="DestroyApplication"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="UpdateClientProfile"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="AddService"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="RemoveService"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="UpdateService"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetServices"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="AddData"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="UpdateData"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="RemoveData"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetDataStoreInformation"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetDataDescriptions"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="AddNetworkService"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="RemoveNetworkService"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetNetworkServices"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetClients"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetCachedProfiles"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="AddConnection"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="RemoveConnection"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetConnections"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="SetConnections"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetEncryptMedia"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetDescription"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetName"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetApplication"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetApplications"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="AddNetworkLocationToStream"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="RemoveNetworkLocationFromStream"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetEventServiceLocation"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="DetermineSubjectRoles"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="AddNetService"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="RemoveNetService"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="IsAuthorized"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="IsValid"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="AllocateMulticastLocation"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="RecycleMulticastLocation"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetState"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action><Action name="GetVersion"><Role name="AllowedEntry"/><Role name="Everybody"/><Role name="Administrators"/></Action></AuthorizationPolicy> [00000115d19508c100c100900024008c71c] type : Venue name : CESGA's Lobby uri : 00000115d19508c100c100900024008c71c description : Servidor de salas do CESGA (Centro de Supercomputacion de Galicia) encryptMedia : 0 streams : c190248c066b4b5f25d2d61052cf2cb0:c190248c066b4b5f25d5d6105470a35b authorizationPolicy : <?xml version="1.0" ?><LF><AuthorizationPolicy><Role name="VenueUsers"/><Role name="Administrators"><Subject auth_data="" auth_type="x509" name="/O=Access Grid/O=Argonne National Laboratory/OU=Futures Lab Anonymous Authority/CN=Anonymous User 8b39bff3b256cb464d8622ba2e37d245"/><Subject auth_data="" auth_type="x509" name="/O=Access Grid/OU=agdev-ca.mcs.anl.gov/CN=VenueServer/agserver.cesga.es"/>......... It seems after rebooting, new information is added related to a AG3 Venue (pay attention to the header). Uncomprenhensible. Respect to AG3, the same problem, since a client I can't enter any venue. I keep trying things, but there is no improvement and running the services manually seems to be the only valid solution. Any help would be appreciated. Thank you very much! Nico. Christoph Willing escribiï¿½: > > On 23/10/2007, at 1:37 AM, Nico wrote: > >> Hi Chris again! >> >> Well, I don't where to start but I'll try to explain all my problems >> as well as I can because I have some difficulties with English. >> >> I didn't try all the solutions you gave me in the last email, but I >> tried the last solution changing the address in "persistenceFilename" >> entry as this: >> >> persistenceFilename = /home/ag/venue_server3/VenueServer.dat (The >> same for the Data folder) >> >> Then, I rebooted the machine and it didn't work, in fact I think I >> obtained some errors, but I'm not sure. So I correct VenueServer.cfg >> again. > > > Nico, > > I've now tried this method myself and found that it does not work > correctly yet. The server will use the different data store and > persistenceFilename if they are specified in the cfg file, however the > data written to the .dat file is incorrect - a bug for fixing sometime. > > > >> After that I started to have problems with Access Grid 2.4 too (I >> have another script on the startup for VenueServer24). At any way, is >> not the first problem I have with AG2.4. The problem I have is that >> VenueServer.dat (for AG2.4) become corrupt file and VenueServer24 >> runs but with problems, when I execute it I have this messages: > [snip] >> File "/usr/lib/python2.4/ConfigParser.py", line 520, in get >> raise NoOptionError(option, section) >> ConfigParser.NoOptionError: No option 'cleanuptime' in section: >> 'c190248c0648459db8c5401e80b4f0a0' > > This means that the VenueServer.dat file being used now by your AG2 > server was sometime also used by the AG3 server, at which time a new > venue was created. The new venue did not include a 'cleanuptime' > feature (because it is not used by AG3) but it is expected to to be > there by the AG2 server which then complains when the feature is not > found. > > >> Traceback (most recent call last): >> File "/usr/lib/python2.4/logging/handlers.py", line 62, in emit >> if self.shouldRollover(record): >> File "/usr/lib/python2.4/logging/handlers.py", line 132, in >> shouldRollover >> self.stream.seek(0, 2) #due to non-posix-compliant Windows feature >> ValueError: I/O operation on closed file >> >> Therefore the quick solution is deleting Data folder and >> VenueServer.dat, then I run VenueServer24 and I go to >> VenueManagement24 to create a default Venue with multicast addresses >> for video and audio. I press Ok to save the configuration and close >> the program. Then to check the configuration I connect a client to >> the server and I see all I configured is ok, however I make a cat to >> VenueServer.dat and the information about the default Venue doesn't >> appear, the file didn't change so it's quite uncomprenhensible. I was >> trying to get some aditional information from Logs and all I could >> find was this clue: > > The changing configuration is kept in memory and occasionally written > out to the VenueServer.dat file. If the server is shut down before the > new configuration is written out then the VenueServer.dat file may not > contain the correct configuration. > > You can force writing of the configuration from the VenueManagement > tool from the Server->Checkpoint menu. Wait until this has completed > and then it is safe to close down the server. Hopefully your > VenueServer.dat file will then be correct. > > > >> For now I removed the VenueServer script from the startup. First, it >> must work fine manually, then I'll try to find a solution for the >> startup of the services. > > I think the manual starting will always work because you cd into the > correct directory before you start the server. This cd into the > correct directory must also be part of any startup script you use. > > > chris > > > >> Christoph Willing escribiï¿½: >>> >>> On 18/10/2007, at 5:24 PM, Nico wrote: >>> >>>> Hi Chris! >>>> >>>> When I start VenueServer manually I use the same command as in the >>>> script file. The syntax is the same. I have a little script (called >>>> venue_server) in /home/ag/venue_server3 with this line: >>>> >>>> VenueServer -c VenueServer.cfg -p 9000 & >>>> >>>> So, I just execute at this way: ./venue_server with "ag" user. >>>> >>>> The entry for 'persistenceFilename' in VenueServer.cfg is >>>> 'VenueServer.dat' >>>> >>>> persistenceFilename = VenueServer.dat >>> >>> Nico, >>> >>> From this information, I'm pretty sure your problems are related to >>> the VenueServer being run from the incorrect directory. >>> >>> When the server is started manually from the venue_server3 >>> directory, it runs correctly. That directory contains the correct >>> VenueServer.dat file (and also a Data directory). The >>> persistenceFilename set in the VenueServer.cfg file says >>> 'VenueServer.dat' but note that this is a relative (not absolute) >>> path name. The problem is that it is relative to the location the >>> server is running from, _not_ relative to the location of the >>> VenueServer.cfg file. If the server is run, for instance, from >>> /var/tmp then a VenueServer.dat is expected to be in /var/tmp even >>> when you specify the correct VenueServer.cfg file somewhere else. If >>> no VenueServer.dat file is found, a new one is created containing >>> just a default lobby. If the server is run from >>> /home/ag/venueserver3 directory then the correct VenueServer.dat >>> file is found. >>> >>> When you run from the init.d script, you're using a 'daemonAG' >>> command which I presume is based on the plain 'daemon' command which >>> is sourced from /etc/rc.d/init.d/functions. If you look at the >>> definition of the 'daemon' function in that file, you'll see that it >>> is just a wrapper for the 'runuser' command (which itself is a cut >>> down version of the more traditional 'su' command). You'll also see >>> that runuser is invoked with the '-' option i.e. it runs in a login >>> shell of the specified user ('ag' in this case). That means that >>> when the VenueServer command is run, it is run from ag's home >>> directory /home/ag, not /home/ag/venue_server3 as you intend. >>> >>> My guess is that you see your previous venues because you used to >>> run your AG2 venue server the same way and so /home/ag already >>> contains a useable VenueServer.dat file (even if its not the one you >>> intend, which is in the venue_server3 directory). >>> >>> Was the AG2 server running at the same time you ran the AG3 server >>> from the init.d script? I think this would be a big problem with >>> both the AG2 and AG3 servers attempting to use the same .dat file >>> simultaneously! >>> >>> The solution is to have your script cd to the correct directory >>> before running VenueServer && preventing it from running from a >>> login shell. If your daemonAG is largely a copy of the 'daemon' >>> function in /etc/rc.d/init.d/functions, then you could edit daemonAG >>> command to remove the '-' option from the invocation of 'runuser' >>> i.e. change the line: >>> $nice runuser -s /bin/bash - $user -c "$corelimit >/dev/null >>> 2>&1 ; $*" >>> to: >>> $nice runuser -s /bin/bash $user -c "$corelimit >/dev/null 2>&1 >>> ; $*" >>> >>> Then change your init.d script line: >>> daemonAG --user ag VenueServer -c >>> /home/ag/venue_server3/VenueServer.cfg -p 9000 >>> to: >>> cd /home/ag/venue_server3 && daemonAG --user ag VenueServer -c >>> /home/ag/venue_server3/VenueServer.cfg -p 9000 >>> >>> If you use this line, you don't really need to specify the >>> VenueServer.cfg location since the VenueServer will look for the cfg >>> file in the directory in which it is running i.e. the line could be: >>> cd /home/ag/venue_server3 && daemonAG --user ag VenueServer -p 9000 >>> >>> >>> Another possible solution (untried) is to specify an absolute path >>> name for the persistenceFilename entry in the VenueServer.cfg file >>> i.e. instead of >>> persistenceFilename = VenueServer.dat >>> try: >>> persistenceFilename = /home/ag/venue_server3/VenueServer.dat >>> >>> BTW this problem will also occur with the server's data store which >>> is under the 'Data' directory. This is also specified in the >>> VenueServer.cfg file as the 'dataStorageLocation = Data' entry. >>> >>> >>> chris >>> >>> >>> >>>> Christoph Willing escribiï¿½: >>>>> >>>>> On 18/10/2007, at 12:33 AM, Nico wrote: >>>>> >>>>>> Hi Chris! >>>>>> >>>>>> Thanks for answering! When I start from the script in init.d and >>>>>> I connect a client and I can see all Venues, but I can't enter in >>>>>> any of them because I obtain the error messages I mentioned in >>>>>> the first mail. >>>>>> >>>>>> In the script I have a line different than you to execute >>>>>> VenueServer, but I've specified the "ag" user: >>>>>> >>>>>> daemonAG --user ag VenueServer -c >>>>>> /home/ag/venue_server3/VenueServer.cfg -p 9000 >>>>> >>>>> Nico, >>>>> >>>>> When you start the server manually and clients can connect to all >>>>> venues, which directory are you starting from? With the line above >>>>> there may be a problem with which VenueServer.dat file is used. >>>>> What is the entry for 'persistenceFilename' in your >>>>> /home/ag/venue_server3/VenueServer.cfg file? >>>>> >>>>> >>>>> chris >>>>> >>>>> >>>>>> Maybe our scripts are different. I used the syntax from this >>>>>> forum: >>>>>> http://www-unix.mcs.anl.gov/web-mail-archive/lists/ag-tech/2006/02/msg00023… >>>>>> >>>>>> >>>>>> VenueServer for version 2.4 runs ok with the same syntax. >>>>>> >>>>>> Thanks again for your help! See you soon! >>>>>> >>>>>> Nico. >>>>>> >>>>>> Christoph Willing escribiï¿½: >>>>>>> >>>>>>> On 17/10/2007, at 9:53 PM, Nico wrote: >>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> In our company we have an AG Server on a Linux Fedora Core 4 >>>>>>>> machine with Access Grid 3.0.2 installed. We have several >>>>>>>> Venues configured. During these days I've been configuring >>>>>>>> start scripts on the /etc/init.d folder to automatically run >>>>>>>> Venue Server at the start of the system. So the proccess >>>>>>>> VenueServer is ok when I reboot the machine, but when I connect >>>>>>>> a client I can connect to https://server:9000/Venues/default >>>>>>>> but I can't enter in any configured Venue on the server, I try >>>>>>>> it, but I receive the following error message: "Error entering >>>>>>>> venue". >>>>>>>> >>>>>>>> So the quick solution is start Venue Server again manually, >>>>>>>> then I can enter in any Venue. >>>>>>>> >>>>>>>> Could somebody tell me what can happen? >>>>>>> >>>>>>> >>>>>>> Nico, >>>>>>> >>>>>>> Are the additional venues you've created actually visible to the >>>>>>> client when the server is started from the init.d script? >>>>>>> >>>>>>> If not, then my guess is that whenever the server is started >>>>>>> from the script in init.d directory, it is being run by the root >>>>>>> user instead of the ordinary user who created the additional >>>>>>> venue structure. In that case the server starts in the wrong >>>>>>> directory and doesn't find the VenueServer.dat file that >>>>>>> contains your venue structure (which was created when you ran >>>>>>> the server as an ordinary user). >>>>>>> >>>>>>> Your init.d script should explicitly cd to the directory >>>>>>> containing the correct VenueServer.dat file. It should also su >>>>>>> to an ordinary user account to actually run the venue server. >>>>>>> >>>>>>> Here is the crucial line in our startup script which starts the >>>>>>> server. You can see the cd to the directory which contains the >>>>>>> VenueServer.dat file and if that succeeds it runs >>>>>>> VenueServer3.py as the user 'ag' (not root). >>>>>>> >>>>>>> cd /var/lib/ag/server_HALL && su ag -c >>>>>>> /usr/bin/VenueServer3.py & >>>>>>> >>>>>>> Since you run Fedora, I think your executable will be just >>>>>>> 'VenueServer' (rather than 'VenueServer3.py') >>>>>>> >>>>>>> >>>>>>> >>>>>>> chris >>>>>>> >>>>>>> >>>>>>> Christoph Willing +61 7 3365 8350 >>>>>>> QCIF Access Grid Manager >>>>>>> University of Queensland >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> Christoph Willing +61 7 3365 8350 >>>>> QCIF Access Grid Manager >>>>> University of Queensland >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> Christoph Willing +61 7 3365 8350 >>> QCIF Access Grid Manager >>> University of Queensland >>> >>> >>> >>> >>> > > Christoph Willing +61 7 3365 8350 > QCIF Access Grid Manager > University of Queensland > > > > >

1 0

Re: [AG-TECH] VPCScreen Capture
by Jeremy Mann 30 Oct '07

30 Oct '07

Chris, would it be possible to get the source for VPCScreen? On 10/30/07, Christoph Willing <willing(a)vislab.uq.edu.au> wrote: > Debian & Ubuntu versions of VPCScreen are now available via the > Vislab repositories or, for full instructions, see: > http://www.vislab.uq.edu.au/research/accessgrid/software/debian/ > vpcscreen.html > > > chris > > > Christoph Willing +61 7 3365 8350 > QCIF Access Grid Manager > University of Queensland > > > > -- Jeremy Mann jeremy(a)biochem.uthscsa.edu University of Texas Health Science Center Bioinformatics Core Facility http://www.bioinformatics.uthscsa.edu Phone: (210) 567-2672

1 0

Re: [AG-TECH] VPCScreen Capture
by Jeremy Mann 30 Oct '07

30 Oct '07

On 10/29/07, Jason Bell <j.bell(a)cqu.edu.au> wrote: > In regards to frame rates, it appears the version I am using is only > capable of 10 frames a second. > > As a hint, if you bump up the quality and bandwidth, it produces a > pretty good video stream. In my test yesterday of a 1280x1024 desktop, the performance was perfect. For what we normally use VNC for, 10fps or lower is perfect. One thing I would like to see though, is a way to rename the video stream in VIC so people would know its a Desktop or Window video stream. -- Jeremy Mann jeremy(a)biochem.uthscsa.edu University of Texas Health Science Center Bioinformatics Core Facility http://www.bioinformatics.uthscsa.edu Phone: (210) 567-2672

1 0

Re: [AG-TECH] VPCScreen Capture
by Christoph Willing 30 Oct '07

30 Oct '07

Debian & Ubuntu versions of VPCScreen are now available via the Vislab repositories or, for full instructions, see: http://www.vislab.uq.edu.au/research/accessgrid/software/debian/ vpcscreen.html chris Christoph Willing +61 7 3365 8350 QCIF Access Grid Manager University of Queensland

1 0

RE: [AG-TECH] Vic Source issue - Multiple Producers (Again)
by Douglas Kosovic 29 Oct '07

29 Oct '07

Hi Todd, > This problem still exists on Fedora for me (AG3.1b2). It exists on > multiple computers; however.... > Am I the only person experiencing this? > > Symptoms are: > > Multiple video producers on Fedora and/or Redhat. > When I join a room, the proper device and port are selected; however on > some of the producers (not consistent... sometimes one, sometimes two > etc) it is just blue output. > When I hit 'Menu' and reselect the port (not even deselect - just > reselct) the camera source properly shows up. Install the vic-debug-enabled RPM from: http://www.vislab.uq.edu.au/accessgrid3/fedora/development/RPMS/ e.g: rpm -e --nodeps vic rpm -ivh vic-debug-enabled-2.8ucl1.3.1-0.1.20071017svn.fc7.i386.rpm it should hopefully output debugging info on what is going wrong. > Further, on many of these capture cards (bttv based Impact VCB) I have > to select the Television input when in fact I'm using one of the > Composite inputs.... The Impact VCB isn't listed in bttv-cards.c source file of the bttv driver, the known cards have their input port details and other stuff recorded in that file (like the GPIO bus wiring), if the card isn't known the bttv driver fallbacks to a generic bt878 card (which might only partly work). You might be able to configure /etc/modprobe.conf to tell the bttv driver what is what by using module arguments or submit a bug report to the bttv driver maintainer to have your card's details added. The Windows application btspy (in combination with the original Windows driver for the card) is often used to get the specific details of the Bt878 based card. Cheers, Doug

1 0

RE: [AG-TECH] VPCScreen Capture
by Jason Bell 29 Oct '07

29 Oct '07

G'day Gurcharan and Jeremy In regards to pixel size, I have sent my laptop screen 1280 x 800 in which works very well. I have also tried sending my main AG nodes screen 4128 x 768 in which seems to work. It did appear a little slow, but I suspect this is because I was VNC'ing into the machine and the machine is quite old. In regards to frame rates, it appears the version I am using is only capable of 10 frames a second. As a hint, if you bump up the quality and bandwidth, it produces a pretty good video stream. Thank for your emails, Jason. -----Original Message----- From: Jeremy Mann [mailto:[email protected]] Sent: Monday, 29 October 2007 11:52 PM To: gurcharan khanna Cc: ag-tech Subject: Re: [AG-TECH] VPCScreen Capture I too would be interested in streaming the entire Desktop. We're coming into issues with VNC that I can't seem to solve when a lot of people connect. On 10/29/07, gurcharan khanna <gskpop(a)cis.rit.edu> wrote: > Jason, > > What is the maximum pixel resolution of the transmitted image? > > And is the framerate a max of 10 as indicated on the screenshot? > > Thanks, > > -gurcharan > > PS I am looking for a way to transmit the entire desktop at full resolution > and 30 fps. Doing it without additional hardware would be great! > > Jason Bell wrote: > > Dear colleagues > > > > I would like to take this opportunity to highlight an add-on service for > > the Access Grid that is extremely useful. (With thanks to Rhys Hawkins > > and Yifan Lu for there development work) > > > > VPCScreen is a video producer service for the AccessGrid that captures > > your desktop (or part thereof) and sends it as an H261, H261AS or JPEG > > video stream. > > > > It is particularly useful for when you wish to send only part of a > > display, or just a single window. > > > > VPCScreen is available for Linux and Windows (Sorry Mac users, though > > you can view the VPCScreen streams). > > > > VPCScreen Capture Uses > > ---------------------- > > > > o Streaming of a PowerPoint or equivalent presentation > > > > o Streaming a video/animation > > > > o Streaming a unique application > > > > o Streaming any particular item from your desktop to everyone else > > > > VPCScreen Capture Benefits > > -------------------------- > > > > o If using H261AS and transmitting at custom size, this allows pixel to > > pixel screen resolution and doesn't require any additional applications > > to view the stream. This is very useful for sessions that have lots of > > connections which "VNC" or "Share Presentations" become problematic! > > > > o All is required is the latest version of vic, which come supplied with > > the AGTK 3.1Beta2 (or later) release > > > > o Because video stream is injected into the multicast stream, you can > > record (using AGVCR or similar) presentations as part of the recording. > > > > Details on VPCSCreen and it associated download can be found at > > http://www.accessgrid.org/project/VPCScreen. > > > > I hope you find this application as useful as I do. > > > > Thanks for your time, > > Jason. > > > > -------------------------------------------- > > Jason Bell, B.I.T. > > > > B. Info. Tech. (Honours) Student > > > > High Performance Computing Support Officer, > > Network Engineer > > Information Technology Division > > Central Queensland University > > > > E-mail : j.bell(a)cqu.edu.au > > Phone : 07 4930 9229 > > -------------------------------------------- > > Patience is a virtue. > > > > But if I wanted Patience, > > I would have become a Doctor. > > -------------------------------------------- > > > > > > > -- > ------------------------- > Gurcharan S. Khanna, Ph.D. > Director of Research Computing > Office of the Vice President for Research > > Director, Interactive Collaboration Environments Laboratory, > Center for the Advancing the Study of Cyberinfrastructure > --- > Rochester Institute of Technology > 1 Lomb Memorial Drive > Rochester, New York 14623-5603 > Phone: 585-475-7504 ~ Cell: 585-451-8370 > Email: gurcharan.khanna(a)rit.edu > Http: www.rit.edu/~gskpop > > -- Jeremy Mann jeremy(a)biochem.uthscsa.edu University of Texas Health Science Center Bioinformatics Core Facility http://www.bioinformatics.uthscsa.edu Phone: (210) 567-2672

1 0

Re: [AG-TECH] Vic Source issue - Multiple Producers (Again)
by Christoph Willing 29 Oct '07

29 Oct '07

On 30/10/2007, at 7:27 AM, Todd Zimmerman wrote: > Todd Zimmerman wrote: >> Douglas Kosovic wrote: >>> You could try the vic-2.8ucl1.3.0-0.1.20070816svn.el5 RPM instead. I >>> built some i386 RHEL5/CentOS5 AG RPMs a few days ago: >>> http://www.vislab.uq.edu.au/accessgrid3/centos/ >>> or the symlink: >>> http://www.vislab.uq.edu.au/accessgrid3/rhel/ >>> >>> 'dmesg' might give some indication of what's going on. >>> >> >> New EL vic has same behaviour - no messages in dmesg. >> >> Didn't update the entire AG (just Vic) due to conflicts with epel >> and some installed software - but, >> same behavior when running multiple vics manually. >> >>> On RHEL5, try installing a kernel-2.6.22 RPM from Fedora Core6 >>> updates >>> and see if you get the same symptoms with the V4L that comes with >>> the >>> newer kernel. >> >> May just go to Fedora - and will email if problem still exists. >> >> Thanks, >> >> Todd >> > > > This problem still exists on Fedora for me (AG3.1b2). It exists on > multiple computers; however.... > Am I the only person experiencing this? > > Symptoms are: > > Multiple video producers on Fedora and/or Redhat. > When I join a room, the proper device and port are selected; > however on some of the producers (not > consistent... sometimes one, sometimes two etc) it is just blue > output. When I hit 'Menu' and > reselect the port (not even deselect - just reselct) the camera > source properly shows up. Further, > on many of these capture cards (bttv based Impact VCB) I have to > select the Television input when in > fact I'm using one of the Composite inputs.... Todd, Newer versions of AGTk have updated input detection/selection code to accommodate V4l2 devices available in new UCL vic. This means that the ordering of detected devices is different to previous versions. Its likely that your VideoProducerService's were configured with the older device ordering, leading to problems similar to those you're experiencing. I recommend that you Remove the existing services (don't just try to Configure the existing services), then Add new services (and Store the result). chris Christoph Willing +61 7 3365 8350 QCIF Access Grid Manager University of Queensland

1 0

Vic Source issue - Multiple Producers (Again)
by Todd Zimmerman 29 Oct '07

29 Oct '07

Todd Zimmerman wrote: > Douglas Kosovic wrote: >> You could try the vic-2.8ucl1.3.0-0.1.20070816svn.el5 RPM instead. I >> built some i386 RHEL5/CentOS5 AG RPMs a few days ago: >> http://www.vislab.uq.edu.au/accessgrid3/centos/ >> or the symlink: >> http://www.vislab.uq.edu.au/accessgrid3/rhel/ >> >> 'dmesg' might give some indication of what's going on. >> > > New EL vic has same behaviour - no messages in dmesg. > > Didn't update the entire AG (just Vic) due to conflicts with epel and some installed software - but, > same behavior when running multiple vics manually. > >> On RHEL5, try installing a kernel-2.6.22 RPM from Fedora Core6 updates >> and see if you get the same symptoms with the V4L that comes with the >> newer kernel. > > May just go to Fedora - and will email if problem still exists. > > Thanks, > > Todd > This problem still exists on Fedora for me (AG3.1b2). It exists on multiple computers; however.... Am I the only person experiencing this? Symptoms are: Multiple video producers on Fedora and/or Redhat. When I join a room, the proper device and port are selected; however on some of the producers (not consistent... sometimes one, sometimes two etc) it is just blue output. When I hit 'Menu' and reselect the port (not even deselect - just reselct) the camera source properly shows up. Further, on many of these capture cards (bttv based Impact VCB) I have to select the Television input when in fact I'm using one of the Composite inputs.... Thoughts? Todd

1 0