Настройка сетевой карты rosa. Ос роса fresh r8 соединение сети есть но трафик не проходит

Настройка сетевой карты rosa

13.2. Настройка сетевых интерфейсов

Интерфейсом с точки зрения ОС является устройство, через которое система получает и передает IP-пакеты. Роль интерфейса локальной сети может выполнять одно (или несколько) из следующих устройств: Ethernet-карта, ISDN-адаптер или модем, подключенный к последовательному порту. Каждое устройство (не весь компьютер!) имеет свой IP-адрес. Для выхода в локальные сети используется, как правило, Ethernet-карта, что и будет предполагаться в настоящем разделе. Заодно мы рассмотрим и настройку модемного интерфейса, поскольку настраивается он вполне аналогично, и знания о методах его настройки будут необходимы нам при рассмотрении вопроса о выходе в Интернет в Гл. 14

13.2. 1 Расположение конфигурационных файлов

Отметим сразу, что все приводимые ниже команды можно выполнять из командной строки, но тогда придется повторять эти операции при каждом перезапуске компьютера. Поэтому может быть удобнее записать их в один из инициализационных файлов, автоматически запускаемых при старте системы. В разных дистрибутивах процесс загрузки организован по-разному. В "Linux NET-3-HOWTO" приводится следующая таблица:

Таблица 13.1. Расположение конфигурационных файлов в основных дистрибутивах

Настройка интерфейса и маршрутизации

/etc/init. d/netbase /etc/init. d/netstd_init /etc/init. d/netstd_nfs /etc/init. d/netstd_misc

Обратите внимание, что дистрибутивы Debian и Red Hat содержат отдельный каталог для скриптов запуска системных сервисов (хотя сами файлы настроек находятся в других местах, например, в дистрибутиве Red Hat они хранятся в каталоге /etc/sysconfig). Для понимания процесса загрузки ознакомьтесь с содержимым файла / etc/inittab и документацией по процессу Init .

13.2.2 Команда ifconfig

После подключения драйверов вы должны настроить те интерфейсы, которые вы предполагаете использовать. Настройка интерфейса заключается в присвоении IP-адресов сетевому устройству и установке нужных значений для других параметров сетевого подключения. Наиболее часто для этого используется программа Ifconfig (ее название происходит от "interface configuration").

Запустите ее без аргументов (или с единственным аргументом -a ) и вы узнаете, какие параметры установлены в данный момент для активных сетевых интерфейсов (в частности, для сетевой карты). Кстати, имеет смысл выполнить эту команду еще до подключения модулей: а вдруг у вас поддержка интерфейсов встроена в ядро и необходимые настройки сделаны в процессе инсталляции системы. Тогда вы в ответ можете получить информацию о параметрах вашей Ethernet-карты и так называемого "кольцевого интерфейса" или "обратной петли" — Local Loopback (интерфейс Ethernet при единственной сетевой карте обозначается как eth0, а кольцевой интерфейс — как lo). Если же по этой команде вы ничего не получите, то надо переходить к подключению модулей и настройке, и начинать надо с кольцевого интерфейса.

Настройка локального интерфейса lo

Этот интерфейс используется для связи программ IP-клиентов с IP-серверами, запущенными на той же машине, так что его необходимо настроить даже в том случае, если вы вообще не подключаете никаких сетевых устройств.

Локальный интерфейс настраивается очень просто: командой

[root]# /sbin/ifconfig lo 127.0.0.1

Теперь, чтобы проверить работоспособность протоколов TCP/IP на вашей машине, дайте команду:

[root]# ping 127.0.0.1

Настройка интерфейса платы Ethernet локальной сети (eth0)

Для того чтобы ваш компьютер вошел в сеть с IP-адресом, полученным вами у администратора (пусть для примера это будет адрес 192.168.0.15), вы должны запустить команду Ifconfig примерно следующим образом:

[root]# /sbin/ifconfig eth0 192.168.0.15 netmask 255.255.255.0 up

Если не указывать маску подсети, то по умолчанию устанавливается маска подсети 255.0.0.0.

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

Root# /sbin/ifconfig eth0 irq 5 io_addr 220 media 10baseT

Не все устройства (платы) поддерживают динамическое изменение этих параметров (т. е. может потребоваться переустановить переключатели на плате).

Интерфейс для последовательного порта

Последовательный порт используется для подключения модема, через который осуществляется соединение с сетью по телефонной линии. Для настройки интерфейса этого типа тоже можно использовать программу Ifconfig. Однако, такие программы как Pppd и Dip. используемые для соединения с сетью по модему, способны автоматически конфигурировать сетевой интерфейс, поэтому обычно для этого случая применять Ifconfig не требуется.

13.2. 3 Настройка маршрутизации

Правила маршрутизации определяют, куда отправлять IP-пакеты. Данные маршрутизации хранятся в одной из таблиц ядра. Вести таблицы маршрутизации можно статически или динамически. Статический маршрут — это маршрут, который задается явно с помощью команды Route. Динамическая маршрутизация выполняется процессом-демоном ( Routed или Gated ), который ведет и модифицирует таблицу маршрутизации на основе сообщений от других компьютеров сети. Для выполнения динамической маршрутизации разработаны специальные протоколы: RIP, OSPF, IGRP, EGP, BGP и т. д.

Динамическая маршрутизация необходима в том случае, если у вас сложная, постоянно меняющаяся структура сети и одна и та же машина может быть доступна по различным интерфейсам (например, через разные Ethernet или SLIP интерфейсы). Маршруты, заданные статически, обычно не меняются, даже если используется динамическая маршрутизация.

Для персонального компьютера, подключаемого к локальной сети, в большинстве ситуаций бывает достаточно статической маршрутизации командой Route. Прежде чем пытаться настраивать маршруты, просмотрите таблицу маршрутизации ядра с помощью команды Netstat — n — r. Вы должны увидеть что-то вроде следующего

[root]# netstat — nr

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

10.72.128.101 0.0.0.0 255.255.255.255 UH 0 0 0 eth0

10.72.128.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

0.0.0.0 10.72.128.254 0.0.0.0 UG 0 0 0 eth0

Если таблица пуста, то вы увидите только заголовки столбцов. Тогда надо использовать Route. С помощью команды Route можно добавить или удалить один (за один раз) статический маршрут. Вот ее формат:

[root]# /sbin/route [-f] операция [-тип] адресат шлюз [dev] интерфейс

Здесь аргумент Операция может принимать одно из двух значений: Add (маршрут добавляется) или Delete (маршрут удаляется). Аргумент Адресат может быть IP-адресом машины, IP-адресом сети или ключевым словом Default. Аргумент Шлюз — это IP-адрес компьютера, на который следует пересылать пакет (этот компьютер должен иметь прямую связь с вашим компьютером). Команда

[root]# /sbin/route — f

Удаляет из таблицы данные обо всех шлюзах. Необязательный аргумент Тип принимает значения Net или Host. В первом случае в поле адресата указывается адрес сети, а во втором — адрес конкретного компьютера (хоста).

Как правило, бывает необходимо настроить маршрутизацию по упоминавшимся выше трем интерфейсам:

локальный интерфейс (lo), интерфейс для платы Ethetnet (eth0), интерфейс для последовательного порта (PPP или SLIP).

Локальный интерфейс поддерживает сеть с IP-номером 127.0.0.1. Поэтому для маршрутизации пакетов с адресом 127. используется команда:

[root]# /sbin/route add — net 127.0.0.1 lo

Если у вас для связи с локальной сетью используется одна плата Ethernet, и все машины находятся в этой сети (сетевая маска 255.255.255.0), то для настройки маршрутизации достаточно вызвать:

[root]# /sbin/route add — net 192.168.36.0 netmask 255.255.255.0 eth0

Если же вы имеете насколько интерфейсов, то вам надо определиться с сетевой маской и вызвать команду Route для каждого интерфейса.

Поскольку очень часто IP-пакеты с вашего компьютера могут отправляться не в одну единственную сеть, а в разные сети (например, при просмотре разных сайтов в Интернете), то в принципе надо было бы задать очень много маршрутов. Очевидно, что сделать это было бы очень сложно, точнее просто невозможно. Поэтому решение проблемы маршрутизации пакетов перекладывают на плечи специальных компьютеров — маршрутизаторов, а на обычных компьютерах задают маршрут по умолчанию, который используется для отправки всех пакетов, не указанных явно в таблице маршрутизации. С помощью маршрута по умолчанию вы говорите ядру "а все остальное отправляй туда". Маршрут по умолчанию настраивается следующей командой:

[root]# /sbin/route add default gw 192.168.1.1 eth0

Опция gw указывает программе Route. что следующий аргумент — это IP-адрес или имя маршрутизатора, на который надо отправлять все пакеты, соответствующие этой строке таблицы маршрутизации.

После настройки маршрутизации можно проверить, что у вас получилось. Для этого снова дайте команду

[root]# netstat — nr

Если вывод команды выглядит так, как это было показано выше, но не содержит строки, которая в графе Destination содержит 0.0.0.0. а в графе Gateway указывает на маршрут, используемый для соединений по умолчанию, то вы, вероятно, не задали этот маршрут.

13.2.4. Настройка службы имен

С помощью команды Ifconfig вы задали IP-адрес вашего компьютера, но он еще не знает своего имени (при инсталляции системы он получил обезличенное имя localhost). Существует команда Hostname. которая позволяет установить (и узнать действующее в данный момент) имя компьютера и имя домена.

Однако установить только имя и только этой командой еще недостаточно, поскольку эта команда меняет имя только на текущий сеанс работы. Поэтому обычно эта команда вызывается в одном из инициализационных файлов, например, /etc/rc. d/rc или /etc/rc. d/rc. local. Вы можете попытаться найти ее там, чтобы изменить должным образом имя компьютера, которое задается в качестве параметра команды Hostname. В таком случае требуется перезагрузиться для того чтобы изменения вступили в силу.

Другой способ изменения имени компьютера или домена состоит в том, что эти имена прописываются в файле /etc/sysconfig/network в виде двух строчек примерно следующего вида:

Тогда в процессе инициализации системы эти имена будут восстанавливаться, потому что файл /etc/sysconfig/network вызывается из /etc/rc. d/rc. sysinit.

Кроме того, имя компьютера должно быть прописано в файле /etc/hosts, который связывает имя компьютера с его IP-адресом. Каждая строка файла /etc/hosts должна начинаться с IP-адреса, за которым следует имя данного узла. Следом за именем можно записать произвольное число псевдонимов этого узла.

Даже если ваш компьютер не подключен к сети, в файле /etc/hosts должна быть прописана хотя бы одна строка следующего вида.

127.0.0.1 localhost localhost. localdomain

Если же ваш компьютер подключен к TCP/IP сети, то в этом файле дополнительно нужно прописать строку вида

192.168.0.15 host_name host_name. localdomain

Файл /etc/hosts используется в механизмах разрешения имен. В больших сетях трудно было бы поддерживать в актуальном состоянии файлы /etc/hosts на всех компьютерах, если бы это был основной инструмент для определения IP-адресов по именам. Поэтому обычно для разрешения имен используются серверы DNS. Однако файл /etc/hosts все равно необходим, хотя бы для обращения к серверу DNS. Поэтому в нем имеет смысл указать IP-адреса и соответствующие имена шлюзов и серверов DNS и NIS. А чтобы все приложения использовали этот файл при разрешении имен, должен иметься файл /etc/hosts. conf, содержащий строку

Которая говорит, что при разрешении имен сначала должен использоваться файл /etc/hosts, а затем должно происходить обращение к серверу DNS. В большинстве случаев в файле /etc/hosts. conf достаточно иметь две строки:

Эти параметры указывают системе преобразования имен, что надо просмотреть файл /etc/hosts перед тем, как посылать запрос к серверу, и что следует возвращать все найденные в /etc/hosts адреса для данного имени, а не только первый.

Но настройка механизма разрешения имен не ограничивается редактированием файлов /etc/hosts и /etc/hosts. conf. Необходимо еще указать компьютеру имена серверов DNS. Они прописываются в файле /etc/resolv. conf. Этот файл имеет весьма простой формат. Это текстовый файл, каждая строка которого задает один из параметров системы преобразования имен. Как правило, используются три ключевых слова-параметра:

Domain— задает имя локального домена. Search— задает список имен доменов, которые будут добавляться к имени машины, если вы не укажете явно имени домена. Это позволяет ограничить область поиска и избежать некоторых ошибок (например, вы ищете компьютер linux. msk. ru, а механизм разрешения имен выведет вас на linux. spb. ru). Nameserver — этот параметр, который вы можете указывать несколько раз, задает IP-адрес сервера преобразования имен, на который ваша машина будет посылать запросы. Повторяя этот параметр, вы можете задать несколько серверов.

Если вы не собираетесь заводить поддержку сервиса имен для своей сети (что является довольно сложной организационной и технической проблемой), и доверяете ведение своих имен администратору локальной сети или вашему IP-провайдеру, то вам достаточно задать файл /etc/resolv. conf примерно следующего вида:

Search abcd. ru xyz. edu. ru

В этом примере машина находится в домене abcd. ru. Если вы зададите имя машины, не указывая домена, например "pc1”. то система преобразования имен попытается сначала найти машину "pc1.abcd. ru”. а в случае неудачи — "pc1.xyz. edu. ru”. Для преобразования имен ваша машина будет обращаться к серверам по адресам "192.168.10.1” и "192.168.12.1”.

13.2.5. Тестирование сетевого соединения

Чтобы проверить, соединяется ли ваш компьютер с сетью, попробуйте дать команду Ping. указав ей в качестве параметра IP-адрес одного из компьютеров сети. Пусть, например, вам известно (узнайте реальный номер и имя у администратора сети), что в сети есть компьютер с IP-адресом 192.168.0.2 и именем pc1. Тогда вы должны дать команду:

[user]$ ping 192.168.0.2

Или (тут вы одновременно проверяете и работу службы DNS)

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

64 bytes from 192.168.0.2: icmp_seq=0 ttl=32 time=1.2 ms

64 bytes from 192.168.0.2: icmp_seq=1 ttl=32 time=1.0 ms

64 bytes from 192.168.0.2: icmp_seq=2 ttl=32 time=1.0 ms

64 bytes from 192.168.0.2: icmp_seq=3 ttl=32 time=1.0 ms

64 bytes from 192.168.0.2: icmp_seq=4 ttl=32 time=1.1 ms

Это означает, что сетевое соединение работает. Для того чтобы прервать тестирование сети, нажмите комбинацию клавиш <Ctrl>+<C>.

13.2.6. Утилита Netconf

В предыдущих разделах я попытался подробно и последовательно изложить, каким образом можно настроить выход в сеть путем прямого редактирования конфигурационных файлов. Впрочем, настройки локальной сети можно производить и с помощью специальных утилит Netconf или Netcfg. которые являются просто составной частью пакета Linuxconf. Первая из них работает в графическом режиме, а вторая — в текстовом.

Рис. 13.1. Главное меню программы Netconf

Надо только иметь в виду, что многие опытные пользователи Linux критически относятся к возможностям пакета Linuxconf и предпочитают прямое редактирование конфигурационных файлов. Но для новичка эти утилиты могут оказаться удобнее, поэтому дадим их краткую характеристику на примере программы Netconf. Запустив ее, вы увидите окно, изображенное на рис. 13.1.

Для того чтобы задать имя вашего компьютера, надо нажать кнопку Basic host information. после чего появится еще одно окно с пятью закладками. На закладке Host name задается имя компьютера, а на закладке Adaptor1 — параметры IP-соединения (см. рис. 13.2).

Рис. 13.2. Задание имени через netconf

Рис. 13.3. Настройка сетевого адаптера

Можно ввести параметры непосредственно в появившиеся строки ввода (если вы знаете, что нужно вводить), а можно выбрать подходящий вариант из списка, который появляется, если щелкнуть мышкой по треугольнику в конце строки. После завершения ввода параметров надо нажать экранную кнопку Accept .

Адрес сервера DNS и настройка системы разрешения имен задается в окне, появляющемся при нажатии на кнопку Name server specification (DNS) программы Netconf (рис. 13.3). При выходе из программы после завершения редактирования появится дополнительное окно с запросом (рис. 13.4), в котором надо выбрать вариант Activate the changes .

Как видите, пользоваться этой программой несколько удобнее, чем искать нужные конфигурационные файлы и править их вручную. Здесь все настройки сети собраны в одном месте, и их легко задать в одном сеансе работы с программой. Надо только иметь в виду, что для работы с этой программой (как и с конфигурационными файлами) необходимо иметь права суперпользователя.

Рис. 13.4. Настройка системы разрешения имен через Netconf.

Рис. 13.5. Сохранение изменений, сделанных через Netconf

Больше полезного

mobiandro.ru

Рулим Росой по сети — Блог:Точка Росы — Rosalab Wiki

Задача - рулить!

ROSA Linux, как любой приличный Linuх, умеет управлять-ся и управлять другими системами по сети, т.е. удаленно. Способов для этого существует предостаточно и, чтоб не запутаться, сделаем небольшой обзор проверенно работающих решений. В этом обзоре мы рассмотрим ROSA FRESH KDE (или RED X2) как в роли клиента удаленного доступа, так и в роли сервера. Имеется в виду, конечно, не "настоящий" сервер, на котором одновременно и удаленно работают несколько пользователей запуская приложения и получая результаты. Нет, здесь мы сосредоточимся на задаче периодического управления пользовательской машинкой, ведь ROSA FRESH - пользовательская, десктопная система.

Доступ по SSH - используем консоль и mc

Быстрее всего (а это бывает очень важно для медленных каналов!) работает текстовый доступ к удаленному компьютеру по SSH. Для включения такого доступа нужно на сервере включить сервис sshd:

sudo systemctl start sshd

или Параметры системы/Управление системными службами)

а с клиента, в консоли дать команду

ssh [email protected]

где name - имя пользователя а xxx.xxx.xxx.xxx IP-адрес сервера или его доменное имя.

По умолчанию SSH будет пытаться подключиться по стандартному порту 22. Если нужно указать другой порт, то:

ssh [email protected] -p 5623

... где 5623 — порт для подключения.

Если подключение не происходит, то на компьютере, к которому подключаетесь, нужно в файле /etc/ssh/sshd_config расскоментировать строку (то есть убрать решетку и пробел в ее начале)

# Port 22

Сделать это можно через консольный редактор:

sudo nano /etc/ssh/sshd_config

...или через графический:

gksu xdg-open /etc/ssh/sshd_config

После правок нужно перезапустить сервис SSH:

sudo systemctl restart sshd

Если SSH будет открыт для подключений из глобальной сети Интернет, то для безопасности рекомендуется заменить 22 на любой другой нестандартный порт, например, 5623 (число с потолка) (если есть фаервол, то не забудьте предварительно открыть нужный порт на нем). Также рекомендуется использовать ключи SSH вместо пароля, закрыть доступ по SSH под пользователем root, а для входа в root-режим логиниться по ключу обычного пользователя с правами sudo (в ROSA из коробки настроено) и давать команду

sudo -i

...которая, запросив пароль пользователя (не root) переведет консоль в root-режим.

После этого мы попадем в консоль сервера, где можно уже запустить mc и смотреть-править-копировать файлы и в рамках своих прав курочить сервер из консоли. Если хочется утянуть с сервера файл или наоборот, залить файл на сервер, можно запустить mc в консоли на клиенте и выбрав из меню shell-соединение ввести адрес ssh.

При этом в одной панели mc мы будем видеть локальное дерево файлов, а во второй - удаленное, серверное. Ну и F5-F6, копируем и перемещаем!

Защищаем SSH-сессии от прекращения при разрыве соединения

По умолчанию при прекращении SSH-сессии (если вы ее закрыли вручную, в том числе случайно, или, например, отвалился интернет на хосте или клиенте) завершается работа всех программ, запущенных в сессии. Для защиты от этого на хосте (компьютере, которым управляем удаленно) установим screen:

sudo urpmi screen

Затем критически важные вещи запускаем через него, как именно, почитайте здесь. Можно, например, через screen запустить mc (Miodnight Commander), начать передачу файлов между машинами и выйти из SSH-сессии. Передача файлов продолжится!

Запуск графических приложений через SSH (X11Forwarding)

Настройка сервера

Правим файл /etc/ssh/sshd_config

Проверяем чтобы была такая строка, или добавляем сами:

X11Forwarding yes

Перезагружаем ssh командой

sudo systemctl restart sshd

Настройка клиента

Правим файл /etc/ssh/ssh_config

Проверяем чтобы была такая строка, или добавляем сами:

ForwardX11 yes

Запуск

Заходим на удаленный хост и потом запускаем нужное нам приложение, например: thunar

ssh -XC [email protected] thunar

Сразу запустить приложение thunar

ssh -XC [email protected] "thunar"

Опции:

X : перенаправлять графический вывод С : компрессия передаваемых данных

Доступ к GUI, или помогаем пользователю

Если нужен доступ к удаленному графическому интерфейсу (ну, например, нужно помочь пользователю подвигать мышью) - тут существует несколько решений, основанных на протоколе удаленного управления vnc. В состав KDE-версии ROSA Fresh входит и сервер и клиент VNC - KRFB и KRDC. Пользоваться этой связкой просто и интуитивно, но быстродействие сервера KRFB оставляет желать лучшего даже на широких каналах и мощных машинах. Поэтому для сервера мы рассмотрим другое решение - сервер x11vnc. Ставится он командой

urpmi x11vnc

или выбором в "Управлении программами". Для начальной настройки этого vnc-сервера введите в консоли команду:

x11vnc -storepasswd

при этом будет предложено ввести пароль и он будет сохранен. Для запуска сервера введите команду:

x11vnc -usepw -display :0 -forever

Теперь, запустив на клиенте тот же KRDC и введя адрес сервера в формате xxx.xxx.xxx.xxx:5900 и пароль вы получите удаленный доступ к рабочему столу на ROSA-FRESH-сервере. Если вам, например в корпоративной среде, нужен постоянный доступ к машине-серверу, создайте в /usr/bin скрипт-файл vnc.sh (чтоб запустить файл-менеджер под правами рута введите команду kdesu dolphin)

#!/bin/bash x11vnc -usepw -display :0 -q -forever -avahi &

сделайте его исполнимым командой:

chmod +x /usr/bin/vnc.sh

ну или в свойствах файла в dolphin поставьте галочку исполнимости. Теперь осталось добавить вызов этого скрипта в автозапуск (Параметры системы-Запуск и завершение) перед стартом KDE.

Всё, теперь пользовательская система "под колпаком"!

Простая программа для подключения к удаленной системе по VNC

Это TigerVNC. Проста, надежна, работает быстро, отрисовка без артефактов. В репозиториях Росы пакет называется TigerVNC, для установки через консоль:

sudo urpmi tigervnc

Есть версия для Windows и Mac OS, скачивать здесь. Там же статичные сборки для дистриубтивов Linux, где ее нет в репозиториях. Интерфейс сделан на тулките FLTK.

То же самое, но красиво

Ну вот мы, например, администрируем домашнюю или даже корпоративную сеть где несколько систем ROSA FRESH или RED X2. Мы запустили на них sshd и свой скрипт управления, поставили пароли. Как это всё можно красиво-удобно администрировать? Запускаем Dolphin, Сеть, Сеть - видим список машин сети (если не видим, жмем на F5 и видим!) Дальше выбираем нужную машинку на которой подняты сервисы удаленного управления и - видим все наши любимые и вышеуказанные сервисы.

Теперь, просто кликнув по нужному значку, можно попасть и в удаленное управление GUI, и в доступ по sftp для перемещения файлов и в консоль ssh для текстового управления. Можно властвовать и администрировать! Только нужно не забыть и учитывать, что любая система удаленного доступа это дополнительная уязвимость в системе - включайте сервисы удаленного управления только если они действительно нужны, используйте сложные пароли и другие средства защиты.

Рулим зоопарком систем... или наоборот

А как быть, если у вас ROSA Linux - но не KDE? Ничего страшного - сервер будет работать на любой системе, он маленький и нетребовательный. Клиенты же бывают разные - в состав GNOME входит Vinagre, для MATE можно использовать Remmina и все они умеют связываться по VNC (и, кроме того, по RDP если нужно управлять Windows).

Хорошо, когда у нас сеть состоит из одних систем на основе ROSA и эта сеть - локальная. А что если из Росы нужно управлять далекой Windows или, еще того хуже, MACом? Или, наоборот, находясь в далекой командировке на Камчатке нужно срочно что-то подправить на домашней Росе используя допотопную XP? Тут можно использовать проверенное и доступное в ROSA Linux и других системах средство - Teamviewer. В нашей Росе он доступен из репозиториев, для остальных его можно скачать с официального сайта. Понятно, что такой интеграции, как у встроенных в KDE клиентов удаленного доступа с ним не добьешься, но для удаленного доступа черт-те куда или черт-те откуда он подходит как нельзя лучше.

Подключение по VNC с планшетов и смартфонов с Android

Для подключения с Android установите приложение «Android VNC» из репозитория свободных приложений для Android F-Droid (ссылка). При подключении можно выбрать количество цветов в передаваемой картинке, чем их меньше, тем ниже потребление трафика. Автор пробовал работать по VNC через сеть EDGE с минимальным количеством цветов. Работала очень неплохо. Однако здесь важен стабильный уровень приема мобильной сети для предотвращения большого диапазона колебаний джиттера (это когда сейчас задержка 300 мс, а через секунду она 600 мс, а потом 900 мс и 150 мс, к примеру).

wiki.rosalab.com

Настройка сервера аутентификации посредством связки Kerberos+LDAP на базе ROSA Enterprise Linux Server

Введение Продолжение серии туториалов. Предыдущие части:Развёртывание DNS/DDNS и DHCP сервера на ROSA Enterpise Linux Server за несколько минутПочтовый сервер на базе ROSA Server Enterpise Linux за несколько минутПростой домен на базе ROSA Enterprise Linux Server и Samba 3 с поддержкой перемещаемых профилей

В этой статье мы рассмотрим создание сервера для централизованной аутентификации пользователей посредством Kerberos, а также аутентификацию с помощью Kerberos с хранением информации о профилях в дереве каталогов LDAP. В качестве приятной мелочи — автоматическое создание профилей в домашнем каталоге при подключении. Для настройки сервера аутентификации нам потребуется ROSA Enterprise Linux Server (далее RELS) и любая рабочая станция на базе Linux. В этой статье качестве рабочей станции будет использована ROSA Desktop Fresh 2012 с рабочим окружением KDE.

Немного о самом протоколе Kerberos от Википедии:

«Kerberos — сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию — оба пользователя через сервер подтверждают личности друг друга.»

От себя добавлю, что данный протокол является обязательным промышленным стандартом для организации аутентификации на предприятиях, и что самое главное, он необходим для создания систем использующих технологию единого входа, более известную как Single Sign-On. В настоящий момент, актуальной версией протокола является Kerberos 5. Данный протокол используется в Active Directory (начиная с Windows 2000), 389 Directory Server и многих других местах где требуется создание хоть сколько-нибудь серьёзного решения для централизованной аутентификации пользователей в сети. В том числе он используется и в ROSA Directory Server (далее RDS).

О терминологии используемой при работе с Kerberos:

Принципал — специальная уникальная сущность, которой можно выдать билет. Состоит из трёх частей: основы, экземпляра и области. Основа — первая часть принципала Kerberos. Если это пользователь, то соответствует его имени. Если сервис — имя сервиса. Экземпляр — вторая часть, служит для уточнения первой части. Может не содержатся в имени принципала, если есть, то это его описание. В случае хоста — его fqdn. Область — идет последней частью. Билет — данные, используемые клиентом для аутентификации на сервере, у которого клиент запрашивает службу. Подтверждают идентичность пользователя или сервиса. KDC — центр выдачи ключей Kerberos REALM (область) — область Kerberos. Как правило, соответствует доменному имени, написанному в верхнем регистре.

В качестве вводной — более чем достаточно. Подробности о протоколе, его реализациях можно почитать в Сети, поскольку это материал для более глубокого изучения и одной статьёй здесь уже не обойтись.

Подготовка и развёртывание

Будем считать, что ваша ОС уже установлена, как и установлен компонент RDS. Для настройки сервера аутентификации нам потребуется заранее установленный и настроенный сервер DNS, настройку которого мы рассматривали в одной из предыдущих статей, а также работающий NTP.

Как и во всех предыдущих статьях цикла, используются следующие параметры сети:

Имя домена: rosa.int IP-адрес: 192.168.100.1

Также будем считать, что DNS, LDAP и Kerberos работают на одном и том же физическом сервере.

Прочие подробности настройки читайте в предыдущих статьях цикла.

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

Сперва нам потребуется залогиниться в ROSA Management Console по адресу hostname/mmc и зайти в раздел «DNS зоны». Для существующей зоны (в нашем случае rosa.int) требуется создать алиас на нужный нам хост, который будет в дальнейшем являться KDC (Key Distribution Center). Центром распространения ключей, то бишь. В данном разделе нажимаем на ссылку с FQDN-именем, либо на пиктограмму изображающую два компьютера.

Там необходимо найти запись отвечающую за named-сервер. В моём случае это ns.rosa.int. Ищем значок «Изменить», в открывшемся окне нажимаем кнопку «Добавить» и в появившемся поле для ввода текста пишем любое понравившееся нам слово в нижнем регистре, которое будем именем KDC. Например, kerberos.

Проверяем:

[rels@rosa tmp]$ ping kerberos.rosa.int PING ns.rosa.int (192.168.100.1) 56(84) bytes of data. 64 bytes from rosa (192.168.100.1): icmp_seq=1 ttl=64 time=0.011 ms 64 bytes from rosa (192.168.100.1): icmp_seq=2 ttl=64 time=0.026 ms 64 bytes from rosa (192.168.100.1): icmp_seq=3 ttl=64 time=0.022 ms

Теперь можно идти устанавливать необходимые компоненты для будущего сервера аутентификации, для чего проследуем в ROSA Server Setup и выбираем компонент «Аутентификация Kerberos с RDS backend». Дожидаемся окончания установки всех необходимых компонентов и нажимаем «Продолжить» для первоначальной настройки. Откроется вот такая замечательная формочка:

Дам некоторые пояснения по представленному выше скриншоту:

Область — собственно, определяет область на которую распространяется Kerberos. В большинстве случаев, это имя используемого домена в верхнем регистре.
Имя узла KDC — сервер, на котором будет располагаться сервер дистрибуции ключей. В нашем случае, всё размещается на одной машине. FQDN-имя сервера должно указываться без имени домена. Т.е. вместо kerberos.rosa.int просто kerberos.
DNS домен — Имя домена. Собственно в нашем случае, совпадает с областью.
Порт KDC — порт для сервера дистрибуции ключей.
Порт сервера администратора — порт, по которому Kerberos связывается со своей базой данных.
Основной ключ базы данных KDC — пароль для базы данных Kerberos.
DNS-поиск для KDC — проверяет в SRV записях DNS наличие информации о сервере Kerberos.
DNS-поиск для области — поиск доступных серверов Kerberos информации в TXT-поле DNS.
Временной сдвиг — указывает допустимое время смещения часов относительно «эталонных». В качестве эталона у нас будет выступать сервер Kerberos, на котором работает сервис NTP. Время смещения указывается в секундах.
Типы шифрования TGS — поддерживаемые алгоритмы шифрования допустимые на сервере выдачи билетов. Как правило, не трогается.
Типы шифрования TKT — поддерживаемые алгоритмы шифрования для выдаваемых сервером билетов. Как правило, не трогается.
Разрешённые типы шифрования — типы шафрования для сессионного ключа.
Разрешить типы шифрования невысокой криптостойкости — собственно, позволяет разрешить использование слабозащищённых алгоритмов шифрования. Если мучает паранойя и требуется бОльшая безопасность при подключении к серверу, снимите этот чекбокс.

На всякий случай дам совет. На момент написания этой статьи, в ROSA Server Setup существовал крайне неприятный баг, приводивший к тому, что если вы неправильно с первой попытки заполнили одно из обязательных полей, то ветка для Kerberos данными в БД LDAP всё равно создавалась. Это приводило к тому, что при повторно заполненной форме, но уже с правильными значениями, нельзя было продолжить дальнейшую настройку. В следующих версиях эту проблему гарантированно устранят, так что на всякий случай выполните команду yum update в эмуляторе терминала перед установкой.

Если же всё-таки напоролись на эту ошибку, возьмите любой редактор для LDAP. Сойдёт даже такой простой как luma. Как правило, он есть в репозиториях любого дистрибутива. Подключитесь к серверу и удалите полностью следующие записи:

dn: ou=kerberos,@SUFFIX@ dn: uid=kadmin,ou=System Accounts,@SUFFIX@ dn: uid=kdc,ou=System Accounts,@SUFFIX@ dn: cn=Kerberos Admins,ou=System Groups,@SUFFIX@ dn: cn=Kerberos Readers,ou=System Groups,@SUFFIX@

Ещё на всякий случай проверьте существование следующих записей:

dn: relativeDomainName=kerberos,ou=@DNSDOMAIN@,ou=@DNSDOMAIN@,ou=DNS,@SUFFIX@ dn: relativeDomainName=_kerberos._udp,ou=@DNSDOMAIN@,ou=@DNSDOMAIN@,ou=DNS,@SUFFIX@ dn: relativeDomainName=_kerberos-master._udp,ou=@DNSDOMAIN@,ou=@DNSDOMAIN@,ou=DNS,@SUFFIX@ dn: relativeDomainName=_kerberos-adm._tcp,ou=@DNSDOMAIN@,ou=@DNSDOMAIN@,ou=DNS,@SUFFIX@ dn: relativeDomainName=_kpasswd._udp,ou=@DNSDOMAIN@,ou=@DNSDOMAIN@,ou=DNS,@SUFFIX@ Если они имеются, тоже удалите. После чего, перезапустите мастер установки.

Для подключения к серверу LDAP в целях редактирования содержимого веток использовать следующие параметры:

uid=LDAP Admin,ou=System Accounts,dc=rosa,dc=int

В настройках luma использовать Simple authentication. Пароль — тот, что вы указывали при настройке с помощью ROSA Server Setup. Естественно, вместо dc=rosa,dc=int должен быть указан ваш домен. Шифрование при подключении не применяется.

Теперь нам необходимо обязательно (!) настроить NTP как на сервере так и клиентах, в противном случае наши клиентские машины могут не подключиться из-за неправильных настроек часов.

На сервере достаточно проделать:

sudo yum install ntp sudo chkconfig ntpd on sudo vim /etc/ntp.conf

Как можем увидеть, серверы NTP уже прописаны. Остаётся только скомандовать:

ntpdate pool.ntp.org service ntpd start.

Проверьте и синхронизируйте часы на клиентских системах. Это очень важный момент настройки.

Создание принципалов

Перед началом проверки работы необходимо создать пользователя, на котором мы проверим работу сервера Kerberos в действии.

Для начала заглянем в список принципалов Kerberos и удостоверимся, что все служебные принципалы на месте: Теперь создадим уже нашего пользователя и принципала Kerberos. Для этого мы переходим в ROSA Management Console и добавляем тестового пользователя через «Добавить пользователя» в главном меню. Заполняем поля логина и пароль. Если прокрутить форму чуть ниже, то можно увидеть параметры относящиеся к настройкам Kerberos. Можно задать следующие параметры:

Использование парольной политики
Установить срок действия принципала
Установить срок действия пароля принципала

Думаю, объяснять смысл всех трёх пунктов нет смысла. Всё достаточно очевидно.

В случае успешного и правильного заполнения полей, после нажатия на кнопку «Подтвердить» появится соответствующее уведомление:

Проверка в действии

Для начала проверим, что всё действительно работает средствами консольных утилит. Это позволит сразу отследить возникающие ошибки. Для начала необходимо установить пакет krb5-workstation, после чего в командной строке запустить команду kinit, а после ввода пароля ввести команду klist, чтобы удостовериться в правильности сделанного запроса.

Выглядеть это будет примерно следующим образом:

kinit [email protected] Password for [email protected]:

klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: [email protected]

Valid starting Expires Service principal 10/19/11 01:46:33 10/20/11 01:46:33 krbtgt/[email protected] renew until 10/26/11 01:46:33

Если вы видите всё именно так, как в листинге выше, то вам прилетает правильный билет Kerberos, а это значит, что можно приступить к настройке рабочего места.

В качестве клиентской операционной системы я использовал дистрибутив Linux ROSA Desktop Fresh 2012. Там уже есть мастер настройки подключения к таким серверам. Для остальных дистрибутивов я приведу листинги рабочих конфигурационных файлов чуть позднее, чтобы вы могли использовать любой другой дистрибутив, который вам лично по вкусу.

Для подключения к серверу RELS необходимо открыть «Настройки рабочего стола» и выбрать найти пиктограмму с надписью «Аутентификация». Выбираем пункт Kerberos 5. Затем, прописываем сервер, как указано на скриншоте. Обратите внимание на расставленные чекбоксы. Если оставить последний активированным, то могут не установиться необходимые для подключения пакеты и их зависимости.

На следующем скриншоте прошу обратить внимание на две опции: «Использовать локальный файл с данными пользователей» и «Использовать LDAP с данными о пользователях».

Если вы будете использовать пункт «локальный файл с данными пользователей», то вам придётся удостовериться в наличии существования учётной записи с нужным именем на локальной машине. В случае её отсутствия на одной из сторон, создать на сервере и клиенте пользователя с одинаковым логином. Но задать ему разные пароли. Это не очень хорошо и добавляет уйму головной боли администратору. К тому же, из-за довольно больших таймаутов по умолчанию, первый вход в систему с использованием такого метода входа будет очень медленным. Более правильным является выбор второго пункта: «Использовать LDAP с данными о пользователях». В этом случае, вам нет необходимости заводить две учётные записи, все данные будут браться с сервера. Что, согласитесь, куда приятнее. Будьте внимательными, адрес должен быть указан в виде IP-адреса, а не FQDN-имени. После чего нажать на кнопку «Получить данные DN».

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

И обещанные листинги конфигурационных файлов:

/etc/krb5.conf

[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = ROSA.INT dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = true

/etc/ldap.conf

base dc=rosa,dc=int host 192.168.100.1 nss_base_group dc=rosa,dc=int?sub nss_base_shadow dc=rosa,dc=int?sub nss_base_passwd dc=rosa,dc=int?sub

/etc/nsswitch.conf

passwd: files ldap shadow: files ldap group: files ldap hosts: mdns4_minimal files nis dns wins mdns4 networks: files services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files ldap aliases: files

/etc/pam.d/system-auth

#%PAM-1.0 auth required pam_env.so auth sufficient pam_tcb.so shadow nullok prefix=$2a$ count=8 auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so account sufficient pam_tcb.so shadow account sufficient pam_krb5.so use_first_pass account required pam_deny.so password required pam_cracklib.so try_first_pass retry=3 password sufficient pam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8 password sufficient pam_krb5.so password required pam_deny.so session optional pam_mkhomedir.so skel=/etc/skel/ umask=0022 session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_tcb.so session optional pam_krb5.so

Если кому-то нужно аутентифицироваться исключительно через LDAP не применяя Kerberos, то всё значительно упрощается.

Точно также запускаете мастер настройки, только вместо пункта Kerberos требуется выбрать LDAP. Для дистрибутивов ROSA Marathon 2012 (LTS) и ROSA Desktop Fresh 2012 все необходимые пакеты требуемые для подключения уже входят в состав дистрибутива. Остальным следует знать, что для настройки клиента потребуются следующие пакеты: openldap-clients, pam_ldap, autofs.

На этом этапе необходимо указать адрес LDAP-сервера. Как и в прошлый раз, адрес не забываем указывать в виде октетов. В противном случае, будет сгенерирован нерабочий конфигурационный файл (впрочем, его всегда можно исправить руками в случае чего). База пользователей определяется автоматическим образом при нажатии на кнопку «Получить DN». Как и в прошлом примере, необходимо снять флаг «Автономный режим», иначе настройка будет произведена не совсем верно.

Также проверить работоспособность в консоли можно с помощью команды getent paswd, либо выполнить команду su имя_пользователя_в_БД_ldap. Первая команда покажет список пользователей, среди которых будут перечислены пользователи каталога LDAP. Во врем выполнения второй команды будет выполнен вход в систему с использованием учётных данных пользователя каталога LDAP и автоматически создастся каталог аутентифицировавшегося пользователя внутри директории /home.

Примеры конфигурационных файлов:

Содержимое ldap.conf:

base dc=rosa,dc=int host 192.168.100.1 nss_base_group dc=rosa,dc=int?sub nss_base_shadow dc=rosa,dc=int?sub nss_base_passwd dc=rosa,dc=int?sub Содержимое nsswitch.conf: passwd: files ldap shadow: files ldap group: files ldap hosts: mdns4_minimal files nis dns wins mdns4 networks: files services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files ldap aliases: files И, наконец, system-auth:#%PAM-1.0 auth required pam_env.so auth sufficient pam_tcb.so shadow nullok prefix=$2a$ count=8 auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account sufficient pam_tcb.so shadow account sufficient pam_ldap.so use_first_pass account required pam_deny.so password required pam_cracklib.so try_first_pass retry=3 password sufficient pam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8 password sufficient pam_ldap.so password required pam_deny.so session optional pam_mkhomedir.so skel=/etc/skel/ umask=0022 session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_tcb.so Заключение

На этом всё, пожалуй. Мы научились быстро и без проблем создавать собственный сервер аутентификации с использованием Kerberos и LDAP. В дальнейшем, керберизацию можно использовать для самых различных целей. Например, связать Kerberos с сервером PostgreSQL и использовать принципалов Kerberos для входа. Или создание инфраструктуры Single Sign-On и многое другое. Традиционно надеюсь, что материал пригодится как начинающим, а также просто ленивым (в хорошем смысле) системным администраторам.

Дельные комментарии, вопросы по существу и фичреквесты всегда приветствуются.

habr.com

Блог:Точка Росы — Rosalab Wiki

Запросов от пользователей на обновление тех или иных программ в дистрибутивах ROSA Desktop Fresh мы получаем не много, а очень много. Приходится закрывать слишком разросшиеся темы на форуме, разбивая их на более мелкие.

К сожалению, выполнить абсолютно все пожелания разработчики РОСЫ не в состоянии. Однако помочь нам может каждый — вопреки распространенному мнению, для обновления какой-либо программы вовсе не обязательно быть программистом, разбираться в сборке пакетов и прочих премудростях. Во многих случаях вам хватит веб-браузера и желания сделать нечто полезное.

Итак, вы узнали о выходе новой версии вашей любимой программы и хотите обновить соответствующий пакет в РОСЕ. Для примера, возьмем набирающий популярность редактор Atom — у него недавно вышла версия 1.3.2, а в репозиториях РОСЫ на момент написания этой статьи — все еще версия 1.2.0. Давайте исправим это досадное недоразумение.

Первым делом идем и регистрируемся в нашей среде сборки ABF, если вы этого до сих пор не сделали — на http://abf.io кликаем в правом верхнем углу на «Регистрацию», вводим логин/пароль и успешно заходим в систему (регистрация абсолютно свободна, происходит мгновенно и не требует никаких подтверждений).

Теперь находим с помощью поиска интересующий нас пакет atom, находящийся в группе import (обязательно используйте эту группу, именно из нее собираются пакеты в официальные репозитории!).

Переходите в этот проект и жмите кнопку «Клонировать» («Fork»).

В появившемся окне выберите опцию «Клонировать в <ваш_логин>/atom» («Fork to <your_login>/atom»). Этим действием вы склонируете проект в ваш персональный репозиторий, где вы сможете с ним играться в свое удовольствие. Клонирование происходит достаточно быстро, и вы сразу будете перенаправлены на страницу склонированного проекта. Если вы видите сообщение о том, что репозиторий пуст — просто обновите страницу.

Следующим пунктом необходимо изменить используемую ветку Git-репозитория на rosa2014.1. Если эта фраза вам ни о чем не говорит, не пугайтесь — достаточно в выпадающем списке в правом верхнем углу выбрать значение «rosa2014.1» (мы используем эту ветку, начиная с релиза ROSA Desktop Fresh R4 и точно продолжим использовать в R7).

Теперь вам необходимо в списке файлов проекта найти файл с расширением «spec» («atom.spec» в нашем случае) и кликнуть на него и затем кликнуть на «Edit» для его редактирования.

Все, что вам надо изменить в этом файле — это значение тэга Version, который обычно находится где-то вверху файла. Как мы видим, сейчас здесь указана версия 1.2.0, и мы ее заменим на 1.3.2. После этого в окне «Commit message» оставьте некоторое разумное описание произведенных изменений — например, «Updated to version 1.3.2». На этом все — теперь файл можно сохранить соответствующей кнопкой внизу экрана.

Если кто-то подумал, что этим мы и обновили программу в дистибутиве — спешим огорчить, мы всего лишь подготовились к попытке собрать новую версию, и теперь пора эту попытку произвести. Для этого кликаем на кнопку «New Build», и в появившемся окне выполняем два действия:

на всякий случай, отключите ваш персональный репозиторий — вдруг там уже есть что-то, что помешает чистоте сборки
если вы собираете пакет для репозитория Contrib (или просто не уверены, в какой репозиторий вы его собираете), то обязательно отметьте в левой колонке позицию «contrib» в секции «rosa2014.1»

После этого можно нажать на кнопку «Start Build» и ждать результата. Если сборка завершится с ошибкой — что ж, «нахаляву» обновить пакет не получилось, надо либо разбираться с ошибками либо бежать за помощью к более осведомленным людям. Если же сборка завершилась успешно, то на страничке сборки вы сможет получить rpm-пакеты с новой версией программы, которые вы можете скачать, установить и попробовать в деле.

Если новая программ работает как положено, то надо поделиться своими достижениями с остальными членами сообщества (ведь вы помните, что до сих пор мы все действия производили в вашем персональном репозитории?), послав запрос на обновление в основной проект, находящийся в группе import. Делается это посредством нажатием на кнопку «Pull Request» на страничке вашего проекта.

В появившемся окне убедитесь, что для исходного и целевого проектов выбрана ветка rosa2014.1, при необходимости нажмите кнопку «Update commits», оставьте некоторое вразумительное сообщение в поле Description и отправьте запрос, нажав на кнопку «Send Pull Request».

Разработчики получат уведомление о предлагаемых вами изменениях, рассмотрят их, внесут в основной проект в группе import и соберут новую версию пакета в официальные репозитории.

→ продолжить чтение…

wiki.rosalab.ru

ROSA Desktop fresh | Блог Александра Толстого

Хочу поделиться своим опытом тестирования дистрибутивов Linux в медленно уходящем 2017 году. Напомню, что мой профиль использования — это классическое настольное применение, также известное как desktop computing. Если говорить конкретно, то свою тестовую машину я использую для интернет-сёрфинга, проигрывания медиа-контента, каталогизации фотографий, а также для написания, сканирования и печати документов. Существенный момент: я регулярно пишу обзоры новинок открытого ПО, которые вы можете читать в журнале Linux Format, поэтому для меня жизненно важно иметь возможность устанавливать самые новые программы. Если есть готовые бинарные сборки — хорошо, нет — не беда, я могу и сам собрать что угодно из Github.com.

С точки зрения «железа», использовалась следующая конфигурация:

Intel Core i3 2105 с материнской платой DH67BL-B3;
Встроенная графика Intel HD 3000 Graphics;
8 Гб ОЗУ (DDR3/1333)
Intel SSD 120GB

В качестве подопытных операционных систем выступали интересующие меня дистрибутивы Linux: openSUSE 42.3, elementaryOS 0.4.1, Rosa Fresh R9, Mageia 6. Каждая из этих систем прожила в моём компьютере не менее 2 месяцев и оценивалась с точки зрения удобства, функциональности и эстетики. Ниже я поделюсь своими впечатлениями о каждой из них.

openSUSE 42.3

Данный дистрибутив имеет массу преимуществ для тех, кто по тем или иным причинам, предпочитает RPM-системы. Здесь есть очень удобный и надёжный инсталлятор от Suse Enterprise Linux (SLE) и довольно толковый центр управления YaST. Я сознательно выбрал более консервативную и стабильную версию Leap вместо всегда супер-свежей Tumbleweed по простой причине: в Leap я могу подключить дополнительные репозитории и обновить множество компонентов до самых свежих версий, получив на выходе нечто похожее на Tumbleweed. Но при этом, если что-то пойдёт не так, я всегда могу временно отключить такие репозитории и откатиться обратно. Не стоит забывать, что команда ‘zypper dup’ не столько обновляет пакеты, сколько приводит их в соответствие с текущим набором включённых репозиториев, то есть, её можно использовать и для даунгрейда (отката). Я установил новые версии для Qt5, KF5, KDE, KDE Extras, настроил себе более свежий компилятор GCC 7, перешёл на свежую версию ядра. У меня появилась самая новая версия рабочего стола KDE Plasma 5, которая автоматически обновлялась почти без моего участия. В openSUSE имеется отличная интеграция PackageKit и Zypper, поэтому для установки обновлений достаточно пару раз щёлкнуть мышью по значку в системном лотке. Даже пароль вводить не нужно!

Что и говорить, обновления в openSUSE ставить легко и приятно, однако за последствия никто не отвечает…

Однако, со временем стали вылезать недостатки такой системы: приверженность самым новым версиям вышла мне боком. То и дело после очередного обновления что-нибудь отваливалось или начинало работать не так. Либо Segmentation fault, либо частые падения самой оболочки Plasma (да, она всё ещё падает иногда!), либо временная потеря функциональности (Virtualbox может не работать с самым новым ядром). Проблемы можно обычно решить с помощью маневрирования с репозиториями, но со временем, опять же, дистрибутив превращается в гремучую смесь пакетов от разных поставщиков. Поддерживать стабильность вручную оказалось довольно трудозатратно. Всё таки, openSUSE Leap наиболее надёжен именно

atolstoy.wordpress.com