Почему бы нам не взломать ядро?


17

Я не мог поверить, что этот вопрос еще не был дан ответ на этом сайте, но я не нашел его, когда я искал, так что ...

Почему взломать ядро ​​так плохо, преступление против природы?

  • Разве это так здорово - иметь возможность обновить версию ядра? Большинство моих сайтов в конечном итоге имеют ужасно устаревшие ядра, так зачем беспокоиться?
  • Даже если это так плохо для владельцев сайтов, почему сообщество так заботится? Почему это называется "убийство котят"? Разве это не гиперболично?
  • Взломать ядро ​​так просто, разве нам не нравится идти по более простому пути к решению проблем?
  • Разве не там проблемы , которые могут только быть решены путем взлома ядра? Что тогда?

Я думаю, что если вы создаете небольшой веб-сайт самостоятельно, без команды, может быть, вы можете взломать ядро, если вам нужно, но зачем вам это? Я считаю, что вы можете решить любую проблему без взлома ядра
Петр Попелышко

4
@beth я на самом деле довольно серьезно об этом. Патчи, необходимые для защищенных страниц в D7, зависали уже более года из-за проблем с юнит-тестами. Насколько я помню, в D6 все еще есть ошибка с длинами имен машин в меню. Ни один из них не продемонстрировал каких-либо успехов в деле совершения.
mpdonadio

3
@MPD На самом деле это отличный пример, я знаю немало людей, которые требуют этих патчей (включая меня). Котята в стороне, очевидно, иногда вам совершенно необходимо исправлять ядро, и в этом нет ничего плохого, если эти исправления хорошо документированы и доступны для всех в команде. Это также говорит о важности надежного процесса развертывания, при котором обновления не выполняются вслепую без предварительных ручных проверок. В моей (небольшой) команде мы просто документируем, что изменилось, и проверяем, что все знают, чтобы проверить это перед обновлением
Клайв

3
Примените патч и запишите его в текстовый файл, который находится в корне вашего хранилища.
Чарли Шлиссер

1
Я бы перефразировал его так: «Никогда не взламывайте ядро, если у вас нет механизма, чтобы все еще иметь ваши обновления». Это требует некоторых размышлений и влияет на ваш рабочий процесс разработки. Если вы или ваша команда не готовы к этой дополнительной няне, не делайте этого.
Donquixote

Ответы:


9

Вообще говоря, есть три причины не изменять основной код Drupal:

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

  • Исправления безопасности применяются к ядру Drupal, как поддерживается на Drupal.org, но не могут применяться к вашей взломанной версии. Это означает, что вы должны убедиться, что ваша версия не затронута проблемой безопасности, возникающей в ядре Drupal.
    В случае, если ваша взломанная версия представляет другую проблему безопасности, вы единственный, кто может ее найти, поскольку у вас нет поддержки группы безопасности, которая занимается исследованием недостатков безопасности, присутствующих в коде ядра Drupal и сторонних разработчиков. модули, размещенные на Drupal.org.

  • Внесенные вами изменения могут быть несовместимы как с самим Drupal, так и со сторонними модулями, которые необходимы для работы с ядром Drupal, а не с любой взломанной версией, которую можно создать.
    Каждый раз, когда Drupal вводит новую функцию (которая все еще происходит в Drupal 7 и в Drupal 6, хотя и с меньшей частотой) или новое изменение API, существует вероятность того, что взломанная версия несовместима с последними изменениями.

Тем не менее, можно создать взломанную версию, но это не та задача, которую может выполнять один разработчик, точно так же, как Drupal не поддерживается одним человеком. Фактически, Pressflow является взломанной версией Drupal, которая была создана с учетом производительности и для решения некоторых проблем с производительностью, которые могут возникнуть на сайте Drupal.

Нет ли проблем, которые можно решить только взломом ядра? Что тогда?

В большинстве случаев можно изменять функции / поведение без редактирования кода ядра Drupal. Всегда есть ловушка, которая позволяет изменить особенности / поведение, которые есть у Drupal, и это предпочтительный метод.


4
Я могу опубликовать две реальные проблемы, с которыми я столкнулся, которые могут оспорить утверждения в последнем абзаце.
mpdonadio

3
In the case your hacked version introduces a different security issue...Я не вижу в этом особого аргумента в пользу изменения файла ядра по сравнению с чем-либо еще. Если я не взламываю ядро ​​и вместо этого я создаю проблему безопасности через модуль, моя система все равно будет взломана. Компрометация скомпрометирована, не имеет значения, пришло ли это от меня, редактируя существующий файл или добавляя новый.
Zoredache

@Zoredache Если в вашем модуле присутствует проблема безопасности, вы всегда можете отключить ее, а остальная часть сайта будет работать без проблем с безопасностью, даже без функций. Если вы представляете проблему безопасности в коде ядра Drupal, и невозможно просто скопировать обратно исходные файлы, потому что вы также изменили схему некоторых таблиц, используемых Drupal, то это более серьезная проблема.
kiamlaluno

2
Утверждение, что «всегда есть крючок ...» не является правильным. Весьма распространено, что есть что-то, что выпекается в ядре drupal, которое нельзя обойти без взлома, а также что существуют открытые проблемы для drupal с патчами, которые не были зафиксированы, и в этом случае вы должны патчить ядро для решения этих вопросов.
Роби

2
Абсолютно, но это простой пример. В большинстве случаев есть зацепки, но все же иногда нужно исправлять ядро, если вы не хотите дублировать большой объем кода и создавать что-то более нестандартное. Например, чтобы позволить администраторам правильно администрировать неопубликованные книги, вам нужен патч на drupal.org/node/520786 или если вы хотите, чтобы SQL-поиск по умолчанию для drupal совпадал с частичными словами (включая фильтр поиска представлений), вам нужен патч на drupal.org / node / 498752 # comment-6001310 - обходить их без взлома ядра не представляется возможным.
Роби

14

Я мог бы написать масштабный ответ здесь, но я просто опубликую эту ссылку: Никогда не взламывайте ядро !

Основная причина, я думаю, заключается в том, что если вы взломаете ядро, чтобы сделать то, что вам нужно, а затем обновить его ... БАХ! Ваши изменения ушли. Потерянный. Затем вы можете попытаться откатить код из вашей VCS, но, видя, что вы не можете откатить обновления баз из ядра Drupal - вы смотрите на восстановление всего кода из VCS, а затем восстановление баз данных из ваших резервных копий. Все время, когда вы пытаетесь откатить свой код, вы, вероятно, заметите, что ваша последняя резервная копия базы данных перед обновлением не удалась, и вы поклянетесь больше, чем когда-либо.

Кроме того, что наиболее важно, если вы взломаете ядро, Dries и Webchick убьют котенка: -o


4
Что, они убивают котенка? Я думал, что это был Бог. , Мой мир падает вокруг себя ...
Клайв

1
Вы знаете, я написал свой комментарий выше, прежде чем увидел котят, упомянутых здесь.
mpdonadio

13

«Что не может взломать ядро ​​для меня, разработчика?»

  • Ваш сайт может быть обновлен до релизов безопасности
  • Ваш сайт может быть обновлен, чтобы исправить надоедливые ошибки в ядре
  • Ваш сайт может быть обновлен для поддержки новых модулей
  • Ваши сообщения об ошибках и запросы поддержки на ядро ​​и вклад смогут ответить на
  • Вы хотите использовать поддерживаемую CMS, поэтому вы выбрали Drupal. Когда вы взламываете ядро, словами вебчика : «Если вы взломали ядро, поздравляю! Вы создали свой собственный форк Drupal, и теперь вы и только вы один несете ответственность за его поддержку!»

«Что не может взломать ядро ​​для моего клиента?»

  • Ваш сайт может обслуживаться кем-то другим после того, как вы уволите своего клиента / выиграете в лотерею / попадете в автобус

«Что не может взломать ядро ​​для моего сообщества?»

  • Ваши сообщения об ошибках на самом деле предоставят полезную информацию для сопровождающего ядра или модулей contrib.
  • Если вы обнаружите допустимую ошибку в ядре, которая должна быть исправлена, грань между «взломом ядра» и «становлением основным участником» так же хороша, как простое внесение изменений и загрузка их в виде патча в соответствующую проблему do. Виола! Ядро лучше для ваших усилий, а ваше имя связано с возвращением кода сообществу.

Каждый выигрывает, если не взламывать ядро!


3
Не все патчи привязаны к ядру, даже простые.
mpdonadio

1
Да, но, загрузив его, вы, по крайней мере, получите запись патча, что он делает, возможно, некоторые версии, которые были улучшены другими, и возможность загрузить его и применить его к вашему проекту снова, если у вас есть обновление, которое перезаписывает твоя перемена И часто причина, почему это не было совершено, и альтернативные предложения. Все бесплатно.
Бэт

6

В настоящее время я работаю над взломанным основным сайтом. У меня возникают трудности с поиском простых настроек шрифта. Я также провожу несколько дней, исправляя ошибку, внесенную основным хаком. Я нашел это, ища строку во всем друпальском коде.

Если вы не следуете стандартной структуре программирования в drupal, то как кто-то другой может найти и отредактировать внесенные вами изменения? Это особенно болезненно, потому что в drupal каждый отдельный php-файл может реализовать хук. Попробуйте выяснить, какой из них вызывает проблемы.


4
Эта. Если вы унаследуете сайт, созданный на основе какой-либо конкретной инфраструктуры, а затем обнаружите, что эта платформа была взломана, и, следовательно, документация для этой платформы потенциально неактуальна, вам будет больно. (в дополнение ко всем вышеупомянутым причинам, приведенным выше ...)
Чарли Шлиссер

5
Спорим, ты бы хотел услышать о drupal.org/project/hacked раньше?
Крис Берджесс

Хорошо выглядит Крис. Я обязательно посмотрю.
Павел G

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

5

«Разве нет проблем, которые можно решить только взломом ядра? Что тогда?»

Чтобы ответить на этот вопрос, да, иногда возникают проблемы, которые вы должны преодолеть, что означает, что вам нужно взломать ядро ​​(или модуль contrib).

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

Например, для любого изменения ядра или вклада я создаю патч. Если он является общим и полезным для других людей, я отправляю его на drupal.org в номере, в противном случае - для собственного использования.

Затем я фиксирую файл патча в моем контроле версий вместе с изменением кода.

Это означает, что я могу видеть файлы патчей, если что-то было взломано.

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

В этой хакерской документации я перечисляю каждый хак с описанием того, что делает хак и почему, затронутыми модулями / файлами, именем файла патча, содержащего код хака, и ссылкой на связанную проблему drupal.org, если она есть (почти всегда в моем случае есть).

Тогда у вас и у всех, кто еще работает на сайте в будущем, есть полный список хаков, и вам не нужно беспокоиться о том, чтобы случайно что-то сломать с обновлением.

Затем для процесса обновления я проверяю свой список хаков и быстро просматриваю файлы исправлений во всех модулях, которые я обновляю. Если есть взлом, и у него есть проблема с drupal.org, я проверяю эту проблему, чтобы увидеть, есть ли в последней версии патч, и в этом случае я удаляю хак с обновлением и удаляю его из моего списка хаков (make Посмотрев на сообщения о коммитах drupal.org, убедитесь, что то, что было зафиксировано, совпадает с версией используемого вами патча или, по крайней мере, функционально совпадает).

Если патч не был зафиксирован, все, что мне нужно сделать, это обновить модули и повторно применить патчи. Во многих случаях исправления будут по-прежнему применяться корректно, и процесс будет легким, но иногда вам придется повторно применить исправления для новой версии, а затем зафиксировать новую версию исправления в своем локальном хранилище (вместе с публикацией в соответствующем хранилище). Проблема drupal.org, где это применимо).

Еще одна вещь, которую мне нравится делать, если у меня есть более существенные исправления или исправления, которые взаимодействуют с функциональностью ядра модуля (или просто пользовательские модули, которые расширяются поверх модуля drupal.org), - это проверить примечания к выпуску обновленного модуля ( это означает всю версию между вашей текущей версией и версией, на которую вы обновляете), и убедитесь, что там нет ничего, что могло бы испортить ваш код. Примечание. Многие сопровождающие модуля в наши дни хороши тем, что дают полные заметки о выпуске, но есть еще много, которые делают пометки о выпуске. В этом случае в некоторых случаях я просматриваю все сообщения коммита начиная с моей текущей версии (обычно это происходит только в тех случаях, когда у меня сложный код, который глубоко взаимодействует с другим модулем). Замечания:

Затем, после обновления (в разрабатываемой копии сайта), тщательно протестируйте. В конце концов вы узнаете, что значит тщательно, после того, как проскочат несколько ошибок.

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

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

Если вы когда-нибудь унаследуете такой сайт, вы полностью поймете :)


2

Если вы зарабатываете на жизнь за счет установки и создания веб-сайтов Drupal, то необходимо поддерживать их в актуальном состоянии. Если большинство ваших сайтов оказываются ужасно устаревшими, значит, вы не профессионал.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.