хостинг или Vps/vds (что лучше)

[Institut]

Доброго дня.
Есть хостинг, с Bitrix( контроль версий), на котором работают пять человек - пишут программы на php, Java итд. Потом куски этих программ переносятся на рабочий сайт. Установлена система CentOS.
На хостинге используется Birix, программы хранят там. Пишут программы на php, Java итд. Есть доступ по ssh, SFTP только к их домашним директориям - например /var/www/coder1/data/ итд Потом переносят готовые куски на сайт. В связи с уходом двух разработчиков, начальник боится, что они могут начать мешать работе или положить сайт итд, в общем опасается.
Начальник решил заменить хостинг, тем самым скрыв ip от этих двух разработчиков.
(Я сам склоняюсь vps, так как тогда перенос будет осуществляться владельцами vds, и соответственно времени на установку CentOS и перенос всех настроек затрачивать не надо)

Соответственно вопрос - что брать в данной ситуации хостинг или Vps/vds?
Или просто сменить ип адрес на хостинге?
Если вопрос не для данной темы, прошу перенести в другую тему.

[serzh-z]

Начальник решил заменить хостинг

Хороший подход, чувствуется, что бюджет в компании... резиновый. =) А не проще ли удалить/заблокировать этих двух разработчиков? Или отозвать их SSH-ключи/поменять пароли.

[Bizdelnick]

Bitrix( контроль версий), на котором работают пять человек - пишут программы на php, Java итд.

Что? Вы это серьёзно? Ни одной нормальной СКВ ваши разработчики не осилили, что ли?

[Institut]

serzh-z - я уже это предлагал. Не слушают меня.
Bizdelnick -

Ни одной нормальной СКВ ваши разработчики не осилили, что ли?

1 - Предложите свои системы контроля версий, которые Вам нравятся.
2 - По заданному мной вопросу есть у Вас совет?

[SLEDopit]

Начальник решил заменить хостинг, тем самым скрыв ip от этих двух разработчиков.

Такое ощущение, что ни у вас, ни у начальника нет точного понимания что такое хостинг, IP, dns имена и как это всё работает.

Я предложил бы начать с основ и почитать подробнее. Заодно про управление доступом на сервера (никакого прямого доступа разработчиков на сервера), современные системы контроля версий (git) и, в идеале, CI/CD.

Конкретно по вашей проблеме -- смена IP навряд ли поможет, если ваш сайт доступен по доменному имени. Вам нужно именно отключить аккаунты разработчиков. Если использовался общий аккаунт на всех, то сменить ключи / пароли. Так же стоит помнить, что наверняка у них был не только ssh доступ, но и доступ в базу данных и что там у вас ещё используется (почта, очереди, etc). Если точного списка нет, поговорите с другими разработчиками. Они должны знать.

Просто переезд на другой IP это пустая трата времени. Пароли старые, аккаунты старые. Если новый IP внезапно станет известен старым разработчикам, но весь ваш переезд станет бесполезен.

И да. При таком подходе, навряд ли у вас есть система code review. Поэтому в худшем варианте не исключено, что разработчики могут оставить какой-нибудь backdoor в системе и воспользоваться им в случае чего, даже если вы своевременно смените все пароли. Подумайте об этом тоже.

[Bizdelnick]

Предложите свои системы контроля версий, которые Вам нравятся.

Специально не предлагал, чтобы избежать вкусовщины. Под нормальными современными СКВ обычно понимают git или mercurial, ну и несколько коммерческих, от которых большинство давно отказалось. Для олдфагов, считающих, что распределённость не нужна, — subversion, но помимо централизованности у него есть ещё ряд неудобств. Если нужен веб-интерфейс и всё равно платите за хостинг, по-моему вполне логично не напрягаясь заплатить какому-нибудь github/gitlab/bitbucket/… Получите сразу нормальное управление правами доступа, не занимаясь настройкой, в которой, как я понял, в вашей конторе мало кто разбирается (а также issue tracker, wiki, code review и прочие плюшки). Вот только мигрировать с php-поделки с сохранением истории вряд ли реально.

[serzh-z]

я уже это предлагал. Не слушают меня.

У меня есть стойкое ощущение, что этому вашему начальнику просто нужно "списать" старый хостинг и получить деньги на новый.

Такая схема была очень популярна, например, у некоторых моих нанимателей в начале столетия. Только применялась по отношению к оборудованию. =)

[Institut]

Начальник решил заменить хостинг, тем самым скрыв ip от этих двух разработчиков.

Такое ощущение, что ни у вас, ни у начальника нет точного понимания что такое хостинг, IP, dns имена и как это всё работает.

Я предложил бы начать с основ и почитать подробнее. Заодно про управление доступом на сервера (никакого прямого доступа разработчиков на сервера), современные системы контроля версий (git) и, в идеале, CI/CD.

Конкретно по вашей проблеме -- смена IP навряд ли поможет, если ваш сайт доступен по доменному имени. Вам нужно именно отключить аккаунты разработчиков. Если использовался общий аккаунт на всех, то сменить ключи / пароли. Так же стоит помнить, что наверняка у них был не только ssh доступ, но и доступ в базу данных и что там у вас ещё используется (почта, очереди, etc). Если точного списка нет, поговорите с другими разработчиками. Они должны знать.

Просто переезд на другой IP это пустая трата времени. Пароли старые, аккаунты старые. Если новый IP внезапно станет известен старым разработчикам, но весь ваш переезд станет бесполезен.

И да. При таком подходе, навряд ли у вас есть система code review. Поэтому в худшем варианте не исключено, что разработчики могут оставить какой-нибудь backdoor в системе и воспользоваться им в случае чего, даже если вы своевременно смените все пароли. Подумайте об этом тоже.

нет точного понимания что такое хостинг, IP, dns имена и как это всё работает

спасибо, я тоже Вас люблю.
Что значит никакого прямого доступа на сервер - а как, им тогда заводить свой отдельный git и с него сливать на сервер разработчиков?
Так правильно или нет???
Я завожу пользователя useradd dev1 -d /var/www/d1/data/www/devel1.dev.mysrver.ru -m -s /bin/false
cd /var/www/d1/data/www/d1.devel1.myserver.ru/
git status
git push origin dev
Прыгнуть выше своей домашней директории он не может.
если ваш сайт доступен по доменному имени, сайт доступен, сервер разработчиков - не доступен.
Доступ по ssh можно закрыть для данных пользователей - проблем не вижу.
Почта не используется.
Системы code review у нас нет. И я тоже не знаю, как её организовать.
оставить какой-нибудь backdoor в системе - и как я это узнаю, расскажите.

Я понимаю, проще всего ткнуть меня мордой в то, что я не знаю, как правильно должно работать.Также не знаю как работает git и уж тем более CI/CD. Но я помогал и на этом форуме тем, у кого что-то не получалось, а не говорил им например man iptables. Так расскажите, как все по феншую сделать, что-бы понятно мне было.
Или, если Вам так будет удобнее, я могу рекомендовать Вас в качестве консультанта по настройке web сервера для разработчиков,по удалнке за деньги, если так Вам проще.
Рутовый доступ по ssh с пустым паролем - обеспечу.

[SLEDopit]

Но я помогал и на этом форуме тем, у кого что-то не получалось, а не говорил им например man iptables.

Ваш вопрос настолько обширный, что тут просто невозможно написать простой и короткий ответ в два предложения, который даст ясный план дальнейших действий. К тому же в вопросе прозвучали несколько моментов, которые указывают на пробелы. Писать подробный ответ в данном случае на целую книгу выйдет.

Что значит никакого прямого доступа на сервер - а как, им тогда заводить свой отдельный git и с него сливать на сервер разработчиков?
Так правильно или нет???
Я завожу пользователя useradd dev1 -d /var/www/d1/data/www/devel1.dev.mysrver.ru -m -s /bin/false
cd /var/www/d1/data/www/d1.devel1.myserver.ru/
git statusgit
git push origin dev
Прыгнуть выше своей домашней директории он не может.
если ваш сайт доступен по доменному имени - не доступен.
Доступ по ssh можно закрыть для данных пользователей - проблем не вижу.
Почта не используется.
Системы code review у нас нет.
оставить какой-нибудь backdoor в системе - и как я это узнаю, расскажите.

Правильно так:
1. У вас есть репозиторий с кодом (скажем условный github.com). Там хранится код и туда есть доступ у разработчиков. Больше никакие доступы им в идеальном мире не нужны. Ну ок, ещё на тестовый стенд можно выдать, но и без этого можно вполне неплохо жить.
2. Когда разработчики меняют код в репозитории, он автоматически деплоится на сервер (ну или руками людьми, кто поддерживает инфраструктуру, но не разработчиками). (git pull + миграции в базе, если нужно)

Подробнее или вот.

Системы code review у нас нет. И я тоже не знаю, как её организовать.
оставить какой-нибудь backdoor в системе - и как я это узнаю, расскажите.

Это когда один разработчик (или руководитель) проверяет код другого разработчика. backdoor -- это закладка в коде, которая позволяет получить доступ к системе в обход правил или предоставляет скрытые возможности (например скидки), которых быть не должно. При наличии code review, вероятность закладок на порядок ниже, чем без нее. В большинстве случаев достаточно запретить коммитить код напрямую в бранч из которого идет деплоймент, а только через пулл реквесты. Те, кто подтверждает пулл реквесты, должны при этом просматривать чужой код.

Или, если Вам так будет удобнее, я могу рекомендовать Вас в качестве консультанта по удалнке за деньги, если так Вам проще.

Нет, спасибо. Но тут есть раздел Работа.

[Institut]

И как код размещенный на github.com и потом переданный на сервер, поможет найти backdoor?
Тогда нужен отдельный человек, который будет проверять этот код и только после его проверки, заливать на сайт.
Иначе как?

[Bizdelnick]

Я понимаю, проще всего ткнуть меня мордой в то, что я не знаю, как правильно должно работать.Также не знаю как работает git и уж тем более CI/CD. Но я помогал и на этом форуме тем, у кого что-то не получалось, а не говорил им например man iptables. Так расскажите, как все по феншую сделать, что-бы понятно мне было.

На эту тему понаписано столько всего, что не знать можно только в том случае, если ни разу не интересовались. И вариантов организации всего этого хозяйства тоже масса. Так или иначе всё сводится к примерно такой цепочке:
Разработчики пишут код и отлаживают на локалхостах, коммитят в локальный репозиторий → отправляют коммиты в основной репозиторий → из основного репозитория система непрерывной интеграции забирает код, собирает его в случае компилируемых языков, запускает юнит-тесты → в случае, если все юнит-тесты прошли успешно, артефакты (бинарники, скрипты или, как сейчас модно, образ контейнера со всем этим хозяйством) отправляются в хранилище → проводятся приёмочные тесты артефактов (сначала автоматические, потом ручные) → выпускается релиз и разворачивается на проде.
У рядовых разработчиков доступа дальше, чем к репозиторию исходников, быть не должно. Управление доступом к репозиторию, как правило, требуется более гибкое, чем "всё или ничего", для этого в случае git используют gitolite или что-то наподобие.

[Institut]

Bizdelnick

На эту тему понаписано столько всего, что не знать можно только в том случае, если ни разу не интересовались. И вариантов организации всего этого хозяйства тоже масса. Так или иначе всё сводится к примерно такой цепочке:

Не поверите - ни разу не интересовался, нужды не было.
Понятно, те все делается на стороне, а не на самом сервере. Потом через git сливается на сервер,
Но вопрос с backdoor остается актуальным.
Да и не понятно, вроде github - бесплатен, а тут https://github.com/pricing - это как понимать?

[Bizdelnick]

Да и не понятно, вроде github - бесплатен, а тут https://github.com/pricing - это как понимать?

Бесплатны публичные репозитории, закрытые — за деньги.

[Institut]

А в чем разница - а публичных и закрытых?
И что с backdoor делать - нанимать отдельного человека?

[SLEDopit]

А в чем разница - а публичных и закрытых?

Одни доступны всем, другие только вам и указанному кругу лиц. Собственно из названия следует. Второй вариант платный. Если нужны именно закрытые репы -- смотрите альтернативы (e.g. bitbucket и другие).

И что с backdoor делать - нанимать отдельного человека?

Зачем? У вас разработчиков больше одного? Вот пусть друг друга и проверяют.

[Bizdelnick]

А в чем разница - а публичных и закрытых?

Раз спрашиваете, видимо, разницы для Вас нет. Публичные доступны на чтение всем, закрытые — только тем, кому дали доступ.

И что с backdoor делать - нанимать отдельного человека?

SLEDopit предложил code review, что является вполне нормальной практикой, полезной и для качества кода, и для обмена опытом. Один разработчик вносит изменения в своей ветке и открывает pull request (в случае github), другой рецензирует изменения и решает, принять их или отправить на доработку.
P.S. Если бюджет позволяет, лучше рассмотрите возможность нанять девопса.

[Institut]

Bizdelnick

SLEDopit

Вы очень здорово всё объяснили. Я действительно был очень далек от данной темы, так как никогда ей не занимался.
В общем похоже надо менять систему по которой сейчас всё работает. В корне.

Spoiler

Сорри за офтоп, а новый дизайн форума мне нравится.