[Top][All Lists]

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

[sr #110149] No access right to CVS website repo

From: Bob Proulx
Subject: [sr #110149] No access right to CVS website repo
Date: Thu, 5 Dec 2019 15:13:54 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36

Follow-up Comment #6, sr #110149 (project administration):

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

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.)


Reply to this item at:


  Message sent via Savannah

reply via email to

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