Участник:Diman Russkov: различия между версиями

Материал из ЧТМ
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
← Предыдущая правкаСледующая правка →
Diman Russkov (обсуждение | вклад)
Основатель, Расширенный доступ, Полный доступ, Разработчики
1256 правок
ВизуальныйВики-текст
Нет описания правки
Нет описания правки
Строка 4: Строка 4:
* [[ЧТМ:Расширения]]
* [[ЧТМ:Расширения]]


ИИ о расширении CheckUser:
== Чистка БД ==
<markdown>Приношу искренние извинения! Вы абсолютно правы, и я дал вам чудовищно вредный совет с точки зрения классической философии Вики-проектов. Архив (`archive`) — это важнейшая историческая летопись, а не мусорное ведро. Скрипт `deleteOldRevisions` действительно пройдётся по всему архиву вики и уничтожит историю всех когда-либо удалённых страниц. Это недопустимо.
 
Вы задали абсолютно правильный вопрос: **как точечно «кастрировать» тяжелые правки в таблице `text`, не сломав целостность сложной структуры MediaWiki (ревизии, слоты, контент)?**
 
Ответ: **Никогда не используйте `DELETE` для таблицы `text`. Используйте `UPDATE`.**
 
Если вы удалите строку из `text`, вы сломаете ключи в таблицах `content` и `slots`, и вики начнет сыпать фатальными ошибками при попытке открыть историю страницы. Но если вы просто *замените* 3 мегабайта текста на крошечную заглушку, целостность базы данных сохранится идеально. В истории правок эти ревизии останутся, но при их открытии будет отображаться пустота, а место на диске освободится.
 
Поскольку эти три правки весят по 2.8 Мб, они будут торчать в вашей базе данных как Эйфелева башня, и найти их через терминал или phpMyAdmin будет элементарно.
 
### Снайперская очистка через phpMyAdmin (или консоль MySQL)
 
**Шаг 1. Находим `old_id` этих гигантских правок**
Выполните следующий SQL-запрос (если у вас есть префикс таблиц, например `mw_`, добавьте его: `mw_text`):</markdown>
 
<syntaxhighlight lang="sql" line>
SELECT old_id, LENGTH(old_text) AS size, old_flags
FROM text
ORDER BY size DESC
LIMIT 10;
</syntaxhighlight>
 
<markdown>Поскольку обычные статьи весят килобайты, этот запрос мгновенно выведет вам топ самых тяжелых правок за всю историю вашей вики. На первых строчках вы увидите ваши три правки размером ~2800000 байт.
*Запишите их `old_id` (например, 1501, 1502, 1503).*
 
**Шаг 2. Обнуляем их вес (Освобождаем БД)**
Теперь мы просто превращаем этот машинный код в пустой, но валидный JSON-объект, чтобы не сломать парсер MediaWiki, если кто-то случайно откроет эту правку в истории. Выполните:</markdown>
 
<syntaxhighlight lang="sql" line>
UPDATE text
SET old_text = '{"info": "historical heavy cache deleted by admin"}',
    old_flags = 'utf-8'
WHERE old_id IN (1501, 1502, 1503);
</syntaxhighlight>
 
<markdown>*(Замените цифры в скобках на те `old_id`, которые вы нашли на первом шаге).*
 
**Почему `old_flags = 'utf-8'`?**
Иногда MediaWiki сжимает старые тяжелые правки и ставит флаг `gzip` или `utf-8,gzip`. Если мы заменяем сжатый бинарник на обычный текст, флаг `gzip` нужно обязательно убрать, иначе вики попытается «разархивировать» наш новый текст и выдаст ошибку. Флага `utf-8` или вообще пустой строки `''` будет достаточно.
 
### Итог:
1. Вы мгновенно освободили 8.5 Мегабайт в таблице `text`.
2. Дерево истории (номера ревизий, кто сделал правку, когда) осталось абсолютно целым.
3. Ваш архив удалённых страниц в полной безопасности.
4. Никаких ошибок или «оборванных» связей (orphaned rows) не возникло.
 
### Совет на будущее (Как не плодить этот вес):
Поскольку вы часто тестируете код (отлаживаете медали, таблицы), не генерируйте кэш по всем 40 годам во время отладки.
В модуле `Module:Cron/GenerateStats` в массиве `Config.years` временно оставьте только один год (например, 2046). Генерируйте этот крошечный JSON (он будет весить пару десятков килобайт) и сохраняйте его в `GrandStats.json` хоть 100 раз подряд.
И только когда вы убедитесь, что в интерфейсе всё работает идеально, раскомментируйте все годы, сгенерируйте полную базу в 2.8 Мб и сделайте **ровно одну финальную правку**.</markdown>
 
== ИИ о расширении CheckUser ==


<pre>Метод 1: Поиск по подсетям (Использование масок CIDR)
<pre>Метод 1: Поиск по подсетям (Использование масок CIDR)

Версия от 21:27, 4 июня 2026

Инженер
Этот участник является основателем ЧТМ Вики
Инженер
Этот участник является одним из разработчиков ЧТМ Вики
Расширенный доступ
Этот участник является одним из участников с расширенным доступом к ЧТМ Вики
Полный доступ
Этот участник является одним из участников с полным доступом к ЧТМ Вики

Статистика


Правки:1256

БП — 0 (50, в т. ч. статьи — 0,ЮП — 0,ЦК — 0)

Расширения для ЧТМ Вики

Чистка БД

Приношу искренние извинения! Вы абсолютно правы, и я дал вам чудовищно вредный совет с точки зрения классической философии Вики-проектов. Архив (archive) — это важнейшая историческая летопись, а не мусорное ведро. Скрипт deleteOldRevisions действительно пройдётся по всему архиву вики и уничтожит историю всех когда-либо удалённых страниц. Это недопустимо.

Вы задали абсолютно правильный вопрос: как точечно «кастрировать» тяжелые правки в таблице text, не сломав целостность сложной структуры MediaWiki (ревизии, слоты, контент)?

Ответ: Никогда не используйте DELETE для таблицы text. Используйте UPDATE.

Если вы удалите строку из text, вы сломаете ключи в таблицах content и slots, и вики начнет сыпать фатальными ошибками при попытке открыть историю страницы. Но если вы просто замените 3 мегабайта текста на крошечную заглушку, целостность базы данных сохранится идеально. В истории правок эти ревизии останутся, но при их открытии будет отображаться пустота, а место на диске освободится.

Поскольку эти три правки весят по 2.8 Мб, они будут торчать в вашей базе данных как Эйфелева башня, и найти их через терминал или phpMyAdmin будет элементарно.

Снайперская очистка через phpMyAdmin (или консоль MySQL)

Шаг 1. Находим old_id этих гигантских правок Выполните следующий SQL-запрос (если у вас есть префикс таблиц, например mw_, добавьте его: mw_text):

SELECT old_id, LENGTH(old_text) AS size, old_flags 
FROM text 
ORDER BY size DESC 
LIMIT 10;

Поскольку обычные статьи весят килобайты, этот запрос мгновенно выведет вам топ самых тяжелых правок за всю историю вашей вики. На первых строчках вы увидите ваши три правки размером ~2800000 байт. Запишите их old_id (например, 1501, 1502, 1503).

Шаг 2. Обнуляем их вес (Освобождаем БД) Теперь мы просто превращаем этот машинный код в пустой, но валидный JSON-объект, чтобы не сломать парсер MediaWiki, если кто-то случайно откроет эту правку в истории. Выполните:

UPDATE text 
SET old_text = '{"info": "historical heavy cache deleted by admin"}', 
    old_flags = 'utf-8' 
WHERE old_id IN (1501, 1502, 1503);

(Замените цифры в скобках на те old_id, которые вы нашли на первом шаге).

Почему old_flags = 'utf-8'? Иногда MediaWiki сжимает старые тяжелые правки и ставит флаг gzip или utf-8,gzip. Если мы заменяем сжатый бинарник на обычный текст, флаг gzip нужно обязательно убрать, иначе вики попытается «разархивировать» наш новый текст и выдаст ошибку. Флага utf-8 или вообще пустой строки '' будет достаточно.

Итог:

  1. Вы мгновенно освободили 8.5 Мегабайт в таблице text.
  2. Дерево истории (номера ревизий, кто сделал правку, когда) осталось абсолютно целым.
  3. Ваш архив удалённых страниц в полной безопасности.
  4. Никаких ошибок или «оборванных» связей (orphaned rows) не возникло.

Совет на будущее (Как не плодить этот вес):

Поскольку вы часто тестируете код (отлаживаете медали, таблицы), не генерируйте кэш по всем 40 годам во время отладки. В модуле Module:Cron/GenerateStats в массиве Config.years временно оставьте только один год (например, 2046). Генерируйте этот крошечный JSON (он будет весить пару десятков килобайт) и сохраняйте его в GrandStats.json хоть 100 раз подряд. И только когда вы убедитесь, что в интерфейсе всё работает идеально, раскомментируйте все годы, сгенерируйте полную базу в 2.8 Мб и сделайте ровно одну финальную правку.

ИИ о расширении CheckUser

Метод 1: Поиск по подсетям (Использование масок CIDR)
Когда ваш IP меняется (например, вы перезагрузили роутер или переподключились к мобильной сети), он редко меняется полностью. Обычно меняются только последние цифры, так как провайдер выдает вам адреса из одного пула.
Вместо того чтобы вводить конкретный IP, введите в поле CheckUser диапазон адресов.
Как это сделать для IPv4:
Допустим, ваш текущий IP: 176.59.112.45. Вы ввели его и нашли 3-х последних виртуалов.
Теперь отбросьте последнее число и вместо него напишите 0/24.
Введите в поле CheckUser: 176.59.112.0/24 (и выберите «Получить учётные записи»).
Это заставит систему искать всех пользователей, которые правили с любого IP от 176.59.112.0 до 176.59.112.255. Вы увидите гораздо больше своих учеток.
Если этого мало, отбросьте две последние цифры и введите маску /16 (это покрывает 65 000 адресов провайдера).
Введите: 176.59.0.0/16. Система выдаст всех, кто сидел с IP, начинающегося на 176.59....
Как это сделать для IPv6:
Если ваш провайдер использует длинные адреса с двоеточиями (IPv6), то они меняются постоянно.
Вам нужно скопировать первую половину адреса (первые 4 блока) и добавить /64.
Пример: ваш IP 2a00:1fa0:c202:1111:5555:6666:7777:8888.
В поле CheckUser введите: 2a00:1fa0:c202:1111::/64.
Метод 2: Цепной поиск (Клубок)
Если вы заходили с совершенно разных сетей (дом, работа, мобильный, кафе), подсети не помогут. Вам придется "разматывать клубок" вручную. Расширение не сделает это за один клик.
Алгоритм ввода (что прописывать по шагам):
Шаг 1: Вводите имя Учётной записи №1 (которую вы точно помните). Выбираете "Получить IP-адреса".
Результат: Вы получаете список, скажем, из 5 разных IP-адресов.
Шаг 2: Копируете IP-адрес №1 из полученного списка. Вставляете его в поле и выбираете "Получить учётные записи".
Результат: Система выдает вам Учётную запись №1 и, внезапно, Учётную запись №2 и Учётную запись №3, с которых вы сидели на этом же IP месяц назад.
Шаг 3: Теперь вводите имя найденной Учётной записи №2 и ищете её IP-адреса.
Результат: Она выдает вам еще 4 новых IP-адреса, с которых вы работали.
Шаг 4: Вводите эти новые IP-адреса по очереди и ищете учётки. Находите Учётную запись №4.
Вы повторяете этот процесс (Учётка -> её IP -> Учётки на этих IP -> их IP -> новые Учётки), пока система не перестанет выдавать новые имена. Это называется перекрестный поиск.
Важное ограничение: Правило 90 дней
Почему вы можете не найти некоторых своих старых виртуалов, даже если будете использовать подсети и цепной поиск?
Расширение CheckUser жестко ограничено настройкой $wgCUDMaxAge в конфигурации вашей Вики (по умолчанию это 3 месяца / 90 дней).
Все данные старше 90 дней автоматически удаляются из таблиц cu_changes.
Если вы создали виртуал полгода назад, сделали пару правок и больше на него не заходили — через веб-интерфейс CheckUser вы его уже никак не найдете. Его IP-адреса стерты из логов. Связать его с вашим текущим IP невозможно.
Что делать, если нужны старые учётки?
Раз вы владелец/админ этой Вики и имеете доступ к серверу (к базе данных MySQL/MariaDB), вам не нужен CheckUser для старых учеток. Но вам придется делать запрос напрямую к базе данных.
Дело в том, что Mediawiki хранит IP-адрес, с которого была создана учетная запись, бесконечно долго в таблице user, в столбцах user_registration или смежных логах (в зависимости от версии движка, сейчас это часто пишется в таблицу logging). Вы можете выгрузить список всех пользователей и отсортировать их по дате регистрации или просто просмотреть историю создания аккаунтов. Но именно расширение CheckUser вам тут уже не поможет.


ОФ

Manual:Logging to Special:Log

Служебная:Разблокировка_БД

https://www.mediawiki.org/wiki/Category:User_rights_extensions

https://www.mediawiki.org/wiki/Extension:GroupWhitelist

https://www.mediawiki.org/wiki/Extension:ArticleCreationWorkflow

https://www.mediawiki.org/wiki/Extension:Checkpoint

https://www.mediawiki.org/wiki/Extension:CirrusSearch

1

2

3

Источник — http://thirdworldcup.ru/index.php?title=Участник:Diman_Russkov&oldid=69768