Показаны сообщения с ярлыком openSUSE. Показать все сообщения
Показаны сообщения с ярлыком openSUSE. Показать все сообщения

понедельник, 3 апреля 2017 г.

Последствия пересборки raid после использования

Жил, да не тужил сервер у меня на базе openSUSE 13.1, да в связи с недавним окончанием поддержки данного релиза, было решено перейти на 42.1, а в связи с тем, что прямое обновление между этими релизами строго не рекомендуется и высока вероятность получить нерабочую систему, выбор пал на свежую установку пока ещё поддерживаемой 42.2

Установка вроде прошла успешно и много раз повторялась в разных вариациях из-за возникшей ошибки:
erst can not request mem for erst

Что это такое и с чем это едят, так и не понял, хотя читал гуглёвые ссылки долго и упорно. Интуитивно, пошёл разбираться в сторону RAID, так как ранее в выводе
dmraid -tay
видел записи про "not activated", а информация о массиве говорила "not synced". Отключив в fstab проблемный раздел, загрузка внезапно прошла успешно. При этом, если включить раздел, загрузка вновь "встанет".

Журнал journalctl, который для меня был некой новинкой, так как в 13.1 его ещё не было, показал другую интересную ошибку:
device appeared twice with different sysfs paths

которая показала на два зеркальных раздела на дисках.

Сделал пересборку RAID на двух массивах, но это не помогло (хотя процедура была нужная, так как диски не были синхронизированы).

В итоге проблема решилась пересозданием разделов на проблемном массиве.

суббота, 24 августа 2013 г.

Установка кодеков в openSUSE

Решил обновить старую инструкцию в связи с сообщением на форуме...

Установка в графическом режиме.

Установка в графическом режиме производится с помощью файлов для "установки в один клик" и YaST2. От версии openSUSE в принципе не зависит и в данный момент ориентирована на работу в openSUSE версий с 11.4 по 12.3, а также в Factory и Tumbleweed.

KDE

Если у вас KDE, то установить кодеки можно кликнув здесь (поведение зависит от браузера, см. ниже).

Gnome

При использовании Gnome, кодеки можно установить нажатием на этот файл (поведение зависит от браузера, см. ниже).
  • При использовании Mozilla Firefox, откроется YaST2 с предложениями о подключении репозиториев и установке необходимых пакетов. При получении сообщения о конфликте пакетов, выберите смену поставщика и продолжите установку.
  • При использовании Google Chrome, либо Chromium, файл откроется в виде текста, поэтому его для начала нужно сохранить с помощью функции "Сохранить ссылку как..." (правая клавиша мыши и соответствующий пункт меню), после чего уже кликнуть на сохранённый файл.

Консольный режим

Примечание: Набор устанавливаемых пакетов подразумевает использование KDE.
Чтобы установить пакеты используя консоль и zypper, нужно добавить репозитории packman и libdvdcss. Это делается следующими командами:
Для openSUSE 12.2:
zypper addrepo -r http://packman.inode.at/suse/12.2/packman.repo
zypper addrepo -r http://www.opensuse-guide.org/repo/12.2/libdvdcss.repo

zypper install libxine2-codecs k3b-codecs ffmpeg lame gstreamer-0_10-plugins-bad gstreamer-0_10-plugins-ugly gstreamer-0_10-plugins-ugly-orig-addon gstreamer-0_10-plugins-ffmpeg libdvdcss2
Для openSUSE 12.3:
zypper addrepo -r http://packman.inode.at/suse/12.3/packman.repo
zypper install libxine2-codecs k3b-codecs ffmpeg lame gstreamer-0_10-plugins-bad gstreamer-0_10-plugins-ugly gstreamer-0_10-plugins-ugly-orig-addon gstreamer-0_10-plugins-ffmpeg libdvdcss2

Экспериментальным путём также выяснено, что для работы Amarok также требуется пакет gstreamer-0_10-plugins-fluendo_mp3

среда, 17 июля 2013 г.

openSUSE 12.3 за прокси

Нижеописанное является вольным переводом статьи "OpenSUSE 12.3 Behind a Proxy", автором которой является Mel Kham.



Вопрос!

Как сделать так, чтобы openSUSE работала используя прокси? В моём случае прокси есть на рабочем месте и используется в компании для доступа в интернет.

Попробуем некоторые настройки для работы с прокси

# yast2 --update


Отредактируем /etc/sysconfig/proxy

# vi /etc/sysconfig/proxy


Применим изменения к своему профилю:
# source /etc/sysconfig/proxy

И попробуем установить какие-нибудь пакеты:
# zypper install php

Работает!

В режиме графического окружения пользователя

Приложения -> Система -> Центр управления (YaST). Выполнить поиск по "proxy".
Введите свои данные как показано на рисунке ниже.
Этот метод был протестирован на моей openSUSE 12.3 и прекрасно работает. Если у вас есть трудности, пожалуйста, опишите их в комментариях.

пятница, 14 июня 2013 г.

Предстоящие изменения в репозиториях KDE в openSUSE

Нижеописанное является вольным переводом статьи "Upcoming changes to openSUSE KDE repositories", автором которой является Luca Beltrame.


С выходом бета-версии KDE 4.11 в репозиториях openSUSE произойдут некоторые изменения.
Вкратце:

  • KDE:Distro:Factory будет содержать бета-версии и кандидаты в релизы 4.11. Эти версии пакетов рекомендуется использовать для тестирования и отправки сообщений об ошибках в KDE.
  • KDE:Release:410 отделена от KDE:Distro:Factory. Если вы используете KDE версии 4.10.x из репозитория KDF (KDE:Distro:Factory), то рекомендуется переключиться на репозиторий KDE:Release:410.
  • KDE:Unstable:SC не поменяется и будет далее хранить снимки из git репозиториев KDE.
Если вы тестируете 4.11, сообщайте об ошибках в пакетах (или других специфичных именно для openSUSE) в систему отслеживания ошибок Novell, и программных ошибках KDE в систему отслеживания ошибок KDE. Также для обсуждения проблем приветствуется использование специально созданной ветки форума сообщества KDE.
Да начнётся тестирование!

четверг, 7 марта 2013 г.

Установка Google Music Manager в openSUSE

Испробовано на версиях oS 12.1 - 12.3 x64. Собственно установка очень проста, но имеет пару затруднений:
  1. google-musicmanager-beta-1.0.55.7425 требует наличия какого-то qtwebkit.
  2. Используя PackageKit и ему подобных, требование это невозможно проигнорировать. Apper в этом случае информирует о том, что не может установить требуемые зависимости и остаётся только "Закрыть".
Устанавливать нужно с помощью zypper, либо rpm с игнорированием зависимости:
sudo zypper in Программное\ обеспечение/Linux/google-musicmanager-beta_current_x86_64.rpm 
root's password:
Загрузка данных о репозиториях...
Чтение установленных пакетов...
Разрешение зависимостей пакетов...

Проблема: ничто не предоставляет qtwebkit, необходимый для google-musicmanager-beta-1.0.55.7425-0.x86_64
 Решение 1: не устанавливать google-musicmanager-beta-1.0.55.7425-0.x86_64
 Решение 2: повредить google-musicmanager-beta-1.0.55.7425-0.x86_64, игнорируя некоторые из его зависимостей

Выберите по номеру одно из вышеуказанных решений или отмените [1/2/c] (c): 2
Разрешение зависимостей...
Разрешение зависимостей пакетов...

Будет установлен следующий НОВЫЙ пакет:
  google-musicmanager-beta 

1 новый пакет для установки.
Полный размер загрузки: 4,1 MiB. После этой операции будет использовано дополнительно 11,5 MiB.
Продолжить? [y/n/?] (y): 
Получение пакет google-musicmanager-beta-1.0.55.7425-0.x86_64             (1/1),   4,1 MiB ( 11,5 MiB после распаковки)
(1/1) Установка: google-musicmanager-beta-1.0.55.7425-0 .......................................................[готово]
Дополнительный вывод rpm:
warning: commands will be executed using /bin/sh
job 4 at 2013-03-08 02:49

суббота, 15 декабря 2012 г.

Половина крупнейших суперкомпьютерных кластеров работают под управлением SUSE Linux

Статья представляет из себя интервью с Andreas Jaeger, который отвечает на довольно любопытные вопросы, которые часто встречались мне в рунете особенно в период продажи компании Novell. Так что, на мой взгляд, достойно перевода. Уточнения, указания на ошибки и предложения исправлений приветствуются. Источник вот.

Andreas Jaeger был недавно назначен продукт-менеджером SUSE, поэтому мы поговорили с ним о его новой роли, о взаимоотношениях между SUSE и сообществом openSUSE, о SUSE после продажи и многом другом.

Muktware: Можешь рассказать нам об отношениях между компанией SUSE и сообществом openSUSE? Как устанавливает отношения SUSE и командой openSUSE?

AJ: openSUSE это Open Source проект, которым управляют и занимаются люди, которые регулируются Советом openSUSE, где председатель назначается SUSE, а все остальные избираются (прим. пер.: избираются сообществом). Многие из занимающихся openSUSE людей являются сотрудниками SUSE и SUSE основной спонсор проекта.
openSUSE - стабильный вышестоящий по разработке проект для продуктов SUSE Linux Enterprise. Координирование происходит в зависимости от участников и команд. openSUSE делает то, что хорошо для пользователей и активных участников, и, таким образом, некоторые решения принятые в openSUSE могут отличаться от того, что будет позже в SUSE Linux Enterprise.
Muktware: На сколько независим openSUSE в управлении и развитии проектов?Или, другими словами, на сколько велико влияние SUSE на развитие openSUSE?
AJ: Председатель совета назначаемый SUSE имеет право вето, но никогда его до сих пор не использовал. Совет также не контролирует проект, но в большинстве случаев занимается разрешением конфликтов и руководит им. Как и в большинстве Open Source проектов, независимость openSUSE заключается в отдельных разработчиках - если кому-то нравится что-то делать, она или он могут делать это и продвигать вперёд. Таким образом, влияние SUSE проходит только на инженеров занимающихся openSUSE.
Muktware: Что-нибудь изменилось после поглощения SUSE?
AJ: Поглощение SUSE The Attachmate Group произошло год или полтора года назад, и теперь SUSE является самостоятельным подразделением. Это дало SUSE больше контроля над бизнес направлением и изучением рынка, и позволило нам выйти на такие новые рынки как облачные вычисления. В результате наш бизнес растёт более быстрыми темпами.
Одним из основных изменений является повторное появление бренда SUSE. Сейчас он сам себя представляет на www.suse.com, имеет обновлённый логотип и слоган (Мы приспосабливаемся. Вы преуспеваете). Также мы недавно провели нашу первую конференцию пользователей (SUSECon 12) в сочетании с первой встречей пользователей openSUSE в Северной Америке.
Muktware: Можешь рассказать о своей новой роли и обязанностях в SUSE?
AJ: Как продукт-менеджер, я часть команды управляющих продуктами SUSE и связан с SUSE Linux Enterprise 12, SUSE Cloud и SUSE Studio, а также с инструментарием (библиотека C, отладчик, компилятор, ...).
Muktware: Каков текущий рынок у SUSE? Можешь рассказать о его доле на рынке Linux серверов? Можешь рассказать о рынке распространения по стране? На каком бизнесе SUSE держатся основные клиенты?
AJ: Есть отличная листовка на которой отмечены некоторые области где лидирует SUSE (см. https://www.suse.com/promo/suse-leadership.html). Например, 80 % всех мейнфреймов с Linux работают под SUSE Linux Enterprise, 70 % из развёрнутых SAP на Linux используют SUSE Linux Enterprise, или половина из крупнейших мировых кластерных суперкомпьютеров управляются SUSE Linux. Некоторые ключевые отрасли промышленности включая автомобильную и розничную торговлю.
Muktware: Какова доля из Linux серверов?
AJ: На самом деле это вопрос к IDC или Gartner, не для нас. После того как бизнес снова стал независимым, мы видим хороший рост.
Muktware: Вы смотрите на Red Hat и Canonical как на партнёров или конкурентов? Можешь рассказать об уровне взаимодействия между этими двумя компаниями?
AJ: На самом деле всё зависит от точки зрения. С точки зрения инженеров - партнёрские, так как инженеры разных Open Source компаний работают над улучшением Linux и свободного программного обеспечения совместно. Например, я один из разработчиков glibc и между активными участниками здесь хорошие партнёрские отношения. С точки зрения продавцов, отношения конкурентные.
Muktware: Какую роль играет UEFI Secure boot в корпоративном секторе? Как SUSE/Red Hat справляются с этим? Что скажешь о подходе Canonical?
AJFedora и Red Hat сделали первую реализацию защищённой загрузки, в SUSE это улучшили, а сейчас инженеры обеих команд работают совместно над улучшением ситуации.
Muktware: Какова стратегия SUSE относительно "облаков"? Можешь рассказать нам что-нибудь о корпоративном классе продуктов?
AJ: В рамках перезапуска SUSE как независимой бизнес единицы, мы ставим облачные вычисления в один ряд с двумя основными стратегическими областями (две другие это Enterprise Linux и интегрированные системы). Наше направление по "облакам" состоит из трёх компонентов:
  • Public Cloud - У нас первый Linux, который будет продаваться в составе Amazon EC2, а SUSE Linux доступен в более чем 20-ти глобальных публичных "облаках".
  • Private Cloud - В августе мы анонсировали выпуск SUSE Cloud 1.0. Это предложение ориентировано на клиентов, которые хотят разворачивать свою собственную инфраструктуру как сервисное решение. Это первый промышленный продукт с поддержкой, основанный на OpenStack и предназначенный для упрощение установки.
  • Cloud Management tools - Мы планируем тесно интегрировать SUSE Studio, SUSE Manager и SUSE Cloud для того, чтобы дать клиентам инструменты помогающие им создавать, разворачивать, управлять и поддерживать настроенные рабочие образы в частных и публичных облаках.
Muktware: Какую роль играет SUSE в общем развитии ядра Linux и программного окружения?
AJ: Инженеры SUSE содействуют развитию очень многих проектов и играют ключевую роль, например, для ядра или LibreOffice.

четверг, 6 сентября 2012 г.

Отключаем сообщения о "марсианских" пакетах

Заглянув в dmesg|tail хотел увидеть как система отреагировала на подключение флешки, но не тут то было... Всё зафлудили сообщения о "марсианских" пакетах. Это те, что начинаются на "martian source ...". Поэтому далее последует инструкция по полному отключению журналирования данных записей.
Смотрим все возможные параметры, связанные с "марсианами":

# /sbin/sysctl -a|grep martian
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
net.ipv4.conf.lo.log_martians = 1
net.ipv4.conf.eth0.log_martians = 1
net.ipv4.conf.vboxnet0.log_martians = 1
net.ipv4.conf.dsl0.log_martians = 1
Заносим их в /etc/sysctl.conf и меняем значение 1 на 0. У меня получилось так:

# DEATH MARTIANS!
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.default.log_martians = 0
net.ipv4.conf.lo.log_martians = 0
net.ipv4.conf.eth0.log_martians = 0
net.ipv4.conf.vboxnet0.log_martians = 0
net.ipv4.conf.dsl0.log_martians = 0
net.ipv4.conf.all.rp_filter = 0
Делается это для того, чтобы при следующей загрузке они не "ожили" вновь.
Ну и подгружаем эти значения командами

# /sbin/sysctl -p
/sbin/chkconfig boot.sysctl on
Проверить работоспособность вышеописанного можно с помощью выполнения первой команды.

Примечание:
В openSUSE это не возымеет вообще никакого эффекта, пока вы не поменяете в в файле /etc/sysconfig/SuSEfirewall2 значение FW_KERNEL_SECURITY с YES на NO. Смысл этого действа прокомментирован в этом же файле.

Дополнительные ссылки:
1. http://forum.alliedtelesis.ru/viewtopic.php?p=387&sid=d184dae62c99a95bb1ff162ce9682d13
2. http://baud123.free.fr/eagle/Mars_Attacks.txt
3. http://forums.opensuse.org/archives/sf-archives/archives-network-internet/327784-martian-source.html
4. http://forums.opensuse.org/forums/english/get-technical-help-here/network-internet/387258-martian-sources.html

воскресенье, 3 июня 2012 г.

Прошивка устройств на Android из openSUSE

Намучавшись с неофициальной прошивкой Android'a 2.2 для своего LG GT540, решил вернуться к наиболее ближайшей к оригиналу версии 2.1. Поскольку достопочтеннейшая компания LG Electronics не сочла необходимым делать программное обеспечение кроме как для Windows, то выбирать между официальными и неофициальными прошивками мне не приходится. Прошивать смартфон я буду прошивкой Quarx custom for LG GT540 с помощью fastboot и надеюсь описанное сможет послужить не только памяткой лично мне на будущее, но и полезной информацией владельцам устройств на Android и ПК на openSUSE.


Препарация


Первое что абсолютно необходимо при прошивке с помощью fastboot это android-sdk, который для openSUSE можно взять в единственном на весь OBS репозитории home:digitaltomm. Единственная и главная ссылка на одноклик для разных версий openSUSE, кроме Tumbleweed, может быть найдена на странице результатов поиска android-sdk.
Получив пакет android-sdk у вас будет правило udev для подключения смартфона в нужном режиме (recovery), утилиты adb и собственно fastboot.


Собственно прошивка


Далее, что очевидно, вы должны переключить устройство в тот самый recovery режим.
Примечание: для входа в recovery режим вы уже должны иметь прошивку с такой функцией. Обычно для этого служит определённая комбинация клавиш, у меня это CAMERA+POWER во время загрузки. При этом нужно, чтобы устройство уже было подключено по кабелю к ПК. Если это произошло без подключения по кабелю, то можно просто вынуть аккумулятор из девайса и попробовать сделать всё правильно ещё раз.

Время командовать! Очистка кэша и данных пользователя:
fastboot -w
Очистка системного раздела:
fastboot erase system
Прошивка системного раздела специально подготовленным образом:
fastboot flash system system.img
Прошивка загрузочной области (при обновлении ядра например):
fastboot flash boot boot.img
И наконец перезагрузка устройства:
reboot


На этом всё. Устройство должно загрузиться с новоиспечённой прошивкой.

четверг, 31 мая 2012 г.

Автоматическое выполнение prelink по расписанию

Как ни странно, начитавшись статей типа Ускорение openSUSE: prelink и Сокращение времени загрузки Fedora 17 c 15 до 3 секунд можно обнаружить, что запускать prelink постоянно вручную довольно "не кошерно". Этак надо у себя прививать новую привычку (можно, например, даже напоминание на мобильнике устанавливать).
Мейнтейнеры некоторых дистрибутивов это осознали и начали добавлять в пакеты специальный скрипт для планировщика задач cron и для значительного упрощения своей участи пользователи prelink могут этот скрипт коварно позаимствовать. С поисками далеко идти не нужно - достаточно взять файл prelink.cron из prelink-0.4.5-4.fc17.src.rpm и немного исправить.

Пошагово:

Для ежедневного выполнения prelink, данный файл нужно скопировать в /etc/cron.daily/ и дать права на выполнение:

chmod +x /etc/cron.daily/prelink.cron

Отредактировать скрипт, чтобы он использовал переменные из файла /etc/sysconfig/prelink специфичные для openSUSE. Содержимое его при этом становится таким:

#!/bin/sh

. /etc/sysconfig/prelink

renice +19 -p $$ >/dev/null 2>&1

if [ "$USE_PRELINK" != yes ]; then
  if [ -f /etc/prelink.cache ]; then
    /usr/sbin/prelink -ua 2>&1
    rm -f /etc/prelink.cache
    # Restart init if needed
    [ -n "$(find `ldd /sbin/init | awk 'NF == 4 { print $3 }'` /sbin/init -ctime -1 2>/dev/null )" ] && /sbin/telinit u
  fi
  exit 0
fi

if [ ! -f /etc/prelink.cache -o -f /var/lib/prelink/force ] \
   || grep -q '^prelink-ELF0.[0-2]' /etc/prelink.cache; then
  # If cache does not exist or is from older prelink versions or
  # if we were asked to explicitely, force full prelinking
  rm -f /etc/prelink.cache /var/lib/prelink/force
  PRELINK_OPTS="$PRELINK_OPTS -f"

/usr/sbin/prelink -a 2>&1
# Restart init if needed
[ -n "$(find `ldd /sbin/init | awk 'NF == 4 { print $3 }'` /sbin/init -ctime -1 2>/dev/null )" ] && /sbin/telinit u
fi
exit 0

Убедитесь, что cron запущен, чтобы не было недоразумений:

systemctl status cron.service

Согласно данным из /etc/sysconfig/cron, prelink.cron будет выполняться через 15 минут после загрузки системы, а в следующий раз через 24 часа и так далее.

Дополнительно к этому можно выставить параметру USE_PRELINK в файле /etc/sysconfig/prelink значение "yes", чтобы prelink автоматически запускался после каждого выполнения SuSEconfig, который выполняется, например, после обновления многих системных пакетов, да и вообще после операций с пакетами в YaST2. Сделать это можно как с помощью любимого текстового редактора, так и модуля YaST2  "редактор /etc/sysconfig".

вторник, 29 мая 2012 г.

systemd и скрипт after.local

Не так давно писал про сервисы и демоны в Linux, где присутствует стартовый скрипт /etc/init.d/after.local из openSUSE.
Но пытаясь остановить bootchart с помощью этого скрипта, оказалось, что со всеми любимым systemd, after.local никакого эффекта не имеет вовсе, что мне даже подтвердили в bugzilla. Однако, jdmcdaniel3 описал как всё-таки подружить systemd и after.local.

Всё сводится к трём шагам:

1. Создать /lib/systemd/system/after-local.service со следующим содержимым:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 2 of the License, or
#  (at your option) any later version.

[Unit]
Description=/etc/init.d/after.local Compatibility
ConditionFileIsExecutable=/etc/init.d/after.local

[Service]
Type=oneshot
ExecStart=/etc/init.d/after.local
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
SysVStartPriority=99

[Install]
WantedBy=multi-user.target


2. Собственно добавить after-local.service в автозагрузку, чтоб systemd понимал, что от него требуется:

systemctl enable /lib/systemd/system/after-local.service


3. Отредактировать /etc/init.d/after.local, вписав туда то, что вам нужно.
 

вторник, 22 мая 2012 г.

Измерение скорости загрузки openSUSE

В отличие от Arch Linux, использование bootchart в openSUSE даже не требуется для того, чтобы увидеть красивый график загрузки или узнать точное её время, так как этот функционал уже по умолчанию содержит в себе всеми любимый systemd.

Так, чтобы время загрузки достаточно ввести

systemd-analyze


А команда

systemd-analyze blame

покажет сколько времени забирают различные сервисы

И последнее, что казалось бы, нужно для счастья - построение графика. За это отвечает команда

systemd-analyze plot > plot.svg


При желании, полученный svg файл можно сконвертировать в png формат командой

rsvg-convert plot.svg -o plot.png



Примечание:


Мой график получился следующим:
Скорость загрузки составила 31 секунду с копейками. Стоит отметить, что в 2010-м году на компьютере с одноядерным процессором, жёстким диском PATA (IDE) и с Arch Linux на борту я получил результат загрузки в 26 секунд, который позже был улучшен до 21-й с помощью параллелизации загрузки демонов. То есть ровно на 10 секунд быстрее, чем сейчас. При этом Arch Linux сейчас активно готовится к внедрению systemd в качестве базового компонента по умолчанию... Лично для меня скорость загрузки теперь это ещё один камень в огород systemd при обещанном им турбо-ускорении.

воскресенье, 20 мая 2012 г.

Монтирование съёмных устройств в XFCE 4.10 (заметка)

Установил XFCE 4.10 из репозитория 'X11:xfce'. Странное дело, но thunar не отображал подключенные съёмные носители до установки gvfs, gvfs-backends, gvfs-fuse.
После чего возникла проблема вида воспрещения доступа из thunar к этим самым съёмным устройствам с запросом пароля root и сообщением при отказе его ввести "not authorized". Много всего было перепробовано, например:
~/.xinitrc следующего содержания:

#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

exec ck-launch-session dbus-launch startxfce4
thunar --daemon &
EOF
chown $var_username:users /home/$var_username/.xinitrc

/etc/polkit-1/localauthority.conf.d/10-storage-group-mount-override.pkla с правилом для polkit'a:

[storage group mount override]
Identity=unix-group:users
Action=org.freedesktop.udisks.filesystem-mount
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Добавлением пользователя в группу "disk".
Но помогло как раз удаление ~/.xinitrc

Не легка жизнь в XFCE...

суббота, 19 мая 2012 г.

Настройки zypper в деталях

Дистрибутивы SUSE/openSUSE используют в работе консольный менеджер пакетов zypper, настройки которого скрыты далеко от глаз пользователя и далее мы рассмотрим их.
zypper работает на базе движка ZYpp (или libzypp) и поэтому имеется два конфигурационных файла, это /etc/zypp/zypp.conf и /etc/zypp/zypper.conf
Рассмотрим, что можно сделать с помощью того и другого.

zypp.conf

arch = s390
Параметр определяющий архитектуру процессора и, соответственно, того какие пакеты будет использовать zypper. По умолчанию архитектура определяется автоматически и менять значение данного параметра строго не рекомендуется. Если это всё же происходит, то придётся заново скачать и установить все пакеты, которые были установлены ранее и отличаются от заданной вновь архитектуры. Всё же это является способом для смены архитектуры всего установленного ПО в системе, к примеру, если вы установили сборку под i586, а ваш процессор поддерживает 64-хбитную архитектуру.

cachedir = /var/cache/zypp
Параметр отвечающий за местоположение кэша zypper. По умолчанию это /var/cache/zypp

metadatadir = /var/cache/zypp/raw
Каталог для хранения метаданных, которые загружаются из репозиториев. По умолчанию это {cachedir}/raw, где {cachedir} это значение параметра cachedir. Изменение значения требует последующего обновления и загрузки метаданных из всех подключенных репозиториев.

solvfilesdir = /var/cache/zypp/solv
Каталог для хранения файлов .solv, получаемых в результате обработки загруженных метаданных из репозиториев. По умолчанию это {cachedir}/solv, где {cachedir} это значение параметра cachedir.

packagesdir = /var/cache/zypp/packages
Путь к каталогу в котором будут храниться загружаемые пакеты. По умолчанию это {cachedir}/packages, где {cachedir} это значение параметра cachedir.

configdir = /etc/zypp
Каталог хранения конфигурационного файла. По умолчанию это /etc/zypp

reposdir = /etc/zypp/repos.d
Путь к каталогу, в котором должны храниться файлы .repo с данными подключенных репозиториев. Значение по умолчанию {configdir}/repos.d, где {configdir} это значение параметра configdir.

servicesdir = /etc/zypp/services.d
Каталог хранения файлов .service. По умолчанию это {configdir}/services.d, где {configdir} это значение параметра configdir.

repo.add.probe = false
Проверка доступа к репозиторию при его добавлении. По умолчанию отключена и проверка осуществляется при первом вызове команды zypper ref. Полезно включить, если у вас бывают проблемы с доступом к репозиториям.

repo.refresh.delay = 60
Параметр определяющий промежуток времени в минутах до следующего автообновления метаданных подключенных репозиториев. По умолчанию его значение равно 10 минутам. При значении 0, автообновление метаданных будет происходить каждый раз. Не влияет на то, будет происходить автообновление вообще или нет.

repo.refresh.locales = ru
Список локалей по которым zypper должен определять, описания пакетов на каком языке он должен получать с метаданными. Не все репозитории это поддерживают, а описания на английском языке загружаются в любом случае.

download.max_concurrent_connections = 5
Количество одновременных соединений при загрузке пакетов. По умолчанию значение равно 5.

download.min_download_speed = 0
Минимальная скорость загрузки (задаётся в байтах в секунду) перед разрывом соединения. Параметр может использоваться для предотвращения атак на серверы предоставляющие обновления на очень низкой скорости. По умолчанию ограничение не установлено.

download.max_download_speed = 0
Максимальная скорость загрузки (задаётся в байтах в секунду). Ограничения по умолчанию нет.

download.max_silent_tries = 5
Максимальное количество попыток подключения к репозиторию, которое автоматически будет производиться без обращения к пользователю.

download.use_deltarpm = true
Параметр отвечающий за то, отдавать предпочтения пакетам в .delta.rpm или простым .rpm пакетам. Использование .delta.rpm позволяет уменьшить нагрузку на сетевой трафик, но при этом создание пакета rpm для последующей установки будет производиться на локальной машине, что на короткое время увеличит нагрузку на оперативную память и процессор.

download.use_deltarpm.always = false
Параметр указывающий zypp всегда использовать deltarpm. Не имеет эффекта, если параметру download.use_deltarpm задано значение true.

download.media_preference = download
Параметр определяющий предпочтение источнику загрузки пакета при наличии одинаковой его версии в обоих типах источников. Источником для данного параметра служит web-репозитории и медиа-носитель (CD, DVD). Доступные значения для параметра - download (загружать из web-репозиториев) и volatile (предпочитать медиа-носитель). По умолчанию установлено первое. 

commit.downloadMode =
Политика транзакций zypp. Возможные значения:
DownloadOnly - только загружать пакеты в кэш без дальнейшей установки.
DownloadInAdvance - сначала загрузить все пакеты в кэш, потом начать установку.
DownloadInHeaps - порционная загрузка и установка пакетов

vendordir = /etc/zypp/vendors.d
Определение каталога содержащего файлы описаний специфичных для разных поставщиков типа nvidia. По умолчанию это {configdir}/vendor.d, где {configdir} это значение параметра configdir.

solver.onlyRequires = false
Устанавливать только необходимые зависимости пакетов. Параметр позволяющий избежать предложений установки рекомендуемых пакетов, в число которых входят языковые пакеты, а также требуемые для какого-либо аппаратного обеспечения. По умолчанию отключено.

solver.allowVendorChange = false
Разрешить по умолчанию смену поставщика при обновлении (действует как zypper dup вместо zypper up). Строго не рекомендуется к включению и по умолчанию отключено.

solver.cleandepsOnRemove = false
Параметр указывающий удалять зависимости пакета при его удалении. По умолчанию отключено и строго не рекомендуется.

solver.checkSystemFile = /etc/zypp/systemCheck
Файл содержащий список пакетов необходимых для работы запущенной системы. Служит для информирования пользователя при попытке удаления пакетов из системы, которые есть в списке. По умолчанию содержит только glibc и расположен в {configdir}/systemCheck, где {configdir} это значение параметра configdir.

solver.upgradeTestcasesToKeep = 2
Параметр указывающий сколько тестов разрешения зависимостей следует сохранять при апгрейде дистрибутива (так называется выполнение операции zypper dup). Тесты размещаются в /var/log/updateTestcase-, где - дата выполнения zypper dup. Результаты тестов разрешения зависимостей нужны, чтобы прилагать их к сообщениям об ошибках в https://bugzilla.novell.com/, в случае их возникновения. Чтобы отключить сохранение этих тестов, выставьте значение "0". Если хотите сохранять все отчёты о тестах, то следует выставить значение "-1". По умолчанию равно 2.

solver.upgradeRemoveDroppedPackages = true
Параметр предписывает удалять пакеты отсутствующие в репозиториях на момент выполнения апгрейда (zypper dup). По умолчанию включено.

multiversion = provides:multiversion(kernel)
Значение параметра определяет какие одинаковые пакеты имеющие разные версии могут быть установлены в систему. В значение принимается как название пакетов, так и то, что ими предоставляется. По умолчанию список пуст.

multiversion.kernels = latest,running
Список пакетов предоставляющих ядро Linux, которые могут сосуществовать в системе параллельно друг другу. По умолчанию не удаляется любое ядро, если в предыдущем параметре задано значение provides:multiversion(kernel). Пакеты могут определяться следующим образом:

2.6.32.12-0.7 - Определённая версия ядра
latest             - Последняя версия ядра
latest-N         - Последнее ядро имеющее версию, определённую вместо "N"
running         - Оставлять ядро, которое запущенно в данный момент
oldest           - Оставлять ядро с самой старой версией (так называемое GA (Genetic Algorithm) ядро)
oldest+N      - То же, что и предыдущее, но с определением версии ядра

locksfile.path = /etc/zypp/locks
Определение местоположения lock-файла. По умолчанию это {configdir}/locks, где {configdir} это значение параметра configdir. Значение может быть любым.

locksfile.apply = true
Блокирование lock-файла сразу после запуска zypp. По умолчанию включено.

update.datadir = /var/adm
Каталог в котором будут располагаться "элементы обновления". Под таковыми подразумеваются сообщения и скрипты. По умолчанию это каталог /var/adm.

update.messagesdir = /var/adm/update-messages
Каталог для хранения сообщений при обновлении. По умолчанию это {update.datadir}/update-messages, где {update.datadir} это значение параметра update.datadir.

update.scriptsdir = /var/adm/update-scripts
Каталог для хранения скриптов при обновлении. По умолчанию это {update.datadir}/update-scripts, где {update.datadir} это значение параметра update.datadir.

update.messages.notify = single | /usr/lib/zypp/notify-message -p %p
Параметр определяющий поведение zypp при работе с сообщениями, которые поступают от обновляемых пакетов. zypp может подготовить сообщение об обновлении и перенаправить его содержимое в выбранном формате на командную строку. Формат сообщений может быть следующим:
single - отправлять сообщение в командную строку по отношению к каждому сообщению об обновлении.
none   - не использовать перенаправление, сразу отправлять сообщение в командную строку.
digest - один вызов командной строки на все сообщения обновлений.
bulk   - один вызов командной строки на всё содержимое всех сообщений, разделяемых по нажатию Ctrl-L.

Возможные сокращения для подстановки:
%p     - идентификатор пакета вида название-версия-релиз.архитектура
%P     - полный путь к файлу с сообщениями обновлений

Значение по умолчанию: single | /usr/lib/zypp/notify-message -p %p

rpm.install.excludedocs = no
Исключить из устанавливаемых пакетов файлы документации. Позволяет немного сэкономить дисковое пространство. По умолчанию отключено.

history.logfile = /var/log/zypp/history
Местоположение файла для истории выполненных операций. Лог истории описан на странице http://en.opensuse.org/Libzypp/Package_History. По умолчанию это /var/log/zypp/history

credentials.global.dir = /etc/zypp/credentials.d
Каталог для хранения данных о полномочиях (credentials). По умолчанию это /etc/zypp/credentials.d

credentials.global.file = /etc/zypp/credentials.cat
Путь к файлу содержащему список пользователей вида логин:пароль для доступа к libzypp. По умолчанию это /etc/zypp/credentials.cat

zypper.conf

Конфигурационный файл непосредственно самого zypper может быть не только системным и располагаться в /etc/zypp/, но и пользовательским. Во втором случае он должен иметь путь $HOME/.zypper.conf


Секция [main]

showAlias = false
Отображать псевдоним репозитория вместо его названия. По умолчанию отключено.

repoListColumns = Anr
Столбцы, которые должны отображаться в выводе команды 'zypper lr' (вывести список всех репозиториев). Доступные значения (возможны любые их сочетания):

a - псевдоним репозитория
n - название репозитория
r - статус использования автообновления репозиторием
u - ссылка
p - приоритет
Номер и статус репозитория будут отображаться в любом случае. Значение по умолчанию: anr

Секция [solver]

installRecommends = no
Параметр отвечающий за установку мягких зависимостей (рекомендуемых пакетов). По умолчанию включено.

forceResolutionCommands = remove
Параметр указывает поведение zypper при разрешении зависимостей. По умолчанию происходит удаление. Возможные значения (могут быть просто перечислены): remove, install, update, patch, verify
При указанном вручную параметре --no-force-resolution, значение в конфигурационном файле эффекта не имеет.

Секция [color]

useColors = never
Параметр определяет использовать ли zypper цветовую окраску при выводе. Значение по умолчанию - never, то есть никогда не использовать. Кроме never возможны значения always (всегда) и autodetect (автоопределение).

background = dark
Значение определяет фон в выводе zypper. Доступны значения dark (тёмный) и light (светлый). По умолчанию фон тёмный (dark).

result = white
Цвет вывода результатов операций zypper. Доступные значения: любой цвет (по-английски).

msgStatus = grey
Цвет статусных сообщений и отображающегося прогресса выполнения операций. По умолчанию - серый (grey). Доступные значения: любой цвет (по-английски).

msgError = red
Цвет сообщений об ошибках. По умолчанию красный (red). Можно указать любой другой (по-английски).

msgWarning = yellow
Цвет предупреждений. По умолчанию жёлтый (yellow). Можно указать любой другой (по-английски).

highlight = lightcyan
Цвет подсветки вывода zypper. По умолчанию светло-голубой (lightcyan). Можно указать любой другой (по-английски).

promptOption = grey
Цвет диалогов. По умолчанию серый (grey). Можно указать любой другой (по-английски).

Секция [obs]

baseUrl = http://download.opensuse.org/repositories/
Базовый путь к репозиториям openSUSE Build Service. Используется при обработке таких запросов как obs://project/platform URI

platform = openSUSE_11.3
Целевая платформа для репозиториев openSUSE Build Service. Используется при обработке таких запросов как obs://project/platform URI


Словарь терминов:


Service - клиентская часть протокола Repository Index Service (RIS) для управления пакетами. Repository Index Service (RIS) в отличие от обычного репозитория может предлагать более одного репозитория программного обеспечения, которые в свою очередь могут быть изменены администратором или поставщиком сервиса. Repository Index Service является расширением службы Novell Update специально для управления обновлениями SUSE Linux Enterprise.

Product - группа пакетов необходимая для установки определённого продукта (такого как openSUSE, openSUSE-Addon-NonOss или codecs-set).


Дополнительные ресурсы информации:


воскресенье, 6 мая 2012 г.

Создание резервной копии корневого раздела в режиме rw

Способы сделать резервную копию корневого раздела, который находится в режиме чтения-записи и активно используется:

  • С помощью tar:

# tar --one-file-system -jcf /mnt/another/backup.tar.bzip2 /


Затарит, после чего сожмёт с помощью bzip2.
Аналогичным образом можно сделать бэкап сжатый gzip:

# tar --one-file-system -zcf /mnt/another/backup.tar.gzip /


А можно вообще ничем не сжимать:

# tar --one-file-system -cf /mnt/another/backup.tar /



  • С помощью fsarchiver:

# fsarchiver savefs -Aaz 9 /mnt/another/backup.fsa /dev/sda1


Получается архив lzma максимального сжатия. Опции "A" и "a" указывают не обращать внимания на то, что раздел смонтирован rw и не использовать Acl и user-xattr. Минус данного способа очевиден: нужно иметь fsarchiver на live cd, если разворачивать бэкап предполагается с него.

  • С помощью cp
Как ни странно бэкап можно сделать простым копированием:

# cp -ax / /mnt/another/backup


Плюс такого метода очевиден - скорость работы, но бэкап опять же получается не сжатым и будет занимать ценные гигабайты. 
-a, --archive
По возможности сохраняет структуру и атрибуты исходных файлов при копировании (но не сохраняет структуру каталогов). Эквивалентно заданию опций -dpPR.
-x, --one-file-system
Пропускать подкаталоги, которые расположены на файловых системах, отличных от той, где начиналось копирование.


  • С помощью YaST(2)

Для YaST2 существует модуль yast2-backup, посредством которого возможно создание резервных копий довольно в простом и удобном способе. Примечание: если вы собираетесь не только создавать резервные копии, но и восстанавливать когда-нибудь из них то, что зарезервировано, то логично будет также установить модуль yast2-restore. Рассмотрим создание резервной копии корневого раздела с ручным запуском:
Запустите YaST и в разделе "Система" зайдите в модуль "Резервирование системы":
Добавьте новый профиль из меню кнопки управления профилями. Профиль можно назвать, например, "system backup" (только без кавычек). Следующим шагом будет указание расположения архива с резервной копией и выбор типа архива:
В следующем окне ничего изменять не требуется, если только вы не знаете точно что вам это действительно нужно:
Шаг 3-й и последний - ограничение поиска. Здесь можно задать исключения, например, добавить каталог /home:
Вы вернётесь к главному окну, где выбрав созданный профиль, можно будет создать резервную копию простым нажатием одноимённой кнопки.

Дополнительная информация:

вторник, 1 мая 2012 г.

Замена репозиториев openSUSE зеркалами

download.opensuse.org

Как сообщил Will Stephenson download.opensuse.org отмечает 1-е мая. То есть, к сожалению, ещё не совсем оправился после внезапной и трагической смерти двух жёстких дисков обеспечивающих его работу. Рекомендуется использовать зеркала для доступа к пакетной базе репозиториев. Список зеркал можно найти здесь.

Информация для тех, кто не знает как заменить адрес репозитория на его зеркало:

Для замены адреса репозитория на его зеркало, запустите YaST2, либо yast и зайдите в модкль управления репозиториями программного обеспечения:
Выберите репозиторий и нажмите на кнопку "Редактировать":
В открывшемся окне "Сервер и каталог" при выбранном пункте замените "Редактировать весь URL" замените download.opensuse.org на адрес из нового зеркала, например, mirror.yandex.ru/opensuse (я использую зеркала Яндекса, потому что Яндекс локален для моего провайдера)
Аналогично нужно поступить со всеми остальными репозиториями. Данную операцию также можно проводить путём редактирования файлов *.repo находящихся в /etc/zypp/repos.d

Packman

packman.inode.at в не рабочем состоянии и список его зеркал вы можете найти здесь. В списке кстати почему-то отсутствует зеркало packman на Яндексе, которое даёт определённые преимущества для пользователей в России. А вот скрипт на перле от Pascal Bleser для замены адреса репозитория packman:
perl -p -i.old -e \
's,^(baseurl=).*(/suse/.+)$,${1}http://ftp.halifax.rwth-aachen.de/packman${2}, if /^baseurl=.*packman\.inode\.at.*/' \
/etc/zypp/repos.d/*packman*.repo

суббота, 28 апреля 2012 г.

Packman обзавёлся багтрекером

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

Об этом сообщает Pascal Bleser в своём блоге.