Re: Git cvsserver serious issue

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Git cvsserver serious issue
Дата
Msg-id AANLkTinU2VWFKMWNrKFHfX0jBQgXmfex-D9Z323-qVBO@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Git cvsserver serious issue  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: Git cvsserver serious issue  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Thu, Sep 23, 2010 at 04:59, Andrew Dunstan <andrew@dunslane.net> wrote:
>>> Also, couldn't we just set up the cvsserver on its own VM with a limited
>>> amount of disk space, and not worry too much about any "DOS threat"?
>>> If somebody does do this, block them and reinitialize that server.
>>
>> We could do that, but that could end up fighting a losing battle in
>> case some bot hits it.
>>
>> I don't like deploying something with a known issue on it, sandboxed or
>> not.
>>
>
> Thinking about this some more, how about we do non-anonymous CVS over SSH
> access to the git-cvsserver for the few buildfarm members that can't
> currently handle using git (e.g. spoonbill)?

Well, if we do that centrally, we are back to a dedicated VM (hint:
we're most certainly not adding non-personal no-password accounts to
one of the VMs used for critical services - it's bad enough we have
Bruce's account there :P).

I assume most buildfarm clients are off static IPs (at least as seen
from the servers - they may be behind a NAT device, but that one
having static out)? If so, it seems simply easier to use pserver...


> I'm not sure if that would handle other requirements, such as Peter's, but I
> hope the residual requirements for CVS support will be pretty rare.

Just to be sure - do we have any other requirements for CVS *beyond*
buildfarm and NLS that we're not thinking of here?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Serializable Snapshot Isolation
Следующее
От: Hitoshi Harada
Дата:
Сообщение: Re: top-level DML under CTEs