Задать вопрос
  • Как обезопасить linux-сервер после работы с ним третьих лиц (пароли, ключи и др.)?

    icCE
    @icCE
    youtube.com/channel/UC66N_jRyZiotlmV95QPBZfA
    Как я уже написал, вам надо перегенерировать ключи ssh. Сменить пароли.
    Посмотреть lastlog кто и когда совершал вход в систему и подозрительные вещи проверить.
    Проверить не добавлено ли в системы странных репозитореев, после этого проверить пакеты системы.
    Често говоря как это делается в yum я не помню. Сильно рекомендуется установить систему против руткитов. На habre были несколько статей на эту тему, вот одна из них habrahabr.ru/post/112789/.

    P.S. Да , неплохо проверить cron, иногда некоторые админы оставляют не очень хорошие действие.
    Например удалить что-либо через пора месяцев.
    Ответ написан
    5 комментариев
  • Как обезопасить linux-сервер после работы с ним третьих лиц (пароли, ключи и др.)?

    nazarpc
    @nazarpc
    Open Source enthusiast
    Ключи лежат в ~/.ssh/authorized_keys, но кроме этого могут быть созданы другие пользователи с правами администраторами, и сохранены бэкдоры при необходимости, так что тут уже зависит от уровня паранойи.
    Ответ написан
    2 комментария
  • Выбор между Битрикс и Drupal

    kotomyava
    @kotomyava
    Системный администратор
    1. Есть — www.gnu.org/licenses/old-licenses/gpl-2.0.html, естественно это не та лицензия, которую надо продавать. =)
    2. Действительно толковой интеграции с 1С нет ни в Drupal, ни в Bitrix.
    3. Нет, но в таком виде он и не особо нужен — пилить готовое решение до того состояния, которое необходимо клиенту часто более трудоёмкий процесс, чем создать его из блоков, особенно если есть свои заготовки. Drupal очень гибкая и модульная система, а чтобы не повторять свои решения, можно делать и развёртывать заготовки с помощью features. Это, например, может быть готовый раздел новостей, или другая крупная часть функционала. Есть и различные сборки, но у такого подхода есть минусы — во-первых они практически никогда не совпадают по функционалу с ТЗ конкретного клиента, во-вторых вы не участвуете в развитии и обновлении, с и в один прекрасный момент это может выйти боком…
    4. В случае Drupal тут всё зависит от вас, как разработчика — админка Drupal темизируется и настраивается не хуже фронтэнда. Можно сделать в точности соответствующей нуждам клиента, можно очень неудобно, можно оставить как есть.
    5. Требования к хостингу сопоставимы — и тому и другому нужен хороший хостинг. Bitrix из-за общей прожорливости, Drupal из-за любви к оперативке, и большого количества запросов к БД, которые на хреновых хостингах часто просто лимитируются.

    Разрабатывать под Drupal проще, особенно, если делать что-то не стандартное. Ситуация с этим в Bitrix та же, что вы описывали для UMI.
    У Drupal нет мощного маркетинга, поэтому найти заказчика и продать ему сайт на Bitrix проще. И это может быть критичным плюсом, который перевесит все проблемы разработки.
    Собственно именно на этом маркетинге Bitrix и выезжает — внутри откровенная гниль.
    Ответ написан
    2 комментария