Различия в управлении пакетом между Debian и Arch
Проблемы? Да, партии. Это может быть зафиксировано?Конечно. Быстрее, чем переустановка?Наверное, нет.
Моя рекомендация состоит в том, чтобы переустановить. Сохраните резервное копирование существующей системы и восстановите список пакета и содержание файлов в /etc и /var. Для /usr/local, можно, вероятно, восстановить полномочия вручную. Для /home и /srv, необходимо будет восстановить полномочия от резервных копий.
Если это - система с несколькими локальными пользователями, обратите внимание, что создание некоторых читаемых миром файлов показало некоторые вещи, которые должны были остаться конфиденциальными.
- Ваш список паролей теперь поставлен под угрозу: локальные пользователи имели доступ к хешированному списку паролей и могли судить к "в лоб" их. Уведомьте своих пользователей относительно этого.
- Все данные частного пользователя (ssh ключи, сохраненные пароли, электронная почта, независимо от того, что пользователи могли бы считать конфиденциальным) были выставлены всем локальным пользователям. Уведомьте своих пользователей относительно этого.
Если Вы действительно хотите попытаться восстановить (больше осуществления изучения, чем практический маршрут восстановления), сначала восстановите полномочия нескольких файлов. Обратите внимание, что, в то время как большинство файлов теперь слишком открыто, некоторые пропускают необходимые setuid биты. Вот шаги, которые необходимо сделать перед чем-либо еще. Обратите внимание, что это не исчерпывающий список, просто попытка создания едва функциональной системы.
chmod -R go-w /
chmod 440 /etc/sudoers
chmod 640 /etc/shadow /etc/gshadow
chmod 600 /etc/ssh/*_key /etc/ssh*key # whichever matches
chmod 710 /etc/ssl/private /etc/cups/ssl
chmod 1777 /tmp /var/tmp /var/lock
chmod 4755 /bin/su /usr/bin/passwd /usr/bin/sudo /usr/bin/sudoedit
chmod 2755 /var/mail /var/spool/mail
Затем необходимо будет восстановить все полномочия везде. Для файлов под /usr, можно переустановить пакеты с одной из следующих команд, в зависимости от распределения:
- При использовании Debian, Ubuntu или другого распределения на основе APT, можно выполниться
apt-get --reinstall install - При использовании Дуги Linux можно выполниться
pacman -S $(pacman -Qq --dbpath /newarch/var/lib/pacman) --root /newarch --dbpath /newarch/var/lib/pacman, предположение, что Вы находитесь в Живом CD и Вашей установке Arch, смонтировано в/newarch.
Для файлов под /etc и /var, это не будет работать, столько же из них оставят, сколько они: необходимо будет копировать полномочия на рабочей установке. Для файлов под /srv и /home, необходимо будет восстановить от резервных копий так или иначе. Как Вы видите, Вы могли бы также переустановить.
Я просто использую дугу регулярно с нескольких недель, и не эксперт по предмету, таким образом, этот ответ ни в коем случае не является исчерпывающим, всего несколько точек, я отметил о "гибкости/питании":
Это - просто впечатление, но pacman кажется более современным и простым в его дизайне/архитектуре. По крайней мере, существует намного меньше инструментов для контакта с. В то время как я не знаю о способном исходном коде, я просто, оказалось, смотрел на код libalpm (базовая библиотека к pacman) для создания очень простого патча, и это кажется чистым и легким понять.
Это также очень быстро (из-за оптимизации и также вероятно, путем заботы о немногих вещах (см. ниже)). Последний выпуск (pacman 3.5, несколько дней) пытался улучшить производительность путем сокращения количества включенных файлов базы данных.
В то время как дуга ориентирована к использованию двоичных пакетов, это также имеет преимущества при создании пакетов из источника с системой сборки, подобной портам BSD (ABS).
Это очень легко и быстро для создания пакетов, всего нескольких строк в файле PKGBUILD и его сделанном, никакая потребность иметь дело с control/rules/copyright/changelog/whatever как с пакетами Debian. И в некоторых нажимает на сеть ui, Ваш пакет совместно используется со всеми на АУРЕ (Пользовательский Репозиторий Дуги).
Вещи я вхожу в Debian а не в дуге:
Триггеры/рычаги (что делает способное обновление кэшем значка, mandb или безотносительно только путем взгляда, на то, где файлы установки пакета, без потребности в поставщике программного блока сделать что-либо) (кажется, существуют планы реализовать это).
debconf (никакое грандиозное предприятие и между прочим вынуждая меня сделать вещи вручную, это вынуждает меня знать то, что точно сделано) и правильное обращение новых файлов конфигурации (я, по крайней мере, хотел бы, чтобы pacman знал, когда файл конфигурации в новой версии пакета отличается из установленной, потому что это было изменено в новой версии или потому что я изменил его локально).
подписание пакета (кажется, что оно работается на).
Для дуги того, чтобы быть легким, единственная настоящая причина - то, что это идет с немногими пакетами, установленными по умолчанию, и Вы поощряетесь добавить, в чем просто Вы нуждаетесь, таким образом, вероятно, не установка дополнительных зависимостей по умолчанию подстрекает, пользователи для установки избегают чрезмерного увеличения размера.
-
1я не могу проанализировать это: но я могу обойтись без него и по тому, как знают то, что я добиваюсь большего успеха. На последнем предложении существует также опечатка. – tshepang 27.03.2011, 17:52
-
2В каком языке pacman диспетчер пакетов записан? Это имеет низкий уровень и функциональность управления пакетом высокого уровня подобными dpkg/apt, и если так, чем их называют? – Faheem Mitha 27.03.2011, 18:10
-
3@Tshepang: извините, неноситель английского языка здесь. Я подразумевал, что "это не грандиозное предприятие для меня не иметь эту функциональность (debconf) и вынуждая меня сделать вещи вручную, она вынуждает меня знать то, что точно сделано". – gentledevil 27.03.2011, 20:27
-
4@Faheem Mitha: Pacman записан в C и является frontend к libalpm, который обрабатывает и "высокоуровневое" и управление пакетом "низкого уровня". – gentledevil 27.03.2011, 20:32
-
5@zanko: я не носитель языка также. Все, что я хотел, чтобы Вы сделали, делают предложение более ясным, а не в комментарии, а на самом сообщении. BTW, опечатка, которую я упомянул, является дополнительным. Я мог отредактировать сообщение сам, но я думал, что Вы могли бы также зафиксировать его вместе с частью разъяснения. – tshepang 27.03.2011, 20:41
Я начал свое путешествие с Linux с Ubuntu lucid, а в настоящее время использую Arch. Я написал несколько пакетов Arch и скажу, что это намного проще, чем писать пакеты Debian. Но я хотел бы указать @gentledevil , что у Arch есть система перехватов для пакетов, известная как установочный файл .
Обычно он называется $ {pkgname} .install и содержит несколько функций для предварительной / последующей установки / удаления / обновления; просто поместите туда свои обновления кеша шрифтов и так далее, и он будет работать примерно так же, как хуки Debian.
Также я заметил, что вы упомянули «закрепление» приложения с помощью инструментов управления пакетами debian; В пакмане Arch также есть эта встроенная функция, /etc/pacman.conf принимает ряд настроек, включая IgnorePkg = , что предотвратит обновление любых пакетов, перечисленных после равенства ( с разделителями-пробелами)
Прежде чем я захожу слишком далеко, изучите Наглядную временную шкалу Linux
Чтобы понять различия в диспетчерах пакетов, вы должны понять философию операционных систем, изображенных выше
Three Major Parents
- Redhat, теперь Fedora - Package Manger - RPM, сокращение от Redhat Package Manager, командная строка
rpm - Slackware - Package Manager - tgz, обычные заархивированные файлы. Хотя это просто сжатые файлы, они были собраны Slackware в апстриме и помещены в репозиторий, иногда называемый портом
- Debian - DEB, сокращенно от Debian, это инструмент командной строки
Aptitude или Apt
Эти родители - матери и отцы большинства известных нам сегодня распределений. Идея / концепция системы управления пакетами была получена или распространена в той или иной форме. Тем не менее, все эти родительские элементы являются двоичными распространителями, что означает, что программа упаковывается и выбирается третьей стороной, затем сохраняется в репозитории и используется или устанавливается базой пользователей.
3 Minor Parents
- Linux From Scratch - Исходный код, без диспетчера пакетов.
- Gentoo - Производный от Linux с нуля . По сути, этот дистрибутив представляет собой Linux от Scratch плюс менеджер пакетов под названием Portage / emerge
- SourceMage - Package Manager Sorcery
. Эти родительские компоненты незначительны, поскольку их пользовательская база сочетает скорость и простоту установки с мощностью и простотой настройки. Каждый пакет загружается и компилируется с нуля с использованием переменных и файлов конфигурации.
Мост
Arch был создан как мост между двоичным дистрибутивом, таким как один из 3-х основных родителей, и дистрибутивом на основе исходного кода, например, одним из 3-х второстепенных родителей. Таким образом, он получает статус родительского на временной шкале, потому что ни один другой родитель не предоставил эту функцию. Pacman обладает гибкостью, позволяющей пользователю установить двоичный пакет из официального репозитория или специально созданный пакет с использованием системы сборки Arch. Эта концепция обеспечивает баланс между мощностью, которую дают несовершеннолетние родители, и легкостью установки, которую дают основные родители.
На мой взгляд, не диспетчер пакетов показывает мощь системы, поскольку все диспетчеры пакетов выполняют одну и ту же задачу - управлять и поддерживать работоспособность системы. Таким образом, система, которую вы используете, должна определяться такими факторами, как:
- Уровень пользователя: Кто-то, кто новичок в Linux, должен начать с Основного Родителя, тогда как кто-то технически опытный найдет баланс.
- Что вы хотите делать со своей системой: Запуск сервера LAMP с подключенными пользователями полностью отличается от запуска настольного ПК для просмотра веб-страниц и чтения электронной почты.
- Уровень комфорта: Независимо от уровня пользователя, если вы технически опытны, но не хотите тратить выходные на компиляцию системы, вы выберете основного родителя, независимо от того, выбирают ли все, кого вы знаете, что-то еще.
Это ни в коем случае не полный или исчерпывающий ответ - плакаты передо мной уже дали несколько очень хороших оценок, я просто хотел бы добавить свои 2 цента. Другое дело - никогда толком не привык к apt / dpkg. Мне это всегда казалось слишком сложным, мне действительно удобнее всего использовать yum / rpm.
pacman очень прост в использовании, что является плюсом и минусом - вы можете научиться использовать его (помимо сборки пакетов) за один день - он использует в основном интуитивно понятные и полные функции управления пакетами, но - и это большой, но - он крайне негибкий.
Если дизайнеры не продумали функцию заранее, вы облажались.
Несколько примеров: в pacman нет встроенного управления версиями. Если вы хотите понизить версию пакета, вы должны загрузить эту конкретную версию пакета и использовать параметр -U (обновление) для установки из файла. Он очень ориентирован на то, чтобы всегда использовать самые современные пакеты в вашей системе.
Настоящей внутренней очистки / полной перестройки внутреннего кеша нет. Если (из-за проблемы с сетью) загрузка пакета была повреждена, например, во время -Syu, сообщение об ошибке, хотя и точное, не принесет особого смысла - оно не определит поврежденный пакет даже при включенной "полной" детализации и отладке. , и никакое количество -Syyc не очистит кеш и не загрузит пакеты повторно. Хорошей новостью является то, что -Sc сообщит вам, где находятся загруженные пакеты, чтобы вы могли просто удалить проблемный (если вы можете выяснить, какой именно) или все из них и перезапустите -Syu.
Интеграция pacman с dkms также несколько проблематична - при установке нового ядра у меня продолжались ошибки от dkms. Использование dkms build && dkms install для нового ядра работало без сбоев, но pacman не мог бы предложить никакой информации, почему dkms не удалось выполнить во время обновления ядра (я подозреваю, что он никогда не передавал правильный путь к новому ядру, и просто позволял dkms использовать значение по умолчанию (текущее работающее) ядро, но с неправильной версией).
Еще один анекдот о его негибкости - как уже говорилось, я привык к rpm / yum. Если у меня есть файл в моей системе, и я хочу знать, какой пакет владеет им, я могу запустить yum provides / path / to / file и получить ВСЕ пакеты, которые могут его туда поместить, даже если ни один из них не установлен. Если файл был помещен вручную, и теперь я хочу установить пакет - он переименует новый (добавит расширение .rpmnew), и я смогу выбрать, что использовать.
pacman просто выдает ошибку, что файл уже существует, но с совершенно несущественным сообщением об ошибке - он жалуется на конфликты между «истинным» владельцем файла и установленным в данный момент пакетом «файловых систем», как будто он также является владельцем тот же файл. Кроме того, он в основном ориентирован на локальную установленную информацию - попытка получить информацию (например, списки файлов и права собственности) еще не установленных пакетов менее интуитивно понятна.
Проще говоря, он не такой зрелый, как yum, и, вероятно, dpkg, что придает ему простоту использования, также является относительной негибкостью.