[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] cvs migration status

From: Bob Proulx
Subject: Re: [Savannah-hackers-public] cvs migration status
Date: Fri, 16 Dec 2016 18:56:47 -0700
User-agent: NeoMutt/20161126 (1.7.1)

Assaf Gordon wrote:
> Is it something that we can check before migrating the other vcs'es ?

The other obvious one is download0.  The only three front facing
systems are frontend, vcs, and download.

* vcs/vcs0 sends email due to commit emails.  These need to not use
the local address@hidden(hostname) address as that would mean that replies
would go there.  So they get mapped.  Presently mapped to the email
address registered with that account.  I think that is okay but I
contemplate that for vcs systems such as git that include an email
address that perhaps it should be the included email address.  However
systems such as svn don't have an equivalent so the registered email
address is all that is available.

* frontend sends email due to password recovery and ticket CC
information.  In both of those cases the from address is the web
server from address and therefore the user's address doesn't come into
play in the action.  If it did then it would be a problem there too.

* download.  I am most unfamiliar with download.  Does it send email?
I go look in the email logs on download and I see only the email
associated with administrivia of the server, exactly one a day, and
nothing to other humans ever.  So I conclude that no there is no mail
function out of download.

And therefore it is only vcs0 so far that seems to need this.  Since
vcs0 sends email from commit messages.

Since the files still reside on vcs at the present time any cronjobs
that modify the repositories still need to run on vcs not vcs0.  Going
forward with the present split of functionality that needs to
continue.  Cronjobs that modify the repository need to run on the
system with the repository, which is vcs.  Cronjobs that modify the
system need to run on the client system, which is vcs0.

> One thing I'll check is any links/hooks to scripts in /usr/local/bin .

On vcs0 I redirected from /usr/local/bin that so that it is using
/opt/savannah/bin/sv_aliases for the cronjob.

On the related chain is sv_groups.  It is one of the few scripts that
actually has a comment saying something about what it does.
Unfortunately the description still leaves me wondering what it does.

  # Replicate groups and group repositories on the system

  ## This script should be used via a cronjob to update the system
  ## by reading the database about groups.
  ## It will add create/update a group for each group. 
  ## It will also create a download area, a web area, and a cvs repository 
  ## if in the database the fields dir_cvs dir_homepage and dir_download 
  ## contains the string %PROJECT
  ## (if they don't, it means that no group specific directories like that
  ## are desired).
  ## (the web area can be also a cvs repository 
  ## WARNING: sv_groups should run before sv_users.

This runs every half hour on vcs.

  */30 * * * *    root    sv_groups --cron --only-download --only-arch

But on the surface I think it may be obsolete now.  Looking at the
sv_users script it mentions I think that one is obsolete as it was
trying to update ssh keys in user's home directories and that is all
handled by database access now.  Therefore I wonder about sv_groups.
At the least I think it is not needed on vcs0.

At some point in the future we need to review sv_groups for relevance.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]