Способная проверка может обнаружить обновление ядра, необходимое для безопасности в отсутствие универсальных Linux?
Это было приостановлено как неясное. Возможно, я вставил слишком много фонового объяснения.Моя вина. Так:
ЭТО - ВОПРОС, ПЕРЕФРАЗИРОВАЛ ЕЩЕ ОДИН ПУТЬ:
Может способная проверка, т.е.
/usr/lib/update-notifier/apt-check
будьте заставлены рассматривать потенциальные обновления ядра, тот же способ, которым это делает необновления ядра, обнаруживая их и различая тех, которые включают исправления безопасности и тех, которые не делают, так, чтобы те, которые делают, были отражены во втором поле вывода способной проверки, не имея метапакета, универсального Linux установленный?
И если способная проверка не может сделать этого, есть ли некоторая другая программа, которая может?
user535733, кажется, понял и ответил на это явно в комментарии:
"... При удалении метапакета нет Никакого другого автоматизированного метода для проверки на обновления ядра..., если Вы не пишете это сами".
Если никто не не согласится, и user535733 не говорит, что я неправильно понял его, и помещает это в ответ, то я дам ему одобрение.
user535733 и waltinator оба предполагают, что я мог записать программу, чтобы сделать это сам. Waltinator может быть до перезаписи исходного кода способной проверки, но я не. Я мог бы, мог написать сценарий обходного решения, но я должен буду найти некоторый способ различать обновления ядра, которые имеют новые исправления безопасности и тех, которые не делают.
Спасибо, gentlesapients.
= = = добавленные материальные концы - исходное сообщение следует = = =
способная проверка (от пакета обновления-notifier), который обычно используют для записи MOTD, но можно назвать непосредственно, вывод возвратов формы:
x;y
где x является количеством возможных обновлений
и y является количеством возможных обновлений БЕЗОПАСНОСТИ
Когда linux-generic не установлен, возможное обновление ядра НЕ рассчитывает к первому числу. Если обновление ядра необходимо для исправления недостатков безопасности в более старых ядрах, проводит его подсчет к второму числу? Другими словами, может apt-check зависьтесь от сказать Вам, что НЕОБХОДИМО обновить ядро в отсутствие метапакета, который зависит от последнего ядра?
Если это не ясно, вот конкретный пример:
Каждый раз я обновляю до 4.4.0-77 это Bork мои Гостеприимные системы, из которых я имею 2, оба на той же машине. Единственное решение я нашел, что на самом деле работает, состоит в том, чтобы восстановить fsarchiver резервное копирование borked системы, смонтировать все мои системы, выполнить lilo (как update-grub для другого загрузчика), чтобы найти новое/старое ядро, перезагрузку в восстановленную систему и удалить универсальный Linux, таким образом, это автоматически не установит 4.4.0-77. Прямо сейчас я проверяю то, что универсальное Linux ядро установило бы путем выполнения:
apt-get install --simulate linux-generic.
Возможно, когда мы добираемся до 78 или 80, или даже 4.4.1 я попробую linux-generic снова.
Так будет apt-check скажите мне, когда одно из новых обновлений ядра не будет только для новейших функций Ну-и-дела-свиста, но и на самом деле исправит дефект безопасности? Или это зависит от linux-generic сделать это? И если последний, там некоторая альтернатива apt-check с этой целью?
3 ответа
<глоток> Ваш вопрос является немного замысловатым, но я думаю, что он сводится к единственному вопросу в заголовке, таким образом, это - то, к чему я собираюсь обратиться.
то, Как Кв. выбирает пакет для обновления
нет, А dvanced Package Tool, способ, которым это предназначается, не может установить новые пакеты (например, linux-image-*-generic) автоматически, если другой пакет не зависит от него. Это только уже обновляет установленные пакеты автоматически и заменяет их предыдущую версию в процессе.
Это - одна причина, почему мы используем метапакеты как linux-image-generic: сделать Кв., знающую о новых пакетах для установки без потребности заменить более старые версии. Мы делаем это для пакетов ядра, потому что было бы трудно заменить в настоящее время рабочее ядро и потому что люди хотят вернуться к более ранней, известной работе версии ядра более легко в случае, если что-либо идет не так, как надо.
, Кроме того, Кв. не знает или заботится о семантике номеров версий. Все, о чем это заботится, является порядком строк номера версии и списком доступных версий для выбора самой подходящей для установки на основе настраиваемой системы оценки. Пакет (репозиторий) менеджеры ответственен за объединение и публикацию восходящих изменений, включая исправления безопасности в заменяющих пакетах с подходящей строкой версии.
, Что это означает для apt-check
Теперь, когда мы покрыли Кв. в целом, я могу обратиться, как это влияет на Ваш вопрос относительно update-notifier, пакет, который обеспечивает apt-check: как Кв. это не может знать о новых пакетах, чтобы установить, если они уже не зависят от установленного или запланированного, чтобы быть установленными пакетами. Если Вы не будете иметь linux-image-generic установленный затем, то Кв. не будет видеть новых пакетов ядра, и ни один не будет update-notifier, когда она запросит Кв. для обновляемых пакетов.
, Что, если я действительно хочу эту функцию?
, Конечно, как с большинством вещей в Linux, Вы можете записать инструмент, который ищет шаблоны среди всех доступных пакетов для установки их (полу-) автоматически. Я, по крайней мере, не знаю встроенных инструментов, которые могут сделать это, хотя эта задача кажется достаточно универсальной, что я не был бы удивлен видеть сценарий для этого, который некоторый администратор взломал вместе.
В Гостеприимном необслуживаемые обновления устанавливают только исправления безопасности по умолчанию. И в программном обеспечении Updater можно выбрать только обновления системы защиты, которые будут установлены. Но что касается Вашей проблемы, предстоящие обновления системы защиты будут, вероятно, содержать изменения более ранних необновлений системы защиты, та авария Ваша система также, таким образом, необходимо будет сообщить об ошибке против Linux для зафиксированного проблемы в предстоящих обновлениях.
Так или иначе, в командной строке Вы могли работать
apt-cache policy linux-generic
для наблюдения, если последнее доступное обновление является обновлением системы защиты.
В Гостеприимном, Вы могли установить последнее обновление системы защиты универсальных Linux вручную
apt-get install linux-generic/xenial-security
Благодаря Вам всем и благодаря Andy в Каноническом, который дал некоторые хорошие подсказки на другом форуме. Я ввел по абсолютному адресу вокруг в этом немного, не только здесь, и я изучил несколько вещей и приехал для подозрения некоторых других. Слишком много вставить комментарий.
Строго говоря на вопрос ответил правильно и быстро user535733 во втором комментарии к моему первому сообщению и честно, если он поместит это в ответ, я буду рад принять его.
@user535733 - Отметьте вышеупомянутое.
Но предмет был расширен waltinator в первом комментарии для включения возможности создания инструмента, чтобы сделать задание и David в то, КАК способная проверка работает и ПОЧЕМУ это не сделает этого без установленного универсального Linux.
Следующее нигде не рядом завершено, часть его является предположением (ясно маркировал, я надеюсь), могло бы даже быть несколько прямых ошибок (предположите, что) и я могу возвратиться и отредактировать еще некоторый материал в. Возможно, кто-то спотыкающийся на этой странице найдет часть этого интереса. Вам, вероятно, придется выполнить команды в Вашей собственной системе для наблюдения вывода ясно в правильном формате.
способная проверка ре и универсальный Linux:
Универсальный Linux, кажется, отвлекающий маневр. Моя вина, я предположил, что это - отсутствие, была проблема. Я теперь не думаю, что способная проверка не может сделать этого ВООБЩЕ, даже если универсальный Linux установлен. Это - хитрый вопрос протестировать, не устанавливая 4.4.0-77. Я протестирую в будущем, когда я не должен буду волноваться о ядре, которое последовательно повреждает мои гостеприимные системы.
Проблема состоит в том Не то, чтобы способная проверка не имеет доступа к необходимым данным. Вам определенно НЕ нужно универсальный Linux установленный, чтобы заставить метаданные о потенциальных обновлениях ядра, достаточных показывать то, что доступно и если они имеют исправления безопасности.
Я принимаю "склонный - получают обновление", часть Кв., получает информацию (больше на этом ниже), но НЕЗАВИСИМО ОТ ТОГО, ЧТО получает его:
это НЕ требует универсальный Linux, установлены для наблюдения потенциальных обновлений ядра.
это НЕ требует универсальный Linux, установлены для определения, от которого в настоящее время зависит версия ядра, универсальная Linux.
это НЕ требует универсальный Linux определять, имеет ли потенциальное обновление ядра исправления безопасности в нем.
Кроме того, независимо от того, что получает эту информацию для начала, информация сохраняется локально (по-видимому, пока Вы не очищаете ее). Поэтому выровняйтесь строка и без установленного универсального Linux, способная проверка имеет доступ к необходимой информации - это просто не использует его, вероятно, ДИЗАЙНОМ. Но это может использоваться в сценарии - я не имею универсальными Linux установленный и здесь являюсь 2 примерами теста, который работает над моей системой даже офлайн:
$ apt-cache showpkg linux-image-4.4.0-75-generic | grep "$(lsb_release --codename --short)-security"
и вывод:
4.4.0-75.96 (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-security_main_binary-amd64_Packages) (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-updates_main_binary-amd64_Packages)
File: /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-security_main_binary-amd64_Packages
File: /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_xenial-security_main_i18n_Translation-en
$
Так, 4.4.0-75 ИМЕЕТ исправления безопасности.
По контрасту:
$ apt-cache showpkg linux-image-4.4.0-77-generic | grep "$(lsb_release --codename --short)-security"
и вывод (просто возврат подсказки):
$
4.4.0-77 НЕ делает.
способная проверка ре и склонный:
Проверка Кв., часть update-notifier-common (не обновляют-notifier как указано выше), может зависеть от Кв. для своей информации о пакетах, как David указывает, вероятно, конкретно на "Кв. - получают обновление", даже если склонный не зависит от универсального Linux для получения информации о потенциальных обновлениях ядра. Это - то, что я ожидал бы, и я не вижу альтернативы, но странно, если devs не отметили зависимости, неправильные, склонные не зависимость для способной проверки:
$ apt-rdepends update-notifier-common | grep apt
и вывод:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Depends: python3-apt
python3-apt
Depends: libapt-inst2.0 (>= 1.1~exp9)
Depends: libapt-pkg5.0 (>= 1.1~exp9)
Depends: python-apt-common
libapt-inst2.0
Depends: libapt-pkg5.0 (>= 1.1~exp9)
libapt-pkg5.0
python-apt-common
$
Так, в теории Вам не нужно склонный выполнить способную проверку - Вы могли использовать ее в системе, управляемой с dpkg и dselect, хотя мне не удается видеть, как это могло работать. Я, конечно, не дал бы разногласия, что это будет, пока я на самом деле не попробовал его (и я май из любопытства позже), но это - способ, которым отмечены зависимости. Вы думали бы, что devs отметил бы склонный как зависимость для update-notifier-common, если бы одна из его команд ПОТРЕБОВАЛА, чтобы Кв. работала, но это может быть контроль.
Так, относительно исходного вопроса вот то, что я теперь подозреваю, верно:
"Может способная проверка... будьте заставлены рассматривать потенциальные обновления ядра, тот же способ, которым это делает необновления ядра, обнаруживая их и различая тех, которые включают исправления безопасности и тех, которые не делают... не имея метапакета, универсального Linux установленный?"
Нет, и это, вероятно, не может С универсальным Linux также.
"И если способная проверка не может сделать этого, есть ли некоторая другая программа, которая может?"
Нет, не из поля, так сказать.
Но, ре, создающее что-то, что может
Как waltinator предложенный способную проверку мог, вероятно, быть переписан, чтобы сделать так, если у Вас есть знание и наклон. Но, как предложенный David, эта функция может, вероятно, быть задана сценарием с другими инструментами и я могу, вероятно, сделать это намного легче, чем изучение, как переписать способную проверку.
Как отмечалось ранее, можно получить название пакета, содержащего новейшее, самое солнечное ядро, бывшее благословленное Каноническим путем применения некоторого grep и сокращать волшебство к выводу:
apt-get install --simulate linux-generic
и можно классифицировать его как having/not_having исправления безопасности с чем-то как
apt-cache showpkg linux-image-4.4.0-75-generic | grep "$(lsb_release --codename --short)-security"
как проиллюстрировано выше.
Идеально, для сценариев этого нам нужна история полной версии того, от чего универсальный Linux зависел избежать ложного отрицания в ситуации это:
Вам установили версию 100.
Версия 101 имела исправления безопасности, но Ваш компьютер не был включен та неделя.
Версия 102 НЕ имеет исправлений безопасности (относительно 101, но она делает относительно 100, так как она все еще имеет тех, которые были сделаны в 101).
Было бы хорошо, если я мог бы завихриться история полной версии универсальных Linux, и так или иначе узнать, в каком "кармане" repo зависимые ядра были опубликованы. До сих пор я только обнаружил, как сделать это для старых версий, которые находятся все еще в repo.
Эта команда:
apt-cache madison linux-generic
идет в нужном направлении, но я думаю, что это только получает то, что НАХОДИТСЯ в repo, не, что БЫЛО в repo, таким образом, я не уверен информация, это уступает, будет достаточно предотвратить ложный отрицательный сценарий, подробно изложенный выше. Если в примере выше, 101 уже закончился от repo, я не думаю информация от "способного кэша, Мадисон, универсальный Linux", был бы достаточен.
И, о, да
Еще одна вещь, на которую я должен указать, чтобы кто-то не заинтересован этим и проводит много времени на ней, не зная это:
Я все еще ввожу по абсолютному адресу в этом, потому что я начал, и я упрям. Но в то время как, чистой случайностью насколько я могу сказать, ядро, которое дало мне проблемы, НЕ имеет исправлений безопасности, и поэтому если бы у меня был рабочий сценарий для этого, то это никогда не имело бы, повредил мои гостеприимные системы, Andy говорит мне, который 4.4.0-77 редкий случай и что у значительного большинства обновлений ядра, которое универсальный Linux зависит от, ДЕЙСТВИТЕЛЬНО есть исправления безопасности. Я подозреваю, что он был фигуративен/гиперболическим, когда он сказал "99%", но даже обеспечение, что, я подозреваю способную проверку как механизм, который относится к потенциальным обновлениям ядра, не собирается предотвращать ненужное (мудрое безопасностью) обновление очень часто и так предотвратит ненужные обновления ядра, повреждающие способные или другие решающие компоненты системы, еще более редко. Это, кажется, просто случайная случайность, которую это сделало бы так для меня. BTW, 4.4.0-78 хорошо работает для меня. Andy был прав - независимо от того, что это было об этих 77, фиксируется.