Justin Mason writes:
> Joe Schaefer writes:
> > Theo Van Dinter <[EMAIL PROTECTED]> writes:
> > > So it appears someone has messed up the SVN install on the zone.  This is
> > > breaking the SpamAssassin zone's nightly cronjobs since "svn" upgraded the
> > > working copies to 1.4, and then the 1.1.4 binaries can't use them. :(
> 
> Is this why the buildbots all started failing?  I assumed that was another
> certificate change, based on the logs.  (This is better news, since svn
> 1.4 means we get some good new SVN features I was looking for. ;)

No, it was still a (possibly related?) cert change that's breaking the cron
stuff:

http://buildbot.spamassassin.org:8010/t-solaris-10/builds/97/step-svn/0

  /opt/subversion-current/bin/svn checkout --revision HEAD --non-interactive 
http://svn.apache.org/repos/asf/spamassassin/trunk build
  in dir /home/buildbot/slaves/zone-sol10/t-solaris-10 (timeout 1200 secs)
  watching logfiles {}
  argv: ['/opt/subversion-current/bin/svn', 'checkout', '--revision', 'HEAD', 
'--non-interactive', 'http://svn.apache.org/repos/asf/spamassassin/trunk', 
'build']
  A    build/ldap
  A    build/ldap/sa_test.ldif
  [etc. other files omitted]
  Fetching external item into 'build/rulesrc'
  svn: PROPFIND request failed on '/repos/asf/spamassassin/rules/trunk'
  svn: PROPFIND of '/repos/asf/spamassassin/rules/trunk': Server certificate 
verification failed: issuer is not trusted (https://svn.apache.org)
  program finished with exit code 1

That's with /opt/subversion-current/bin in the PATH.


Wierdly, just su'ing to the 3 different automated subsystems' users and doing
an "svn up" didn't help; it didn't seem to cache the auth settings anymore, as
it did with svn 1.1.x.  So I copied my own auth data into each one's
.subversion dir, and that works.  For future reference, here's how it's done:


  cd ~ ; tar cf - .subversion/auth | ( cd ~automc ; sudo tar xfp - )
  sudo chown -R automc .subversion/auth

  cd ~ ; tar cf - .subversion/auth | ( cd ~bbmass ; sudo tar xfp - )
  sudo chown -R bbmass .subversion/auth

  cd ~ ; tar cf - .subversion/auth | ( cd ~buildbot ; sudo tar xfp - )
  sudo chown -R buildbot .subversion/auth

annoying.

BTW I presume the cert was changed legitimately, and isn't a MITM attacker,
right? Nobody's mentioned it yet ;)

--j.


> > Can you change you PATH to use /opt/subversion-1.4.3/bin instead
> > of /opt/subversion-1.1.4/bin ?
> 
> This should be possible, but will take some work... there are a lot of
> independent scripts/cron jobs that use SVN. :(
> 
> A common old Solaris pattern was to maintain e.g. /opt/subversion as a
> link to /opt/subversion-1.X.Y , and update *that* on upgrades to avoid
> this problem.  It might be worth doing that on /opt.  (update:) ah,
> I see it: /opt/subversion-current.  Is it safe to use that?
> 
> In the meantime, SpamAssassin devs: I'll institute a global "envs" file
> that sets the PATH appropriately for all our scripts and user logins on
> our zone.  (I'll put it in /etc/profile if we have write perms on that.)
> 
> Also, it may be worth reverting the change to
> /opt/subversion-1.1.4/bin/svn :
> 
> lrwxrwxrwx   1 1327     other         29 Feb 25 08:16 
> /opt/subversion-1.1.4/bin/svn -> /opt/subversion-1.4.3/bin/svn*
> 
> that still seems odd, as Theo noted.
> 
> --j.

Reply via email to