Hi
to add to the discussion
I never run configure_node site.cfg CE_torque (WN_torque)
I have done the torque/maui/pbs config manually once
and will "never more!!" touch it, not even when there are upgrades
this has proven good since probably lcg 2.3.1, my site continues
to work well (I mean when it doesn't its not because of the lrms).
so I would advice, take time to configure properly the local
lrms, and from then on don't touch it (this mean dont run the yaim function
config torque since its config its hardwired)
cheers
Mario
Quoting Steve Traylen <[log in to unmask]>:
> On Thu, Aug 11, 2005 at 04:07:05PM +0200 or thereabouts, Ron Trompert
> wrote:
> >
> > Hi,
> >
> > In config_gip there is a piece of code:
> >
> > dn: GlueVOViewLocalID=`echo $VO | tr [:upper:]
> > [:lower:]`,GlueCEUniqueID=${CE_HOST}:2119/jobmanager-${JOB_MANAGER}-${QU
> > EUE},mds-vo-name=local,o=grid
> > GlueCEAccessControlBaseRule: VO:`echo $VO | tr [:upper:] [:lower:]`
> > GlueCEInfoDefaultSE: `eval echo '$'VO_${VO}_DEFAULT_SE`
> > GlueCEInfoApplicationDir: `eval echo '$'VO_${VO}_SW_DIR`
> > GlueCEInfoDataDir: `eval echo '$'VO_${VO}_STORAGE_DIR`
> > GlueChunkKey:
> > GlueCEUniqueID=${CE_HOST}:2119/jobmanager-${JOB_MANAGER}-${QUEUE}
> >
> > which is looped over the supported VOs and queues.
> >
> > This implies that a site running a separate queue for each VO will endup
> > with entries in their information system with dn's like:
> >
> > dn:
> > GlueVOViewLocalID=alice,GlueCEUniqueID=ce.somedomain:2119/jobmanager-pbs
> > -sixt,mds-vo-name=local,o=grid
> >
> > which doesn't make any sense I think.
> >
> > I think that if you run a queue per VO you should move this piece of
> > code out of the VO loop into the QUEUE loop and replace ${VO} by
> > ${QUEUE}. Am I right?
>
> Just noticed that myself, I believe you are.
>
> >
> > Cheers,
> >
> > Ron
> >
> >
> > > -----Original Message-----
> > > From: LHC Computer Grid - Rollout
> > > [mailto:[log in to unmask]] On Behalf Of Ron Trompert
> > > Sent: donderdag 11 augustus 2005 13:24
> > > To: [log in to unmask]
> > > Subject: Re: [LCG-ROLLOUT] Can't contact LDAP server
> > >
> > > It is a tcp_wrapper problem.
> > >
> > > The line:
> > >
> > > slapd: ALL
> > >
> > > in hosts.allow does the trick. I wonder why didn't I have trouble with
> > > this before.
> > >
> > > Cheers,
> > >
> > > Ron
> > >
> > > > -----Original Message-----
> > > > From: LHC Computer Grid - Rollout
> > > > [mailto:[log in to unmask]] On Behalf Of Ron Trompert
> > > > Sent: donderdag 11 augustus 2005 9:38
> > > > To: [log in to unmask]
> > > > Subject: Re: [LCG-ROLLOUT] Can't contact LDAP server
> > > >
> > > > It looks like a permission problem.
> > > >
> > > > I have started up slapd -d 255 on port 2171 by hand:
> > > >
> > > > slapd -d 255 -f /opt/bdii/var/2171/bdii-slapd.conf -h
> > > > ldap://localhost:2171 -u edguser
> > > >
> > > > Doing an ldapsearch on this server I get:
> > > >
> > > > fd=8 host access from unknown (127.0.0.1) denied
> > > >
> > > > Cheers,
> > > >
> > > > Ron
> > > >
> > > > > -----Original Message-----
> > > > > From: LHC Computer Grid - Rollout
> > > > > [mailto:[log in to unmask]] On Behalf Of
> > > > > Maarten Litmaath, CERN
> > > > > Sent: dinsdag 9 augustus 2005 23:12
> > > > > To: [log in to unmask]
> > > > > Subject: Re: [LCG-ROLLOUT] Can't contact LDAP server
> > > > >
> > > > > On Tue, 9 Aug 2005, Sajjad Asghar wrote:
> > > > >
> > > > > > Hi Maarten and Dani
> > > > > >
> > > > > > Both of the method did not work. I am facing same problem
> > > > >
> > > > > Is your BDII actually listening on the external interface?
> > > > > What does this command report:
> > > > >
> > > > > netstat -an | grep -w LISTEN
> > > > >
> > > > > Please send me these configuration files:
> > > > >
> > > > > /opt/bdii/etc/bdii.conf
> > > > > /opt/bdii/etc/bdii-update.conf
> > > > >
> > > > > Also the output of this command:
> > > > >
> > > > > ps auxwww
> > > > >
> > > > > Finally, check if the following command reports no rules:
> > > > >
> > > > > iptables -t mangle -L
> > > > >
> > > >
> > >
>
> --
> Steve Traylen
> [log in to unmask]
> http://www.gridpp.ac.uk/
>
|