mainSavannah Administration - Support: sr #110149, No access right to CVS website repo

 
 

sr #110149: No access right to CVS website repo

Submitter:  Eric L. <ericzolf>
Submitted:  Sat 30 Nov 2019 09:24:59 PM UTC
   
 
Category:  Webpages repositories Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  None
Operating System:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 06 Dec 2019 07:03:44 PM UTC, comment #8: 

I am very happy to hear that you were able to make the commit you wanted to make.  So will go ahead and close this ticket.  Please do report other problems as you encounter them.  In this case I think it "feels" like it must be related to the user account database connection failures that has sometimes been occurring when things have been under stress.  Can't say for certain.  But feels like it.  We have been trying to strengthen the resiliency in the face of system stress but there is still a way to go yet.

Bob Proulx <rwp>
Site Administrator
Thu 05 Dec 2019 08:28:58 PM UTC, comment #7: 

The issue is gone, so it seems indeed to have been due to the DDoS attacks or similar (which was indeed more important to address than my small issue). Thanks for your help, Eric (and good luck with addressing the DDoS)

PS: I can't seem to be able to close my own ticket, feel free to close it in due time.

Eric L. <ericzolf>
Thu 05 Dec 2019 08:13:54 PM UTC, comment #6: 

Sorry but I have been consumed by trying to mitigate the ongoing DDoS attack which has been urgent.  And as I understand it the pending upload isn't urgent but is just to try to disable the web information which seemed like something that could wait.  Please correct me if I am wrong about it.

There are actually a couple of different things that we can do to debug the problem.  What I tend to do is to make a snapshot of the repository files so I can experiment and restore them afterward.  Then add myself to the project.  Then try to make some sample commit myself.  If that recreates the problem then I have a reproducing recipe that is all self-contained to things I control.  If not then must do something else.

Meeting at a time on IRC to coordinate also works well for me.  Or a phone call.  But probably not possible due to my schedule for at least a little bit longer.

Since all commits are always over ssh there is no issue with needing new ports open in the firewall.  They are already all through the ssh gatekeeper.  We do not allow pserver with passwords here.

One persistent and annoying problem with the DDoS active is that the database connection from the frontend systems to the backend database sometimes gets starved.  Savannah keeps all user account information in a MySQL/MariaDB database.  If that fails then user account information is missing and the user, though actually valid, will have the appearance of being 'nobody'.  I have increased the max connection configuration between the frontends and the db system hugely but eventually other system limits hit and we still see db connection failures.  Therefore it is also likely that this permission problem is one of a database connection failure.  (And when this happens the NFS attribute cache is persistent for some time before it times out and is refreshed.  The NFS attribute cache problem is on the git et al side of things though and not on the cvs side as cvs is entirely standalone with local files.  So that is not the problem with cvs.)

Bob Proulx <rwp>
Site Administrator
Thu 05 Dec 2019 08:37:39 AM UTC, comment #5: 


comment #4:

> I'm open for any suggestion but how do you want to practically do this? Meet at a given time and date on IRC and coordinate from there?


Yes, that would be one possibility.

The other way that immediately comes to my mind would be to `tar` up your CVS source tree, note the version of your cvs binary and eventual configuration and send that to Bob Proulx or Karl Berry so that they can reproduce the problem and do the stracing when they are online.

Tomas Pospisek <tpo>
Wed 04 Dec 2019 06:12:18 PM UTC, comment #4: 

I'm open for any suggestion but how do you want to practically do this? Meet at a given time and date on IRC and coordinate from there?

Eric L. <ericzolf>
Tue 03 Dec 2019 08:27:45 AM UTC, comment #3: 

comment #2:

> Looking at the permission problem here I don't see anything in particular that seems like a problem.
>
> [apparently sane filesystem permissions]
>
> And therefore I am a little flummoxed as to what might be wrong.


I'd suggest that a possible way forward would be do a strace of the cvs server process when processing Eric's request. It should be possible then to see which system call exactly returns a failure (probably by grep'ing the strace output for "/web/rdiff-backup/rdiff-backup/,index.html,").

If allowing ports through on the firewall(s) is not complicated then the cvs server could even be made to run on a different (additional) TCP port in order to be able to separate the debugging of the problem here from normal savannah traffic. That way it wouldn't interfere with normal services.

Tomas Pospisek <tpo>
Mon 02 Dec 2019 11:21:41 PM UTC, comment #2: 

Hi Karl, Eric.  The source only appears to be on nfs1 because that is the backup location.  Due to the as yet unresolved problem of file ACLs not working with NFSv4 on Trisquel 8 we fell back to hosting all of the CVS data on vcs1 created for CVS alone in a standalone configuration.  Therefore the place to look to debug CVS issues is solely on vcs1.

Looking at the permission problem here I don't see anything in particular that seems like a problem.

root@vcs1:~# id ericzolf
uid=180852(ericzolf) gid=1003(svusers) groups=1003(svusers),3244(rdiff-backup)

root@vcs1:~# ls -ld /cvsdata/web/rdiff-backup /cvsdata/web/rdiff-backup/rdiff-backup
drwxrwsr-x+ 4 root rdiff-backup   41 Dec 30  2003 /cvsdata/web/rdiff-backup
drwxrwsr-x+ 4 root rdiff-backup 4096 Mar 24  2016 /cvsdata/web/rdiff-backup/rdiff-backup

root@vcs1:~# ll -d /var/lock/cvs/web/rdiff-backup/
drwxrwxrwx 2 root root 40 Dec  2 13:37 /var/lock/cvs/web/rdiff-backup/

For comparison:
root@vcs1:~# ll -d /var/lock/cvs/web/coreutils/
drwxrwxrwx 2 root root 40 Dec  2 13:37 /var/lock/cvs/web/coreutils/

And therefore I am a little flummoxed as to what might be wrong.

Bob Proulx <rwp>
Site Administrator
Sun 01 Dec 2019 10:14:05 PM UTC, comment #1: 

Looking on nfs1, your user (ericzolf) is not in the rdiff-backup group, but only in svusers. Which would explain the permission failure. (Compared to, say, user rahvee, who is in rdiff-backup as well as svusers.)

Unfortunately I don't know how that came about or the right way to fix it. I hope Ineiev or Bob or some other more-knowledgeable person can look at it soon.

Sorry,
Karl

Karl Berry <karl>
Site Administrator
Sat 30 Nov 2019 09:24:59 PM UTC, original submission:  

I'm admin of the rdiff-backup group but I still don't manage to modify the website repository.

$ CVS_RSH=ssh cvs -z3 -d:ext:ericzolf@cvs.savannah.nongnu.org:/web/rdiff-backup co -d rdiff-backup-web rdiff-backup
$ vim index.html
$ cvs commit -m 'Changed index.html to refer to new site and github.' index.html
/web/rdiff-backup/rdiff-backup/index.html,v  <--  index.html
new revision: 1.74; previous revision: 1.73
cvs [commit aborted]: could not open lock file `/web/rdiff-backup/rdiff-backup/,index.html,': Permission denied

I have tried to check all kind of docs, but don't find anything that looks like the beginning of an answer.

Eric L. <ericzolf>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tpo (Posted a comment)
  • -email is unavailable- added by rwp (Posted a comment)
  • -email is unavailable- added by karl (Posted a comment)
  • -email is unavailable- added by ericzolf (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-06 rwp StatusNone Done
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code