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

среда, 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 и прекрасно работает. Если у вас есть трудности, пожалуйста, опишите их в комментариях.

четверг, 18 апреля 2013 г.

Розыгрыш призов от SUSE

+SUSE проводит розыгрыш призов. Для участия нужно подписаться на новостную рассылку "SUSE Conversations" до 31-го мая.


Источник тут.

суббота, 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.

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

Анонсирован SUSE Manager Management Pack для Microsoft System Center

Интересная новость, которую почему-то проигнорировали новостные ленты рунета.


Сегодня на конференции Open Source Business Conference, SUSE и Microsoft анонсировали бета-версию последнего проекта совместимости компаний давнего альянса. Для платформы Microsoft - System Center теперь предоставляется SUSE Manager Management Pack. В результате, клиенты, использующие Microsoft System Center смогут управлять как Windows, так и Linux с помощью единой консоли управления.

SUSE и Microsoft идут на этот шаг, чтобы решить проблемы совместимости при работе в облаке. SUSE Manager позволит клиентам решить вопрос нагрузки в Linux без потери контроля.

SUSE Manager Management Pack для Microsoft System Center предлагается к свободной загрузке в целях тестирования здесь.



суббота, 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).


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