RT for crt.cs.wisc.edu
RT for crt.cs.wisc.edu
Comments about this user:
No comment entered about this user This user's 10 highest priority tickets:
Comments about this user:
No comment entered about this user This user's 10 highest priority tickets:
|
|
| # | Mon Aug 04 18:38:51 2008 | Alan.Sill@ttu.edu - Ticket created | [Reply] | |||||||||||
I am now going to reset ownership of On Aug 4, 2008, at 5:25 PM, Alex Sim wrote: > srm-ping still says connection refused. > Is the bestman server running on 49443? > > > % srm-ping srm://sigmorgh.hpcc.ttu.edu:49443/srm/v2/server >> SRM-CLIENT: Connecting to serviceurl > httpg://sigmorgh.hpcc.ttu.edu:49443/srm/v2/server > > SRM-PING: Mon Aug 04 15:23:59 PDT 2008 Calling SrmPing Request... > SRM-PING : Exception ; nested exception is: > java.net.ConnectException: Connection refused > > can you see if bestman process is running? No, it is not. Exploring: In the vdt-install.log file, which also records service starts, I see: ### 2008-08-04 17:10:20 vdt-control(system) /etc/rc.d/init.d/bestman START ########################################### JAVA_HOME = /usr/local/BeStMan_VDT_1.10.1/jdk1.5 GLOBUS_TCP_PORT_RANGE = 40000,50000 X509_CERT_DIR = /usr/local/BeStMan_VDT_1.10.1/globus/TRUSTED_CA GSI_DAEMON_TRUSTED_CA_DIR = /usr/local/BeStMan_VDT_1.10.1/globus/ TRUSTED_CA MAX_JAVA_HEAP = 512 ########################################### Starting LBNL BeStMan SRM server Configuration file is /usr/local/BeStMan_VDT_1.10.1/bestman/conf/ bestman.rc ## reading configuration file: /usr/local/BeStMan_VDT_1.10.1/bestman/ conf/bestman.rc.......local file system will be accessed through srm server. Assigning log file to be: /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/ bestman/logs/event.srm.log !Warning:Failed to create log file: /usr/local/BeStMan_VDT_1.10.1/vdt- app-data/bestman/logs/event.srm.log for events. Please make sure path exists and has write permission for SRM. ========= Good bye! ========= OK, reasoning this out: The directory exists and has contents owned by the proper user (globus:tigre). Probably as a result of the reconfiguration done inadvertently during the VDT "pacman -update bestman" (which I did NOT want to happen), the ownership of the logs directory itself got set to daemon, whereas I wanted it to run as globus so that the GUMS mapping would work properly and interact properly with our other configured services. Summary: it looks like the "pacman -update bestman" MUST be followed by (a) reconfiguration of any local configuration settings, as I did before, and (b) a careful check of file ownerships before starting the bestman service for he first time. Trying this ... no! I still get the same message. START ########################################### JAVA_HOME = /usr/local/BeStMan_VDT_1.10.1/jdk1.5 GLOBUS_TCP_PORT_RANGE = 40000,50000 X509_CERT_DIR = /usr/local/BeStMan_VDT_1.10.1/globus/TRUSTED_CA GSI_DAEMON_TRUSTED_CA_DIR = /usr/local/BeStMan_VDT_1.10.1/globus/ TRUSTED_CA MAX_JAVA_HEAP = 512 ########################################### Starting LBNL BeStMan SRM server Configuration file is /usr/local/BeStMan_VDT_1.10.1/bestman/conf/ bestman.rc ## reading configuration file: /usr/local/BeStMan_VDT_1.10.1/bestman/ conf/bestman.rc.......local file system will be accessed through srm server. Assigning log file to be: /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/ bestman/logs/event.srm.log !Warning:Failed to create log file: /usr/local/BeStMan_VDT_1.10.1/vdt- app-data/bestman/logs/event.srm.log for events. Please make sure path exists and has write permission for SRM. ========= Good bye! ========= What could be wrong? I checked, and ownership and permissions are the same on munin, which runs, as on sigmorgh, which has the latest Bestman package as updated from the VDT, but does not. Alan Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ==================================================================== |
||||||||||||||
| # | Mon Aug 04 18:47:44 2008 | ASim@lbl.gov - Ticket 3715: Ticket created | [Reply] | |||||||||||
Hi Alan, So you're running bestman under "globus" account... can you see this file: ls -al /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs/ and see who owns the directory/files? thanks -- Alex asim at lbl dot gov On 8/4/08 4:37 PM, Alan Sill wrote: > I am now going to reset ownership of > > On Aug 4, 2008, at 5:25 PM, Alex Sim wrote: > >> srm-ping still says connection refused. >>> Is the bestman server running on 49443? >> >> >> % srm-ping srm://sigmorgh.hpcc.ttu.edu:49443/srm/v2/server >>>> SRM-CLIENT: Connecting to serviceurl >> httpg://sigmorgh.hpcc.ttu.edu:49443/srm/v2/server >> >> SRM-PING: Mon Aug 04 15:23:59 PDT 2008 Calling SrmPing Request... >> SRM-PING : Exception ; nested exception is: >> java.net.ConnectException: Connection refused >> >> can you see if bestman process is running? > > No, it is not. Exploring: > > In the vdt-install.log file, which also records service starts, I see: > > ### 2008-08-04 17:10:20 vdt-control(system) /etc/rc.d/init.d/bestman > START > ########################################### > JAVA_HOME = /usr/local/BeStMan_VDT_1.10.1/jdk1.5 > GLOBUS_TCP_PORT_RANGE = 40000,50000 > X509_CERT_DIR = /usr/local/BeStMan_VDT_1.10.1/globus/TRUSTED_CA > GSI_DAEMON_TRUSTED_CA_DIR = > /usr/local/BeStMan_VDT_1.10.1/globus/TRUSTED_CA > MAX_JAVA_HEAP = 512 > ########################################### > Starting LBNL BeStMan SRM server > Configuration file is > /usr/local/BeStMan_VDT_1.10.1/bestman/conf/bestman.rc > ## reading configuration file: > /usr/local/BeStMan_VDT_1.10.1/bestman/conf/bestman.rc> .......local file system will be accessed through srm server. > Assigning log file to be: > /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs/event.srm.log > !Warning:Failed to create log file: > /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs/event.srm.log > for events. Please make sure path exists and has write permission for > SRM. > ========= Good bye! ========= >> OK, reasoning this out: The directory exists and has contents owned by > the proper user (globus:tigre). Probably as a result of the > reconfiguration done inadvertently during the VDT "pacman -update > bestman" (which I did NOT want to happen), the ownership of the logs > directory itself got set to daemon, whereas I wanted it to run as > globus so that the GUMS mapping would work properly and interact > properly with our other configured services. > > Summary: it looks like the "pacman -update bestman" MUST be followed > by (a) reconfiguration of any local configuration settings, as I did > before, and (b) a careful check of file ownerships before starting the > bestman service for he first time. > > Trying this ... no! I still get the same message. > > START > ########################################### > JAVA_HOME = /usr/local/BeStMan_VDT_1.10.1/jdk1.5 > GLOBUS_TCP_PORT_RANGE = 40000,50000 > X509_CERT_DIR = /usr/local/BeStMan_VDT_1.10.1/globus/TRUSTED_CA > GSI_DAEMON_TRUSTED_CA_DIR = > /usr/local/BeStMan_VDT_1.10.1/globus/TRUSTED_CA > MAX_JAVA_HEAP = 512 > ########################################### > Starting LBNL BeStMan SRM server > Configuration file is > /usr/local/BeStMan_VDT_1.10.1/bestman/conf/bestman.rc > ## reading configuration file: > /usr/local/BeStMan_VDT_1.10.1/bestman/conf/bestman.rc> .......local file system will be accessed through srm server. > Assigning log file to be: > /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs/event.srm.log > !Warning:Failed to create log file: > /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs/event.srm.log > for events. Please make sure path exists and has write permission for > SRM. > ========= Good bye! ========= >> What could be wrong? I checked, and ownership and permissions are the > same on munin, which runs, as on sigmorgh, which has the latest > Bestman package as updated from the VDT, but does not. > > Alan > > > Alan Sill, Ph.D > TIGRE Senior Scientist, High Performance Computing Center > Adjunct Professor of Physics > TTU > > ==================================================================== > : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : > : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : > ==================================================================== >> > |
||||||||||||||
| # | Mon Aug 04 18:57:43 2008 | Alan.Sill@ttu.edu - Correspondence added | [Reply] | |||||||||||
On Aug 4, 2008, at 6:42 PM, Alex Sim wrote: > So you're running bestman under "globus" account... > can you see this file: > ls -al /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs/ > and see who owns the directory/files? On munin (which works): [root@munin ~]# cd /usr/local/grid/vdt-app-data/bestman [root@munin bestman]# ls -al logs total 4288 drwxr-xr-x 2 globus tigre 4096 Jan 24 2008 . drwxr-xr-x 3 root root 4096 Jan 24 2008 .. -rw-r--r-- 1 globus tigre 1080072 Aug 4 11:08 00000000.jdb -rw-r--r-- 1 globus tigre 3291605 Aug 4 11:08 event.srm.log -rw-r--r-- 1 globus tigre 0 Jan 24 2008 je.lck On sigmorgh (which should be set up identically, but does nto work): [root@sigmorgh BeStMan_VDT_1.10.1]# cd vdt-app-data/bestman/ [root@sigmorgh bestman]# ls -al logs total 8 drwxr-xr-x 2 globus tigre 4096 Aug 4 18:31 . drwxr-xr-x 4 root root 4096 Jul 3 12:19 .. Just to be sure, I redid the configuration the way I had it set up before once again, with SRM owned by globus and other parameters adjusted, and started bestman again: [root@sigmorgh BeStMan_VDT_1.10.1]# cd /usr/local/BeStMan_VDT_1.10.1/ bestman/setup/[root@sigmorgh setup]# ./configure --with-replica- storage-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/ cache --with-replica-storage-size=10211 --with-srm-home=/usr/ local/BeStMan_VDT_1.10.1/bestman --with-srm-owner=globus --with- cacert-path=/usr/local/BeStMan_VDT_1.10.1/globus/TRUSTED_CA --with- certfile-path=/etc/grid-security/http/httpcert.pem --with-keyfile- path=/etc/grid-security/http/httpkey.pem --with-eventlog-path=/usr/ local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs --with-cachelog- path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs --with- globus-tcp-port-range=40000,50000 --with-http-port=49080 --with- https-port=49443 --enable-gums --with-gums-url="https://gums.hpcc.ttu.edu:8443/gums/services/GUMSAuthorizationServicePort " --with-gums-dn="/DC=org/DC=doegrids/OU=Services/CN=http/ sigmorgh.hpcc.ttu.edu" checking for correct JAVA path... JAVA found current java version is 1.5.014 checking for JAVA version ( > 1.4.2_07)... ok WARNING: GridMapFileName NOT defined ## GUMS ENABLED GridMapFileName=/usr/local/BeStMan_VDT_1.10.1/bestman/conf/grid- mapfile.empty BeStMan configured... logfile is ... bestman.0804081849.log installing BeStMan server, client and tester configure: creating ./config.status config.status: creating ../bin/srm-ping config.status: creating ../bin/srm-copy config.status: creating ../bin/srm-copy-status config.status: creating ../bin/srm-dir config.status: creating ../bin/srm-extendfilelifetime config.status: creating ../bin/srm-ls config.status: creating ../bin/srm-ls-status config.status: creating ../bin/srm-mkdir config.status: creating ../bin/srm-mv config.status: creating ../bin/srm-permission-check config.status: creating ../bin/srm-permission-get config.status: creating ../bin/srm-permission-set config.status: creating ../bin/srm-putdone config.status: creating ../bin/srm-release config.status: creating ../bin/srm-req-abort config.status: creating ../bin/srm-req-abortfiles config.status: creating ../bin/srm-req-resume config.status: creating ../bin/srm-req-summary config.status: creating ../bin/srm-req-suspend config.status: creating ../bin/srm-req-tokens config.status: creating ../bin/srm-request config.status: creating ../bin/srm-rm config.status: creating ../bin/srm-rmdir config.status: creating ../bin/srm-space config.status: creating ../bin/srm-sp-change config.status: creating ../bin/srm-sp-info config.status: creating ../bin/srm-sp-purge config.status: creating ../bin/srm-sp-release config.status: creating ../bin/srm-sp-reserve config.status: creating ../bin/srm-sp-reserve-status config.status: creating ../bin/srm-sp-tokens config.status: creating ../bin/srm-sp-update config.status: creating ../bin/srm-tester config.status: creating ../bin/srm-transferprotocols config.status: creating ../bin/srm-util config.status: creating ../conf/server-config.wsdd config.status: creating ../sbin/bestman.server config.status: creating ../sbin/SXXbestman config.status: creating ../sbin/SXXbestman.personal ## ReplicaQualityStorageMB=[[10211]]path=/usr/local/BeStMan_VDT_1.10.1/ vdt-app-data/bestman/cache;NOTE: If you have more path to support, edit ../conf/bestman.rc and add to ReplicaQualityStorageMB with semi-colon ";" as seperator e.g. ReplicaQualityStorageMB=3100path=/tmp/cache;200path=/ scratch/cache NOTE: $OUTPUT_STORAGE_PATH or $OUTPUT_STORAGE_SIZE not defined NOTE: If supported, use --with-output-storage-path=<DIRPATH> and --with-output-storage-size=<INT> to define NOTE: $CUSTODIAL_STORAGE_PATH or $CUSTODIAL_STORAGE_SIZE not defined NOTE: If supported, use --with-custodial-storage-path=<DIRPATH> and --with-custodial-storage-size=<INT> to define ## MaxNumberOfUsers=100 WARNING: $PUBLIC_SPACE_PORTION is not defined and## MaxNumberOfFileRequests=1000000 ## Concurrency=40 ## MaxConcurrentFileTransfer=10 ## GridFTPNumStreams=2 ## GridftpBufferSizeBytes=1048576 ## DefaultFileSizeMB=500 ## DefaultVolatileFileLifeTimeInSeconds=1800 ## PublicTokenMaxFileLifetimeInSeconds=1800 ## InactiveTxfTimeOutInSeconds=300 PublicSpaceProportion will be 80 Use --with-public-space-proportion=<INT> to define WARNING: $PUBLIC_SPACE is not defined and PublicSpaceProportion will be used as default Use --with-public-space-size=<INT> to define ## DefaultMBPerToken=1000 ## publicPort=49080 ## securePort=49443 NOTE: supportedProtocolList needs to be added in the conf/bestman.rc : when different from the same hostname that BeStMan runs on e.g. supportedProtocolList=gsiftp://myhost.domain.tlde.g. supportedProtocolList=gsiftp://myhost.domain.tld;gsiftp://host2.domain.tld ## EventLogLocation=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/ logs## CacheLogLocation=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/ logs## useBerkeleyDB=true NOTE: $BERKELEYDB will be used as the internal managementUse --enable-berkeleydb to use berkeley db Use --disable-berkeleydb not to use berkeley db ## srmcacheKeywordOn=true NOTE: $srmcache as keyword will be used as the internal cache managementUse --enable-srmcache-keyword to use srmcache as keyword Use --disable-srmcache-keyword not to use srmcache as keyword WARNING: $PROXY_FILE_PATH is not defined Use --with-proxyfile-path=<INT> to define if desired WARNING: Cert/Key will be used ## CertFileName=/etc/grid-security/http/httpcert.pem GUMS interface enabled## KeyFileName=/etc/grid-security/http/httpkey.pem Grid-mapfile will not be used ## GUMSserviceURL=https://gums.hpcc.ttu.edu:8443/gums/services/GUMSAuthorizationServicePort sigmorgh.hpcc.ttu.edu## GUMSCurrHostDN=/DC=org/DC=doegrids/OU=Services/CN=http/ ## GridMapFileName=/usr/local/BeStMan_VDT_1.10.1/bestman/conf/grid- mapfile.empty## FactoryID=server NOTE: uploadQueueParameter will be used as the transfer queue management## uploadQueueParameter=40:10 Use --enable-twoqueues to use uploadQueueParameter Use --disable-twoqueues not to use uploadQueueParameter ## accessFileSysViaGsiftp=false NOTE: $GSIFTPFSM will not be used as the file managementUse --enable-gsiftpfsmng to use gsiftp Use --disable-gsiftpfsmng not to use gsiftp ## accessFileSysViaSudo=false NOTE: $SUDOFSM will not be used as the file managementUse --enable-sudofsmng to use sudo Use --disable-sudofsmng not to use sudo ## noSudoOnLs=true NOTE: $SUDOLS will not be used as the file managementUse --enable-sudols to use sudo for ls Use --disable-sudols not to use sudo for ls ## MaxMSSConnections=5 WARNING: $PLUGIN_PATH is not defined## mssTimeOutSeconds=600000 Use --with-plugin-path=<INT> to define chmod: cannot access `../bin/g-urlcopy.sh': No such file or directory configuration complete It still does not work. It's as if the ownership I set up in the above configuration command is being ignored somehow. Does anyone in the VDT team have an idea as to what might be wrong? root@sigmorgh setup]# vdt-control --on bestman enabling init service bestman... tail ok [root@sigmorgh setup]# cd ../.. [root@sigmorgh BeStMan_VDT_1.10.1]# tail vdt-install.log ########################################### Starting LBNL BeStMan SRM server Configuration file is /usr/local/BeStMan_VDT_1.10.1/bestman/conf/ bestman.rc ## reading configuration file: /usr/local/BeStMan_VDT_1.10.1/bestman/ conf/bestman.rc.......local file system will be accessed through srm server. Assigning log file to be: /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/ bestman/logs/event.srm.log !Warning:Failed to create log file: /usr/local/BeStMan_VDT_1.10.1/vdt- app-data/bestman/logs/event.srm.log for events. Please make sure path exists and has write permission for SRM. ========= Good bye! ========= ### 2008-08-04 18:51:22 vdt-control(clean_up) all done Alan |
||||||||||||||
| # | Mon Aug 04 19:02:49 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||||
It seems that it might be running under daemon rather than globus... would you check this: head -10 /usr/local/BeStMan_VDT_1.10.1/bestman/sbin/SXXbestman it should show "SRMOWNER=globus" -- Alex asim at lbl dot gov On 8/4/08 4:55 PM, Alan Sill wrote: > > On Aug 4, 2008, at 6:42 PM, Alex Sim wrote: > >> So you're running bestman under "globus" account... >>> can you see this file: >> ls -al /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs/ >> and see who owns the directory/files? > On munin (which works): > > [root@munin ~]# cd /usr/local/grid/vdt-app-data/bestman > [root@munin bestman]# ls -al logs > total 4288 > drwxr-xr-x 2 globus tigre 4096 Jan 24 2008 . > drwxr-xr-x 3 root root 4096 Jan 24 2008 .. > -rw-r--r-- 1 globus tigre 1080072 Aug 4 11:08 00000000.jdb > -rw-r--r-- 1 globus tigre 3291605 Aug 4 11:08 event.srm.log > -rw-r--r-- 1 globus tigre 0 Jan 24 2008 je.lck > > On sigmorgh (which should be set up identically, but does nto work): > > [root@sigmorgh BeStMan_VDT_1.10.1]# cd vdt-app-data/bestman/ > [root@sigmorgh bestman]# ls -al logs > total 8 > drwxr-xr-x 2 globus tigre 4096 Aug 4 18:31 . > drwxr-xr-x 4 root root 4096 Jul 3 12:19 .. > > Just to be sure, I redid the configuration the way I had it set up > before once again, with SRM owned by globus and other parameters > adjusted, and started bestman again: > > [root@sigmorgh BeStMan_VDT_1.10.1]# cd > /usr/local/BeStMan_VDT_1.10.1/bestman/setup/[root@sigmorgh setup]# > ./configure > --with-replica-storage-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/cache > --with-replica-storage-size=10211 > --with-srm-home=/usr/local/BeStMan_VDT_1.10.1/bestman > --with-srm-owner=globus > --with-cacert-path=/usr/local/BeStMan_VDT_1.10.1/globus/TRUSTED_CA > --with-certfile-path=/etc/grid-security/http/httpcert.pem > --with-keyfile-path=/etc/grid-security/http/httpkey.pem > --with-eventlog-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs > --with-cachelog-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs > --with-globus-tcp-port-range=40000,50000 --with-http-port=49080 > --with-https-port=49443 --enable-gums > --with-gums-url="https://gums.hpcc.ttu.edu:8443/gums/services/GUMSAuthorizationServicePort" > --with-gums-dn="/DC=org/DC=doegrids/OU=Services/CN=http/sigmorgh.hpcc.ttu.edu" > > checking for correct JAVA path... JAVA found > current java version is 1.5.014 > checking for JAVA version ( > 1.4.2_07)... ok > WARNING: GridMapFileName NOT defined > ## GUMS ENABLED > GridMapFileName=/usr/local/BeStMan_VDT_1.10.1/bestman/conf/grid-mapfile.empty > > > BeStMan configured... > logfile is ... bestman.0804081849.log > > installing BeStMan server, client and tester > configure: creating ./config.status > config.status: creating ../bin/srm-ping > config.status: creating ../bin/srm-copy > config.status: creating ../bin/srm-copy-status > config.status: creating ../bin/srm-dir > config.status: creating ../bin/srm-extendfilelifetime > config.status: creating ../bin/srm-ls > config.status: creating ../bin/srm-ls-status > config.status: creating ../bin/srm-mkdir > config.status: creating ../bin/srm-mv > config.status: creating ../bin/srm-permission-check > config.status: creating ../bin/srm-permission-get > config.status: creating ../bin/srm-permission-set > config.status: creating ../bin/srm-putdone > config.status: creating ../bin/srm-release > config.status: creating ../bin/srm-req-abort > config.status: creating ../bin/srm-req-abortfiles > config.status: creating ../bin/srm-req-resume > config.status: creating ../bin/srm-req-summary > config.status: creating ../bin/srm-req-suspend > config.status: creating ../bin/srm-req-tokens > config.status: creating ../bin/srm-request > config.status: creating ../bin/srm-rm > config.status: creating ../bin/srm-rmdir > config.status: creating ../bin/srm-space > config.status: creating ../bin/srm-sp-change > config.status: creating ../bin/srm-sp-info > config.status: creating ../bin/srm-sp-purge > config.status: creating ../bin/srm-sp-release > config.status: creating ../bin/srm-sp-reserve > config.status: creating ../bin/srm-sp-reserve-status > config.status: creating ../bin/srm-sp-tokens > config.status: creating ../bin/srm-sp-update > config.status: creating ../bin/srm-tester > config.status: creating ../bin/srm-transferprotocols > config.status: creating ../bin/srm-util > config.status: creating ../conf/server-config.wsdd > config.status: creating ../sbin/bestman.server > config.status: creating ../sbin/SXXbestman > config.status: creating ../sbin/SXXbestman.personal > ## > ReplicaQualityStorageMB=[[10211]]path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/cache; > > NOTE: If you have more path to support, edit ../conf/bestman.rc > and add to ReplicaQualityStorageMB with > semi-colon ";" as seperator > e.g. > ReplicaQualityStorageMB=3100path=/tmp/cache;200path=/scratch/cache > NOTE: $OUTPUT_STORAGE_PATH or $OUTPUT_STORAGE_SIZE not defined > NOTE: If supported, use --with-output-storage-path=<DIRPATH> and > --with-output-storage-size=<INT> to define > NOTE: $CUSTODIAL_STORAGE_PATH or $CUSTODIAL_STORAGE_SIZE not defined > NOTE: If supported, use --with-custodial-storage-path=<DIRPATH> and > --with-custodial-storage-size=<INT> to define > ## MaxNumberOfUsers=100 > WARNING: $PUBLIC_SPACE_PORTION is not defined and> ## MaxNumberOfFileRequests=1000000 > ## Concurrency=40 > ## MaxConcurrentFileTransfer=10 > ## GridFTPNumStreams=2 > ## GridftpBufferSizeBytes=1048576 > ## DefaultFileSizeMB=500 > ## DefaultVolatileFileLifeTimeInSeconds=1800 > ## PublicTokenMaxFileLifetimeInSeconds=1800 > ## InactiveTxfTimeOutInSeconds=300 > PublicSpaceProportion will be 80 > Use --with-public-space-proportion=<INT> to define > WARNING: $PUBLIC_SPACE is not defined and > PublicSpaceProportion will be used as default > Use --with-public-space-size=<INT> to define > ## DefaultMBPerToken=1000 >> ## publicPort=49080 > ## securePort=49443 > NOTE: supportedProtocolList needs to be added in the conf/bestman.rc > : when different from the same hostname that BeStMan runs on > e.g. supportedProtocolList=gsiftp://myhost.domain.tld> e.g. > supportedProtocolList=gsiftp://myhost.domain.tld;gsiftp://host2.domain.tld > > ## > EventLogLocation=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs> ## > CacheLogLocation=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs> ## useBerkeleyDB=true > NOTE: $BERKELEYDB will be used as the internal management> Use --enable-berkeleydb to use berkeley db > Use --disable-berkeleydb not to use berkeley db > ## srmcacheKeywordOn=true > NOTE: $srmcache as keyword will be used as the internal cache management> Use --enable-srmcache-keyword to use srmcache as keyword > Use --disable-srmcache-keyword not to use srmcache as keyword > WARNING: $PROXY_FILE_PATH is not defined > Use --with-proxyfile-path=<INT> to define if desired > WARNING: Cert/Key will be used > ## CertFileName=/etc/grid-security/http/httpcert.pem > GUMS interface enabled> ## KeyFileName=/etc/grid-security/http/httpkey.pem > Grid-mapfile will not be used > ## > GUMSserviceURL=https://gums.hpcc.ttu.edu:8443/gums/services/GUMSAuthorizationServicePort > > ## > GUMSCurrHostDN=/DC=org/DC=doegrids/OU=Services/CN=http/sigmorgh.hpcc.ttu.edu > > ## > GridMapFileName=/usr/local/BeStMan_VDT_1.10.1/bestman/conf/grid-mapfile.empty > > ## FactoryID=server > NOTE: uploadQueueParameter will be used as the transfer queue management> ## uploadQueueParameter=40:10 > Use --enable-twoqueues to use uploadQueueParameter > Use --disable-twoqueues not to use uploadQueueParameter > ## accessFileSysViaGsiftp=false > NOTE: $GSIFTPFSM will not be used as the file management> Use --enable-gsiftpfsmng to use gsiftp > Use --disable-gsiftpfsmng not to use gsiftp > ## accessFileSysViaSudo=false > NOTE: $SUDOFSM will not be used as the file management> Use --enable-sudofsmng to use sudo > Use --disable-sudofsmng not to use sudo > ## noSudoOnLs=true > NOTE: $SUDOLS will not be used as the file management> Use --enable-sudols to use sudo for ls > Use --disable-sudols not to use sudo for ls > ## MaxMSSConnections=5 > WARNING: $PLUGIN_PATH is not defined> ## mssTimeOutSeconds=600000 > Use --with-plugin-path=<INT> to define > chmod: cannot access `../bin/g-urlcopy.sh': No such file or directory > > configuration complete > > It still does not work. It's as if the ownership I set up in the > above configuration command is being ignored somehow. Does anyone in > the VDT team have an idea as to what might be wrong? > > root@sigmorgh setup]# vdt-control --on bestman > enabling init service bestman... tail ok > [root@sigmorgh setup]# cd ../.. > [root@sigmorgh BeStMan_VDT_1.10.1]# tail vdt-install.log > ########################################### > Starting LBNL BeStMan SRM server > Configuration file is > /usr/local/BeStMan_VDT_1.10.1/bestman/conf/bestman.rc > ## reading configuration file: > /usr/local/BeStMan_VDT_1.10.1/bestman/conf/bestman.rc> .......local file system will be accessed through srm server. > Assigning log file to be: > /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs/event.srm.log > !Warning:Failed to create log file: > /usr/local/BeStMan_VDT_1.10.1/vdt-app-data/bestman/logs/event.srm.log > for events. Please make sure path exists and has write permission for > SRM. > ========= Good bye! ========= > ### 2008-08-04 18:51:22 vdt-control(clean_up) all done >> > > Alan > |
||||||||||||||
| # | Mon Aug 04 19:02:49 2008 | RT_System - Status changed from 'new' to 'open' | ||
| # | Mon Aug 04 19:07:43 2008 | Alan.Sill@ttu.edu - Correspondence added | [Reply] | |||||||||||
On Aug 4, 2008, at 7:00 PM, Alex Sim wrote: > would you check this: head -10 > /usr/local/BeStMan_VDT_1.10.1/bestman/sbin/SXXbestman > > it should show "SRMOWNER=globus" Yes, it does: [root@sigmorgh BeStMan_VDT_1.10.1]# head -10 /usr/local/ BeStMan_VDT_1.10.1/bestman/sbin/SXXbestman #!/bin/sh #SRM_HOME=/data/bestman/current #SRMOWNER=srm SRM_HOME=/usr/local/BeStMan_VDT_1.10.1/bestman SRMOWNER=globus ################# DO NOT MODIFY BELOW THIS LINE ####################### # unless you know what you are doing... but notice in the previous message, we can see that the configuration command I issued terminated in an error: WARNING: $PLUGIN_PATH is not defined Use --with-plugin-path=<INT> to define chmod: cannot access `../bin/g-urlcopy.sh': No such file or directory configuration complete Is this significant? Alan Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ==================================================================== |
||||||||||||||
| # | Mon Aug 04 19:12:49 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||||
That last line does not matter... no harm at all. can you start manually by "sbin/SXXbestman start" as root ? if not working, as globus "sbin/bestman.server". -- Alex asim at lbl dot gov On 8/4/08 5:02 PM, Alan Sill wrote: > > On Aug 4, 2008, at 7:00 PM, Alex Sim wrote: > >> would you check this: head -10 >>> /usr/local/BeStMan_VDT_1.10.1/bestman/sbin/SXXbestman >> >> it should show "SRMOWNER=globus" > Yes, it does: > > [root@sigmorgh BeStMan_VDT_1.10.1]# head -10 > /usr/local/BeStMan_VDT_1.10.1/bestman/sbin/SXXbestman > #!/bin/sh > #SRM_HOME=/data/bestman/current > #SRMOWNER=srm > SRM_HOME=/usr/local/BeStMan_VDT_1.10.1/bestman > SRMOWNER=globus > > ################# DO NOT MODIFY BELOW THIS LINE ####################### > # unless you know what you are doing> > ... but notice in the previous message, we can see that the > configuration command I issued terminated in an error: > > WARNING: $PLUGIN_PATH is not defined > Use --with-plugin-path=<INT> to define > chmod: cannot access `../bin/g-urlcopy.sh': No such file or directory > > configuration complete > > Is this significant? > > Alan > > > > Alan Sill, Ph.D > TIGRE Senior Scientist, High Performance Computing Center > Adjunct Professor of Physics > TTU > > ==================================================================== > : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : > : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : > ==================================================================== >> > |
||||||||||||||
| # | Mon Aug 04 19:42:49 2008 | Alan.Sill@ttu.edu - Correspondence added | [Reply] | |||||||||||
On Aug 4, 2008, at 7:12 PM, ASim@lbl.gov via RT wrote: > can you start manually by "sbin/SXXbestman start" as root ? Yes. This leads to the obvious check of what vdt-control is doing. I see. It seems the $VDT_LOCATION/post-install/bestman file has a hard-wired line saying "SRMOWNER=daemon" in it. This is the file that is copied to /etc/init/d when a "vdt-control --on bestman" is issued, and it does not obey the pure bestman configuration command that I issued. To deal with this, I changed the line in the post-install/bestman file to read: SRMOWNER=globus then stopped the above test bestman process (with the same comand ending with "stop" instead of "start"), and cycled everything on with vdt-control. It now starts and appears to work. For example, the logs are in the right place: [root@sigmorgh BeStMan_VDT_1.10.1]# ls -al vdt-app-data/bestman/logs/ total 20 drwxr-xr-x 2 globus tigre 4096 Aug 4 19:24 . drwxr-xr-x 4 root root 4096 Jul 3 12:19 .. -rw-r--r-- 1 globus tigre 7127 Aug 4 19:31 00000000.jdb -rw-r--r-- 1 globus tigre 2481 Aug 4 19:31 event.srm.log -rw-r--r-- 1 globus tigre 0 Aug 4 19:24 je.lck Note to the VDT team: What we need to avoid this kind of problem are two things: (1) a VDT-based configure command that can implement at least the following customizations in bestman setup, rather than having to issue the configure command manually and edit the post-install/bestman file as I have done:. (Note some of these are the defaults -- I got my configure command by looking through the vdt-install.log file for the one used bythe VDT, and adding the customizations that I needed to make it work for our setup at TTU.) ./configure --with-replica-storage-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app- data/bestman/cache \ --with-replica-storage-size=10211 \ --with-srm-home=/usr/local/BeStMan_VDT_1.10.1/bestman \ --with-srm-owner=globus \ --with-cacert-path=/usr/local/BeStMan_VDT_1.10.1/globus/TRUSTED_CA \ --with-certfile-path=/etc/grid-security/http/httpcert.pem \ --with-keyfile-path=/etc/grid-security/http/httpkey.pem \ --with-eventlog-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/ bestman/logs \ --with-cachelog-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/ bestman/logs \ --with-globus-tcp-port-range=40000,50000 \ --with-http-port=49080 --with-https-port=49443 \ --enable-gums \ --with-gums-url="https://gums.hpcc.ttu.edu:8443/gums/services/GUMSAuthorizationServicePort " \ --with-gums-dn="/DC=org/DC=doegrids/OU=Services/CN=http/ sigmorgh.hpcc.ttu.edu" (2) Also we need to make sure that the settings survive a VDT "pacman - update bestman" command, which they did not this time. Thanks, Alan |
||||||||||||||
| # | Mon Aug 04 21:25:05 2008 | roy - Ticket 3715: Merged into | ||
| # | Tue Aug 05 00:48:55 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||||
I will see what I can do at least to make backup or to preserve the existing conf file. I'll make more test tomorrow to sigmorgh. thank you -- Alex asim at lbl dot gov On 8/4/08 7:49 PM, Sill, Alan wrote: > > On Aug 4, 2008, at 7:12 PM, ASim@lbl.gov via RT wrote: > >> can you start manually by "sbin/SXXbestman start" as root ? >> Yes. This leads to the obvious check of what vdt-control is doing. > > I see. It seems the $VDT_LOCATION/post-install/bestman file has a > hard-wired line saying "SRMOWNER=daemon" in it. This is the file that > is copied to /etc/init/d when a "vdt-control --on bestman" is issued, > and it does not obey the pure bestman configuration command that I > issued. > > To deal with this, I changed the line in the post-install/bestman file > to read: > > SRMOWNER=globus > > then stopped the above test bestman process (with the same comand > ending with "stop" instead of "start"), and cycled everything on with > vdt-control. > > It now starts and appears to work. For example, the logs are in the > right place: > > [root@sigmorgh BeStMan_VDT_1.10.1]# ls -al vdt-app-data/bestman/logs/ > total 20 > drwxr-xr-x 2 globus tigre 4096 Aug 4 19:24 . > drwxr-xr-x 4 root root 4096 Jul 3 12:19 .. > -rw-r--r-- 1 globus tigre 7127 Aug 4 19:31 00000000.jdb > -rw-r--r-- 1 globus tigre 2481 Aug 4 19:31 event.srm.log > -rw-r--r-- 1 globus tigre 0 Aug 4 19:24 je.lck > > Note to the VDT team: What we need to avoid this kind of problem are > two things: > > (1) a VDT-based configure command that can implement at least the > following customizations in bestman setup, rather than having to issue > the configure command manually and edit the post-install/bestman file > as I have done:. (Note some of these are the defaults -- I got my > configure command by looking through the vdt-install.log file for the > one used bythe VDT, and adding the customizations that I needed to > make it work for our setup at TTU.) > > ./configure > --with-replica-storage-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app- > data/bestman/cache \ > --with-replica-storage-size=10211 \ > --with-srm-home=/usr/local/BeStMan_VDT_1.10.1/bestman \ > --with-srm-owner=globus \ > --with-cacert-path=/usr/local/BeStMan_VDT_1.10.1/globus/TRUSTED_CA \ > --with-certfile-path=/etc/grid-security/http/httpcert.pem \ > --with-keyfile-path=/etc/grid-security/http/httpkey.pem \ > --with-eventlog-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/ > bestman/logs \ > --with-cachelog-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/ > bestman/logs \ > --with-globus-tcp-port-range=40000,50000 \ > --with-http-port=49080 --with-https-port=49443 \ > --enable-gums \ > --with-gums-url="https://gums.hpcc.ttu.edu:8443/gums/services/GUMSAuthorizationServicePort > > " \ > --with-gums-dn="/DC=org/DC=doegrids/OU=Services/CN=http/ > sigmorgh.hpcc.ttu.edu" > > > (2) Also we need to make sure that the settings survive a VDT "pacman - > update bestman" command, which they did not this time. > > Thanks, > Alan > |
||||||||||||||
| # | Tue Aug 05 10:46:39 2008 | roy - Taken | ||
| # | Tue Aug 05 10:47:03 2008 | roy - Subject changed from 'Bestman update does not start, even after reconfiguration' to 'Preserve Bestman configuration' | ||
| # | Tue Aug 05 10:47:03 2008 | roy - Priority changed from (no value) to '3' | ||
| # | Tue Aug 05 10:47:03 2008 | roy - Fix scheduled CUR added | ||
| # | Tue Aug 05 10:49:42 2008 | roy - Correspondence added | [Reply] | |||||||||
On Aug 4, 2008, at 5:42 PM, Alan.Sill@ttu.edu via RT wrote: > (1) a VDT-based configure command that can implement at least the > following customizations in bestman setup, rather than having to issue > the configure command manually and edit the post-install/bestman file > as I have done:. (Note some of these are the defaults -- I got my > configure command by looking through the vdt-install.log file for the > one used bythe VDT, and adding the customizations that I needed to > make it work for our setup at TTU.) I'm slightly confused. I just ran the Bestman configure script by hand (which the VDT configure script does on your behalf) and it listens to the --with-srm-owner command properly and sets it in the init script properly. You can tell the VDT configure script what user to use (and to pass to the Bestman configure script) with --user. So I think that this option is okay. Am I missing something? > ./configure > --with-replica-storage-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app- > data/bestman/cache \ > --with-replica-storage-size=10211 \ > --with-srm-home=/usr/local/BeStMan_VDT_1.10.1/bestman \ > --with-srm-owner=globus \ > --with-cacert-path=/usr/local/BeStMan_VDT_1.10.1/globus/ > TRUSTED_CA \ > --with-certfile-path=/etc/grid-security/http/httpcert.pem \ > --with-keyfile-path=/etc/grid-security/http/httpkey.pem \ > --with-eventlog-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/ > bestman/logs \ > --with-cachelog-path=/usr/local/BeStMan_VDT_1.10.1/vdt-app-data/ > bestman/logs \ > --with-globus-tcp-port-range=40000,50000 \ > --with-http-port=49080 --with-https-port=49443 \ > --enable-gums \ > --with-gums-url="https://gums.hpcc.ttu.edu:8443/gums/services/GUMSAuthorizationServicePort > " \ > --with-gums-dn="/DC=org/DC=doegrids/OU=Services/CN=http/ > sigmorgh.hpcc.ttu.edu" My approach to configuring Bestman has been that the VDT makes a basic setup, which you can then edit as you need. Are you saying that's the wrong approach? I don't mind passing all of these parameters I guess, but I'm not sure what we're gaining. > (2) Also we need to make sure that the settings survive a VDT > "pacman - > update bestman" command, which they did not this time. Agreed. This is a fault in the VDT. I'm going to change the name of this ticket and try to implement it soon. My goal is to implement it for the next Bestman release, which I should get from Alex in the near future. -alain ----------------------------------------------------------------- Alain Roy vdt-support@opensciencegrid.org VDT Support http://vdt.cs.wisc.edu/support.html |
||||||||||||
| # | Tue Aug 05 11:29:40 2008 | Alan.Sill@ttu.edu - Correspondence added | [Reply] | |||||||||||
On Aug 5, 2008, at 10:49 AM, Alain Roy via RT wrote: > I'm slightly confused. I just ran the Bestman configure script by hand > (which the VDT configure script does on your behalf) and it listens to > the --with-srm-owner command properly and sets it in the init script > properly. Thanks for the observation. It did not change the post-install/ bestman script for me, so this did not survive a vdt-control --off and --on (in multiple trials), in my case. So either my installation is behaving differently, or the post-install/bestman file is not updated with the srm-owner (user) name if only the bestman configure script (and not the VDT one) is run. > You can tell the VDT configure script what user to use (and to pass to > the Bestman configure script) with --user. > > So I think that this option is okay. Am I missing something? I would be happy and would even prefer to use the VDT configure script. It would have to have options to set all of the other things I wanted to set (gums url and dn, globus tcp port range, for example) as well as the srm-owner (i.e., user); last time I checked it could not set all of these options. (Actually, it should not be necessary for there to be a command option to set the GUMS DN; instead BeStMan should be able to extract this from the certificate provided. Last time I checked on this issue, Alex and Junmin were going to look into simplifying the configuration by making such an internal change. It's not high priority, as long as the DN provided by the user is consistent.) Thanks for the other changes. Alan |
||||||||||||||
| # | Tue Aug 05 11:57:57 2008 | roy - Correspondence added | [Reply] | |||||||||
On Aug 5, 2008, at 9:29 AM, Alan.Sill@ttu.edu via RT wrote: > http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3714 > > On Aug 5, 2008, at 10:49 AM, Alain Roy via RT wrote: > >> I'm slightly confused. I just ran the Bestman configure script by >>> hand >> (which the VDT configure script does on your behalf) and it listens >> to >> the --with-srm-owner command properly and sets it in the init script >> properly. > Thanks for the observation. It did not change the post-install/ > bestman script for me, so this did not survive a vdt-control --off and > --on (in multiple trials), in my case. So either my installation is > behaving differently, or the post-install/bestman file is not updated > with the srm-owner (user) name if only the bestman configure script > (and not the VDT one) is run. Ah, maybe I see. Bestman's configure script creates the init script, but it's the VDT's configure script that moves it into the post- install directory. So if you re-run the configuration script by hand, it doesn't get updated. You should see the new version in bestman/sbin/ SXXbestman, I think. This is an argument for putting more arguments into the VDT's configuration script. Or perhaps an argument that you should be able to run Bestman's configure script, then tell the VDT's configure script to "do everything else". Probably we need a blend of both. -alain ----------------------------------------------------------------- Alain Roy vdt-support@opensciencegrid.org VDT Support http://vdt.cs.wisc.edu/support.html |
||||||||||||
| # | Thu Aug 28 12:05:40 2008 | roy - Given to kronenfe | ||
| # | Thu Aug 28 14:35:31 2008 | kronenfe - Correspondence added | [Reply] | |
|
Based on Alan's request, I am adding the following four options to the VDT's configure_bestman When the following behavior has been implemented in Bestman, I can remove the gums-dn option (if desired) On Tue Aug 05 11:29:40 2008, Alan.Sill@ttu.edu wrote: |
||||
| # | Thu Aug 28 15:09:35 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||||
Please keep the --gums-dn in case service cert (rather than host cert) is used. If not provided but gums enabled, we extract the dn from the bestman cert and use it. -- Alex asim at lbl dot gov On 8/28/08 12:35 PM, Scot Kronenfeld via RT wrote: > Based on Alan's request, I am adding the following four options to the VDT's > configure_bestman > > 1) --cache-size (passes --with-replica-storage-size) > This will be in megabytes, and the VDT will calculate a default if it is not > passed. > > 2) --enable-gums (passes --enable-gums) > 3) --gums-url (passes --with-gums-url) > 4) --gums-dn (passed --with-gums-dn) > These arguments will not be passed unless they are specified on the > commandline. > > When the following behavior has been implemented in Bestman, I can remove the > gums-dn option (if desired) > > On Tue Aug 05 11:29:40 2008, Alan.Sill@ttu.edu wrote: > >> (Actually, it should not be necessary for there to be a command option >>> to set the GUMS DN; instead BeStMan should be able to extract this >> from the certificate provided. Last time I checked on this issue, >> Alex and Junmin were going to look into simplifying the configuration >> by making such an internal change. It's not high priority, as long as >> the DN provided by the user is consistent.) >> > > |
||||||||||||||
| # | Thu Aug 28 16:05:55 2008 | kronenfe - Comments added | [Reply] | |||||||
Commit comment: Added four new command line options to configure_bestman that are passed on to the bestman configure script. Changed files: U vdt/branches/vdt-1.10.1-bestman-xrootd/Configure-Bestman/vdt/setup/configure_bestman To generate a diff: svn diff -c 7961 file:///p/vdt/workspace/svn |
||||||||||
| # | Thu Aug 28 16:40:50 2008 | kronenfe - Comments added | [Reply] | |||||||
Commit comment: Added POD and usage for new options. Minor fix in calculate_cache_size subroutine. Changed files: U vdt/branches/vdt-1.10.1-bestman-xrootd/Configure-Bestman/vdt/setup/configure_bestman To generate a diff: svn diff -c 7962 file:///p/vdt/workspace/svn |
||||||||||
| # | Thu Aug 28 17:04:11 2008 | kronenfe - Correspondence added | [Reply] | |
|
Alex, For preserving the Bestman configuration across updates, is it sufficient to preserve the conf directory? Are there any other directories/files that should be preserved as well?
Thanks, |
||||
| # | Thu Aug 28 17:27:44 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||||
Hi Scot, you mean for only the updates on the previous installation/configuration? conf directory can be preserved definitely. sbin directory is hardly touched and can be preserved as long as installation directory is the same. It's probably sufficient most of the time to update lib directory only (not even recursively), and even configure is not necessary as long as the installation directory is the same. Sometimes, all directories get involved in the changes that update is not meaningful, but still conf directory can be preserved. -- Alex asim at lbl dot gov On 8/28/08 3:04 PM, Scot Kronenfeld via RT wrote: > Alex, > > For preserving the Bestman configuration across updates, is it sufficient to > preserve the conf directory? > > Are there any other directories/files that should be preserved as well? > > Thanks, > scot > > > |
||||||||||||||
| # | Fri Aug 29 09:20:21 2008 | kronenfe - Correspondence added | [Reply] | |||||||||
Alex, It's actually easier (and probably safer) to preserve as little as possible during updates. When a user runs "pacman -update Bestman", the entire bestman directory tree gets removed, and then the new one gets installed. So I'm looking for the smallest set of files/directories that I can preserve across Bestman versions to prevent an admin from losing any custom configuration. From your response, it sounds like the conf directory should be sufficient. This also means that in the future, if a bestman configuration file changes such that there are new, better defaults, or the old conf file format is not compatible with the new version of the software, we will need to take some steps during an upgrade to fix this problem. Was that more clear than my last email? Maybe I just misunderstood your response... Thanks, scot On Thu, Aug 28, 2008 at 5:27 PM, ASim@lbl.gov via RT <vdt-support@opensciencegrid.org> wrote: > Hi Scot, > > you mean for only the updates on the previous installation/configuration? > conf directory can be preserved definitely. > sbin directory is hardly touched and can be preserved as long as > installation directory is the same. It's probably sufficient most of > the time to update lib directory only (not even recursively), and even > configure is not necessary as long as the installation directory is the > same. Sometimes, all directories get involved in the changes that > update is not meaningful, but still conf directory can be preserved. > > -- Alex > asim at lbl dot gov > > > > On 8/28/08 3:04 PM, Scot Kronenfeld via RT wrote: >> Alex, >>> >> For preserving the Bestman configuration across updates, is it sufficient to >> preserve the conf directory? >> >> Are there any other directories/files that should be preserved as well? >> >> Thanks, >> scot >> >> >> > > -- > View ticket at <http://crt.cs.wisc.edu/Ticket/Display.html?user=guest&pass=guest&id=3714> > VDT Support: vdt-support@opensciencegrid.org > |
||||||||||||
| # | Fri Aug 29 10:00:22 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||||
Hi Scot, that sounds good. conf is enough. Actually as a caution, our configure makes a bestman.rc backup with a time-stamp in the setup directory if exists already. -- Alex asim at lbl dot gov On 8/29/08 7:20 AM, Scot Kronenfeld via RT wrote: > Alex, > It's actually easier (and probably safer) to preserve as little as > possible during updates. When a user runs "pacman -update Bestman", > the entire bestman directory tree gets removed, and then the new one > gets installed. > > So I'm looking for the smallest set of files/directories that I can > preserve across Bestman versions to prevent an admin from losing any > custom configuration. From your response, it sounds like the conf > directory should be sufficient. > > This also means that in the future, if a bestman configuration file > changes such that there are new, better defaults, or the old conf file > format is not compatible with the new version of the software, we will > need to take some steps during an upgrade to fix this problem. > > Was that more clear than my last email? Maybe I just misunderstood > your response... > > Thanks, > scot > > On Thu, Aug 28, 2008 at 5:27 PM, ASim@lbl.gov via RT > <vdt-support@opensciencegrid.org> wrote: > >> Hi Scot, >>> >> you mean for only the updates on the previous installation/configuration? >> conf directory can be preserved definitely. >> sbin directory is hardly touched and can be preserved as long as >> installation directory is the same. It's probably sufficient most of >> the time to update lib directory only (not even recursively), and even >> configure is not necessary as long as the installation directory is the >> same. Sometimes, all directories get involved in the changes that >> update is not meaningful, but still conf directory can be preserved. >> >> -- Alex >> asim at lbl dot gov >> >> >> >> On 8/28/08 3:04 PM, Scot Kronenfeld via RT wrote: >> >>> Alex, >> -->>> >>> For preserving the Bestman configuration across updates, is it sufficient to >>> preserve the conf directory? >>> >>> Are there any other directories/files that should be preserved as well? >>> >>> Thanks, >>> scot >>> >>> >>> >>> >> View ticket at <http://crt.cs.wisc.edu/Ticket/Display.html?user=guest&pass=guest&id=3714> >> VDT Support: vdt-support@opensciencegrid.org >> >> > > |
||||||||||||||
| # | Fri Aug 29 10:03:50 2008 | roy - Correspondence added | [Reply] | |||||||||
I think the process here might be more difficult than I realized. Background for Alex: Right now when we update Bestman, we lose all of the configuration that the user might have tweaked. We erase the entire Bestman directory, download a new one, unpack it, and re-run configure. As more people adopt Bestman, we don't want to lose all of the configuration they've done each time we update Bestman. That is unpleasant. Background for Scot: When we install Bestman, it's configure script does more than just write a configuration file, it also writes wrapper scripts for Bestman commands. In some cases, the configuration affects the construction of these wrapper scripts. For instance, you can specify the location of Java when you run Bestman's configure script, and that will be hardcoded into the Bestman wrapper scripts. This means that to really do an update properly, we must re-run the configure script. Who knows, maybe the process of creating these wrapper scripts has been updated, or we've just switched to a new version of Java? So the question is, how should we best preserve the Bestman configuration? We don't want to lose the important configuration that the user has done, but we want to get all the benefits of the new update? Alex, any guidance you can provide on this will be invaluable. Thanks, -alain |
||||||||||||
| # | Fri Aug 29 10:23:50 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||||
I'm not that familiar with automation... but Some people actually does the following manually: copy over conf directory in a different location, get new version, unpack and configure, mv the newly created conf directory as conf.old, and make a link to preserved conf directory. Currently the package creates "bestman" directory. We can add version number to it so that bestman-2.2.1.1/ can be created and the rest procedure as before. If VDT can create a "bestman" directory as a post-processing vdt configure with the copy of the conf directory if not exists yet, you can preserve the configuration from the first time. However you need to make a link back to the bestman/conf from bestman-2.2.1.1/conf. Previous bestman-2.2.1.1/conf would be mv to conf.old or something... it's a bit complicated, but it's one of the ways and it'll work... So far, we had all configuration parameters in bestman.rc compatible and we'll try to in the future. So, if we introduce something new in the future, the preserved one will still work.. -- Alex asim at lbl dot gov On 8/29/08 8:03 AM, Alain Roy via RT wrote: > I think the process here might be more difficult than I realized. > > Background for Alex: Right now when we update Bestman, we lose all of > the configuration that the user might have tweaked. We erase the > entire Bestman directory, download a new one, unpack it, and re-run > configure. As more people adopt Bestman, we don't want to lose all of > the configuration they've done each time we update Bestman. That is > unpleasant. > > Background for Scot: When we install Bestman, it's configure script > does more than just write a configuration file, it also writes wrapper > scripts for Bestman commands. In some cases, the configuration affects > the construction of these wrapper scripts. For instance, you can > specify the location of Java when you run Bestman's configure script, > and that will be hardcoded into the Bestman wrapper scripts. This > means that to really do an update properly, we must re-run the > configure script. Who knows, maybe the process of creating these > wrapper scripts has been updated, or we've just switched to a new > version of Java? > > So the question is, how should we best preserve the Bestman > configuration? We don't want to lose the important configuration that > the user has done, but we want to get all the benefits of the new > update? > > Alex, any guidance you can provide on this will be invaluable. > > Thanks, > -alain > > > |
||||||||||||||
| # | Fri Aug 29 10:48:51 2008 | roy - Correspondence added | [Reply] | |||||||||
On Aug 29, 2008, at 8:23 AM, ASim@lbl.gov via RT wrote: > http://crt.cs.wisc.edu/Ticket/Display.html?id=3714 > > I'm not that familiar with automation... but > Some people actually does the following manually: > copy over conf directory in a different location, get new version, > unpack and configure, mv the newly created conf directory as conf.old, > and make a link to preserved conf directory. Thanks. We might be able to do the equivalent of that. > Currently the package creates "bestman" directory. We can add version > number to it so that bestman-2.2.1.1/ can be created and the rest > procedure as before. Thanks for the offer, but let us think about it a bit first. > So far, we had all configuration parameters in bestman.rc compatible > and > we'll try to in the future. So, if we introduce something new in the > future, the preserved one will still work.. That's really good to know! Perhaps the most important thing to know is if a new version adds new configuration variables that are important enough that we want to consider adding them to a configuration that we preserved. Thanks, -alain |
||||||||||||
| # | Fri Aug 29 11:43:50 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||||
>> Currently the package creates "bestman" directory. We can add version >>> number to it so that bestman-2.2.1.1/ can be created and the rest >> procedure as before. >> > Thanks for the offer, but let us think about it a bit first. > if you'd like the appended version number, please let us know. it's not that hard for us. > >> So far, we had all configuration parameters in bestman.rc compatible >>> and >> we'll try to in the future. So, if we introduce something new in the >> future, the preserved one will still work.. >> > That's really good to know! Perhaps the most important thing to know > is if a new version adds new configuration variables that are > important enough that we want to consider adding them to a > configuration that we preserved. > if something must be added in the future, you can just insert at the end of the existing conf file. we'll let you know if that comes.... thanks a lot --Alex |
||||||||||||||
| # | Fri Aug 29 15:50:06 2008 | kronenfe - Correspondence added | [Reply] | |
|
Alex, Just to confirm, before I finish implementing this change...is it safe to preserve *all* the files in the conf directory across updates, including server-config.wsdd? Thanks, |
||||
| # | Fri Aug 29 16:00:22 2008 | ASim@lbl.gov - Correspondence added | [Reply] | |||||||||||
Yes! when there are changes required, we'll let you know. hopefully it won't happen. thanks -- Alex asim at lbl dot gov On 8/29/08 1:50 PM, Scot Kronenfeld via RT wrote: > Alex, > > Just to confirm, before I finish implementing this change...is it safe to > preserve *all* the files in the conf directory across updates, including > server-config.wsdd? > > Thanks, > scot > > > |
||||||||||||||
| # | Fri Aug 29 16:57:01 2008 | kronenfe - Comments added | [Reply] | |||||||
Commit comment: Preserve Bestman config across lettered updates. There is a placeholder for preserving across major updates. Changed files: U vdt/branches/vdt-1.10.1-bestman-xrootd/Configure-Bestman/vdt/setup/configure_bestman To generate a diff: svn diff -c 7973 file:///p/vdt/workspace/svn |
||||||||||
| # | Tue Sep 02 14:49:07 2008 | kronenfe - Comments added | [Reply] | |||||||
Commit comment: When configure_bestman invokes Besman's configure script, it creates some files. Those are now added to the filelist so that they are uninstalled properly. Changed files: U vdt/branches/vdt-1.10.1-bestman-xrootd/Configure-Bestman/vdt/setup/configure_bestman To generate a diff: svn diff -c 7975 file:///p/vdt/workspace/svn |
||||||||||
| # | Tue Sep 02 15:04:34 2008 | kronenfe - Comments added | [Reply] | |
|
This work is finished. These changes will be released concurrent with the next version of Bestman. |
||||
| # | Tue Sep 02 15:04:34 2008 | kronenfe - Status changed from 'open' to 'resolved' | ||
Time to display: 4.287029
»|« RT 3.8.2 Copyright 1996-2008 Best Practical Solutions, LLC.
