Re: [Savannah-hackers-public] cvs migration status
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 $USER@$(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 * * * *rootsv_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. Bob
Re: [Savannah-hackers-public] cvs migration status
> On Dec 16, 2016, at 15:54, Bob Proulx wrote: >> >> On the other hand, acco...@savannah.gnu.org seems to redirect to >> the registered email; not sure what version we really want. > > Thank you for reporting this. It pointed me to the real problem. > Which I think I have fixed now. Thanks Bob! Is it something that we can check before migrating the other vcs'es ? One thing I'll check is any links/hooks to scripts in /usr/local/bin . Also, I changed a small settings in viewvc based on this: https://savannah.gnu.org/support/?109205 -assaf
Re: [Savannah-hackers-public] cvs migration status
Ineiev wrote: > Ineiev wrote: > > I see; now they look like from acco...@savannah.gnu.org, they used > > to be from the registered email (ine...@gnu.org in my case). > > On the other hand, acco...@savannah.gnu.org seems to redirect to > the registered email; not sure what version we really want. Thank you for reporting this. It pointed me to the real problem. Which I think I have fixed now. Email from vcs/vcs0 by Unix default would come from the $user@savannah address but that isn't desirable and isn't how it was previously set up. To avoid creating email from $u...@savannah.gnu.org there is a map created mapping every user address from their Savannah login name to their registered email address. That mapping was alive and active on vcs but had not been set up on vcs0 yet. My bad. I knew about this but had missed setting this up on the new vcs0. I set it up on vcs0 now. That should handle this problem. It was the reason the most recent email from vcs0 came with the unexpected email address of the raw local system name different from the mapped name previously used on vcs. Fixed now. Bob
Re: [Savannah-hackers-public] cvs migration status
On Fri, Dec 16, 2016 at 08:11:52AM -0500, Ineiev wrote: > > I see; now they look like from acco...@savannah.gnu.org, they used > to be from the registered email (ine...@gnu.org in my case). On the other hand, acco...@savannah.gnu.org seems to redirect to the registered email; not sure what version we really want. signature.asc Description: Digital signature
Re: [Savannah-hackers-public] cvs migration status
On Fri, Dec 16, 2016 at 03:18:16AM -0700, Bob Proulx wrote: > Ineiev wrote: > > It looks like commit notifications don't come to www-comm...@gnu.org. > > I saw many messages from new senders to www-commits this night that > were in the hold queue. I approved them and sent them on. I see; now they look like from acco...@savannah.gnu.org, they used to be from the registered email (ine...@gnu.org in my case). signature.asc Description: Digital signature
Re: [Savannah-hackers-public] cvs migration status
Ineiev wrote: > It looks like commit notifications don't come to www-comm...@gnu.org. I saw many messages from new senders to www-commits this night that were in the hold queue. I approved them and sent them on. They were held only because it was a new sender. The initial contact from a new address is always held for human review. If not that then this might be the problem Karl found. http://lists.gnu.org/archive/html/savannah-users/2016-12/msg6.html But if the messages have shown up there now then it was the new sender address. Now that it has been seen it won't be held further and subsequent messages will be sent through without moderation delay. Bob
Re: [Savannah-hackers-public] cvs migration status
Hello, On Thu, Dec 15, 2016 at 10:40:37PM -0500, Assaf Gordon wrote: > > If you encounter any cvs related issues with savannah, > or with web pages not being updated - please email us at > savannah-hackers-public@gnu.org . It looks like commit notifications don't come to www-comm...@gnu.org.
[Savannah-hackers-public] cvs migration status
On behalf of the Savannah Hackers team... Savannah's cvs service has been moved onto the new server. All should be working normally but at the new IP address of the new server. This includes projects using cvs for source code, and all web cvs repositories for www.gnu.org/www.nongnu.org . If you encounter any cvs related issues with savannah, or with web pages not being updated - please email us at savannah-hackers-public@gnu.org . The affected services are: anonymous read-only cvs checkouts, both cvs and webcvs. Example: cvs -d:pserver:anonym...@cvs.savannah.gnu.org:/sources/ co cvs -d:pserver:anonym...@cvs.savannah.gnu.org:/web/ co SSH access (read-only for all savannah users, write access for project members): cvs -z3 -d:ext:@cvs.savannah.gnu.org:/sources/ co cvs -z3 -d:ext:@cvs.savannah.gnu.org:/web/ co Web browsing: https://cvs.savannah.gnu.org/viewvc/ https://web.cvs.savannah.gnu.org/viewvc/ Bob, Assaf, and Karl