GDB

Разработав консольную утилиту, вы решаетесь опубликовать её на PyPI. Ну правда, что может быть лучше, чем сделать её доступной через pip install? Погуглив, что для этого надо, вы, возможно, наткнётесь на единственный найденный мной пост по теме, который мало того что от 2014 года, так ещё и требует от вас создать кучу папок и файлов для совершенно ненужных (вам) вещей.

Как же решить эту задачу без лишней головной боли в 2019 году? Я уже задавался этим вопросом и поэтому, прочитав тонну документации, создал для вас этот туториал. Вот пошаговая инструкция.

1. Создайте аккаунт на PyPI (ссылка для регистрации)

2. Создайте точку входа в приложение (например, файл entry.py со следующим содержимым)

def main():
    print("It's alive!")

3. Установите poetry

curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python
source $HOME/.poetry/env

(poetry можно установить и по-другому, например, pip install --user poetry — прим. перев.)

4. Создайте окружение

cd myproject # Перейдите в папку проекта, который будем паковать
poetry init

5. Настройте консольную команду (для этого добавьте следующие строки в появившийся файл pyproject.toml)

[tool.poetry.scripts]
APPLICATION-NAME = 'entry:main'

APPLICATION-NAME надо поменять на имя консольной команды.

6. Опубликуйте утилиту! (используйте имя пользователя и пароль из шага 1)

poetry publish --username PYPI_USERNAME --password PYPI_PASS --build

Готово! Теперь другому человеку для установки достаточно всего двух команд:

$ sudo pip install PROJECT-NAME
$ APPLICATION-NAME

Где PROJECT-NAME — это имя, которое вы дали проекту на шаге 4, а APPLICATION-NAME — это имя команды из шага 5.

Обновление версии

Всякий раз, когда вы хотите обновить модуль, просто измените номер версии в файле pyproject.toml:

version = "0.1.0"

И повторите шаг 6:

poetry publish --username PYPI_USERNAME --password PYPI_PASS --build

Бонус: настраиваем Travis для авто-публикации

Добавьте следующие строки в файл .travis.yml

language: python
dist: xenial
before_install:
  - curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python
  - source $HOME/.poetry/env
install:
  - poetry install
script:
  - poetry build
deploy:
  - provider: script
    skip_cleanup: true
    script: poetry publish --username $PYPI_USER --password $PYPI_PASS
    on:
      branch: master
      python: '3.7'
      tags: true

И установите переменные окружения PYPI_USER и PYPI_PASS на travis-ci.com. После этого можно будет публиковать пакет с помощью команд:

git tag -a v1.2 # Replace version number with yours
git push --tags

С недавних пор я начал использовать новый менеджер под названием Poetry. Именно о нём сегодня пойдёт речь.

Функциональные возможности Poetry:

• Управление зависимостями через toml файл (прощай, requirements.txt)


• Автоматическое создание изолированного виртуального окружения Python (теперь не нужно для этого вызывать virtualenv)


• Удобное создание пакетов (отныне не нужно копипастить создавать setup.py каждый раз)


• poetry.lock файл для фиксирования версий зависимостей

А особенно радует тандем при работе с pyenv. О pyenv я писал три года назад.

Установка

Исходный код проекта лежит на github. Для установки необходимо выполнить команду:

curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python

Если установка прошла успешно, то убедиться в этом можно вызвав:

$ poetry --version
Poetry 0.12.8

Стартуем!

Создаём новый проект my-demo-project:

$ poetry new my-demo-project

Заходим в папку:

$ cd my-demo-project/
~/my-demo-project$ ls
README.rst my_demo_project pyproject.toml tests

Poetry автоматически создал все необходимые файлы для будущего пакета, но наибольший интерес представляет файл с названием pyproject.toml, этот файл можно рассматривать как продвинутую альтернативу старичку requirements.txt. Взглянем на содержимое:

[tool.poetry]
name = "my-demo-project"
version = "0.1.0"
description = ""
authors = ["Your Name you@example.com"]

[tool.poetry.dependencies]
python = "^3.6"

[tool.poetry.dev-dependencies]
pytest = "^3.0"

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

Формат файла TOML. Раздел tool.poetry предназначен для описания проекта: название, версия, краткая информация о проекте и т.д. Далее следует tool.poetry.dependencies, именно здесь будут указаны все production зависимости. Их можно указать вручную (привет, requirements.txt), но мы так делать не будем (привет, npm!). Раздел tool.poetry.dev-dependencies предназначен для зависимостей во время разработки (привет, pytest, tox!)

Добавляем зависимости

Давайте добавим к проекту зависимость в виде Luigi.

~/my-demo-project$ poetry add luigi==2.8.0

Creating virtualenv my-demo-project-py3.6 in /home/user/.cache/pypoetry/virtualenvs
Updating dependencies
Resolving dependencies... (24.1s)

Package operations: 12 installs, 0 updates, 0 removals

Writing lock file
  - Installing docutils (0.14)
  - Installing lockfile (0.12.2)
  - Installing six (1.11.0)
  - Installing atomicwrites (1.2.1)
  - Installing attrs (18.2.0)
  - Installing more-itertools (4.3.0)
  - Installing pluggy (0.8.0)
  - Installing py (1.7.0)
  - Installing python-daemon (2.1.2)
  - Installing tornado (4.5.3)
  - Installing luigi (2.8.0)
  - Installing pytest (3.10.1)

Обратите внимание, что Poetry автоматически создал виртуальное окружение через virtualenv при добавлении пакета (т.к. ранее оно не было создано). Все окружения находятся по пути ~/.cache/pypoetry/virtualenvs

Если снова открыть pyproject.toml, то можно увидеть новую запись в разделе зависимостей:

[tool.poetry.dependencies]
python = "^3.6"
luigi = "=2.8.0"

Всю "грязную" работу за нас делает Poetry. Чтобы добавить зависимость для разработки достаточно указать флаг —dev:

$ poetry add tox --dev

Using version ^3.5 for tox
Updating dependencies
Resolving dependencies... (6.3s)
Package operations: 4 installs, 0 updates, 0 removals

Writing lock file
  - Installing filelock (3.0.10)
  - Installing toml (0.10.0)
  - Installing virtualenv (16.1.0)
  - Installing tox (3.5.3)

Смотрим содержимое pyproject.toml ещё раз:

[tool.poetry.dev-dependencies]
pytest = "^3.0"
tox = "^3.5"

Чтобы удалить зависимость нужно выполнить:

~/my-demo-project$ poetry remove luigi

Сборка пакета

Отныне забудьте про головную боль с ручным созданием setup.py, прописыванием туда всех зависимостей и запоминанием команд для сборки через pip. Всё стало в разы проще. Чтобы собрать python пакет выполните:

~/my-demo-project$ poetry build

Building my-demo-project (0.1.0)
 - Building sdist
 - Built my-demo-project-0.1.0.tar.gz
 - Building wheel
 - Built my_demo_project-0.1.0-py3-none-any.whl

В папке dist будут сформированы пакеты. Чтобы поделиться своим творением с другими разработчиками, например через pypi, выполните:

~/my-demo-project$ poetry publish

Окружение

Для активации виртуального окружения необходимо выполнить команду:

~/my-demo-project$ poetry shell

Вывод

Проект Poetry появился 28 февраля 2018 года, последняя версия 0.12.8. Инструмент молодой, но перспективный и быстроразвивающийся. Уже сейчас он на голову выше старичка pip и по функциональным возможностям и по удобству использования. Советую вам его попробовать и поделиться мнением в комментариях к этой статье. За более подробной информацией об инструменте советую заглянуть на сайт с документацией.

Объемы данных в современных системах растут с каждым днем и тот объем, который еще вчера считался достаточным, сегодня уже не способен удовлетворить текущие требования. Также дешевеют носители данных, особенно это касается твердотельных накопителей, что рано или поздно поставит администратора перед необходимостью апгрейда дисковой подсистемы. Но как быть, если вы используете программный RAID в Linux? В этой статье мы рассмотрим наиболее часто встречающийся сценарий с заменой дисков на более емкие и расширением объема массива.

Несмотря на то, что в качестве примера мы использовали Debian 9 все нижеизложенное будет справедливо для любого базирующегося на Debian дистрибутиве, а с небольшими поправками (там, где касается установки загрузчика) для любой Linux-системы.

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

Итак, у нас в системе используются два виртуальных жестких диска объемом 20 ГБ которые мы хотим заменить на новые виртуальные диски объемом в 30 ГБ желательно без существенного простоя системы.

Прежде всего ознакомимся с текущей конфигурацией дисковой подсистемы. Будет очень полезно выполнить перезагрузку и войдя в BIOS уточнить с какого именно физического диска мы загружаемся.

В нашем случае это первый физический диск. Теперь загрузимся в систему и выполним команду:

lsblk

ее вывод позволяет в удобном виде увидеть структуру текущей дисковой подсистемы.

Как можно увидеть, в нашем случае на двух физических жестких дисках sda и sdb расположены два программных массива raid1: md0 с корневой файловой системой и md1 с разделом подкачки объемом 16,8 ГБ и 3,2 ГБ соответственно.

Следующим шагом нам нужно посмотреть разметку на физических дисках, это можно сделать при помощи утилиты fdisk, но лучше использовать ее аналог с псевдографическим интерфейсом - cfdisk. Запустим ее с указанием интересующего нас диска:

cfdisk /dev/sda

Здесь мы видим, что диск имеет таблицу разделов MBR (Label: dos в шапке) и содержит первичный раздел sda1 объемом 16,8 ГБ типа fd Linux RAID, а также логический раздел sda2, в котором находится еще один раздел типа fd Linux RAID размером 3,2 ГБ - sda5.

Запомним эти данные, так как аналогичную по структуре разметку нам нужно будет воспроизвести на новом жестком диске. Для этого нам нужно заменить один из старых дисков массива на новый, так как загрузились мы с первого физического диска, т.е. sda, то заменить нам следует sdb. Поэтому пометим его как сбойный для каждого из расположенных на нем массивов:

mdadm -f /dev/md0 /dev/sdb1
mdadm -f /dev/md1 /dev/sdb5

Теперь можно выключить сервер и физически заменить старый жесткий диск на новый. После этого загрузимся и выполним команду:

fdisk -l

Как видим в системе появился новый неразмеченный диск sdb объемом 30 ГБ. Теперь следует разметить его:

cfdisk /dev/sdb

Первым шагом указываем тип таблицы разделов, так как у нас уже используется MBR, то выбираем dos.

Теперь нам нужно создать аналогичную по структуре sda разметку, но с новыми разделами разделов. Единственное условие - они не должны быть меньше уже имеющихся. В нашем случае мы создадим первичный раздел объемом 26 ГБ и укажем для него тип Linux raid autodetect (fd) используя для этого кнопку Type утилиты.

Затем запишем изменения кнопкой Write. На оставшемся месте создадим расширенный раздел (extended) и внутри его еще один раздел Linux raid autodetect (fd). В итоге у вас должна получиться разметка аналогичная по структуре sda, но с новыми размерами разделов.

Теперь добавим вновь созданные разделы в массивы:

mdadm --add /dev/md0 /dev/sdb1
mdadm --add /dev/md1 /dev/sdb5

После чего убедимся, что начался процесс ресинхронизации:

cat /proc/mdstat

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

Вроде бы все хорошо, но не забываем про загрузчик, на новом диске его нет. Поэтому выполним:

dpkg-reconfigure grub-pc

Принимаем значения по умолчанию пока не появится окно с выбором дисков, указываем установку загрузчика на все физические диски, выбирать RAID-массив не надо.

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

mdadm -f /dev/md0 /dev/sda1
mdadm -f /dev/md1 /dev/sda5

Выключаем сервер, физически заменяем диск на новый, загружаемся. Проверяем дисковую конфигурацию:

Как видим, теперь у нас в системе появился новый неразмеченный диск sda, но так как нам уже не нужно создавать разделы с отличным от sdb размером, то просто скопируем разметку с одного диска на второй, для этого используем еще одну утилиту sfdisk:

sfdisk -d /dev/sdb | sfdisk /dev/sda

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

Снова добавим разделы в массив:

mdadm --add /dev/md0 /dev/sda1
mdadm --add /dev/md1 /dev/sda5

Дождемся окончания ресинхронизации:

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

lsblk 

и внимательно изучим вывод:

Несмотря на то, что мы увеличили размер sda1/sdb1 и sda5/sdb5 размеры массивов md0 и md1 остались неизменными. Но если мы вспомним, что программный RAID в Linux строится поверх разделов, то все станет на свои места. Это аналогично тому, что если бы мы заменили жесткий диск в системе на более емкий, но перенесли раздел без изменения размера.

Что делать? Расширить объем массива, для этого выполните команды:

mdadm --grow /dev/md0 --size=max
mdadm --grow /dev/md1 --size=max

Что у нас получилось?

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

df -h

Из ее вывода видно, что размер файловой системы не изменился и нам по-прежнему доступно около 17 ГБ. Но здесь нет никакой ошибки, если мы вспомним, что программный RAID является для системы аналогом диска, который содержит раздел с файловой системы, то поймем, что несмотря на то, что мы увеличили размер диска, нам следует также увеличить размер раздела с данными. Для этого выполним:

resize2fs /dev/md0

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

А в заключение не будет лишним напомнить, что все проведенные нами операции несут потенциальный риск полной потери данных, поэтому перед тем, как выполнять указанные в статье действия создайте полную резервную копию вашей системы.

Get-WindowsOptionalFeature -Online | ft >$env:userprofile\desktop\features.txt
Get-WindowsOptionalFeature -Online -FeatureName NetFX3

Mount-WindowsImage -ImagePath $env:ua\wim\install.wim -Index 1 -Path $env:ua\mount
Disable-WindowsOptionalFeature -Path $env:ua\mount -FeatureName Microsoft-Hyper-V-All
Get-WindowsOptionalFeature -Path $env:ua\mount -FeatureName Microsoft-Hyper-V-All
Dismount-WindowsImage -Path $env:ua\mount -Save

Недавно при включении компьютера, Ubuntu меня "порадовала" тем, что решила не загружаться и "свалилась" в busybox в момент инициализации пользовательского пространства (userspace) оно же initramfs. Немного ошарашенный начал разбираться. Оказалось, что мой старенький жёсткий диск дал небольшой сбой, и подпортил суперблок файловой системы. Впрочем, оказалось что это не смертельно, и проблема эта, довольно просто и быстро решается.

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

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

Для восстановления нам понадобится загрузочный диск или флэшка с Linux. Загружаемся, и запускаем терминал. В терминале пишем:

sudo fdisk -l|grep Linux|grep -Ev 'swap'

В результате выполнения команды, будет выведен список всех разделов:

/dev/sda2       371306496 976771071 605464576 288.7G 83 Linux

В моем случае это был один раздел. В этом списке нужно найти нужный раздел, и запомнить его. Он понадобится нам дальше. Далее посмотрим список доступных запасных суперблоков:

sudo dumpe2fs /dev/sda2 | grep superblock

В команде выше, /dev/sda2 необходимо заменить на полученный ранее, нужный раздел. В результате выполнения команды, будет выведен список всех суперблоков:

Primary superblock at 0, Group descriptors at 1-19
Backup superblock at 32768, Group descriptors at 32769-32787
Backup superblock at 98304, Group descriptors at 98305-98323
Backup superblock at 163840, Group descriptors at 163841-163859
Backup superblock at 229376, Group descriptors at 229377-229395
Backup superblock at 294912, Group descriptors at 294913-294931
Backup superblock at 819200, Group descriptors at 819201-819219
Backup superblock at 884736, Group descriptors at 884737-884755
Backup superblock at 1605632, Group descriptors at 1605633-1605651
Backup superblock at 2654208, Group descriptors at 2654209-2654227
Backup superblock at 4096000, Group descriptors at 4096001-4096019
Backup superblock at 7962624, Group descriptors at 7962625-7962643
Backup superblock at 11239424, Group descriptors at 11239425-11239443
Backup superblock at 20480000, Group descriptors at 20480001-20480019
Backup superblock at 23887872, Group descriptors at 23887873-23887891
Backup superblock at 71663616, Group descriptors at 71663617-71663635

Из списка запасных суперблоков, выбираем любой кроме Primary и запускаем проверку диска с указанием запасного суперблока:

sudo fsck -b 32768 /dev/sda2 -y

Параметр -y необходим для того, чтобы fsck не спрашивал что делать с каждой найденной ошибкой, а вместо этого ее автоматически исправлял если это возможно. После того, как fsck закончит, результат выполнения будет примерно таким:

fsck 1.40.2 (23-March-2016)
e2fsck 1.40.2 (23-March-2016)
/dev/sda2 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #241 (32254, counted=32253).
Fix? yes
Free blocks count wrong for group #362 (32254, counted=32248).
Fix? yes
Free blocks count wrong for group #368 (32254, counted=27774).
Fix? yes
..........
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 59586/605464576 files (0.6% non-contiguous), 3604682/605464576 blocks

После этого перезагружаемся, отключаем флэшку/вынимаем диск из привода, и всё должно работать. :)

Введение

• /usr/lib/systemd/system/ – юниты из установленных пакетов RPM.
• /run/systemd/system/ — юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.
• /etc/systemd/system/ — юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме.

• .service – системный сервис
• .target — группа юнитов systemd
• .automount – точка автомонтирования файловой системы
• .device – файл устройства, распознанного ядром
• .mount – точка монтирования файловой системы
• .path – файл или директория в файловой системе
• .scope – процесс, созданный извне
• .slice – группа иерархически организованных юнитов, управляющая системными процессами
• .snapshot – сохраненное состояние менеджера systemd
• .socket – сокет межпроцессного взаимодействия
• .swap – Свап-устройство или свап-файл (файл подкачки)
• .timer – таймер systemd

Основные функции systemd в CentOS 7

• Активация, основанная на сокетах. Во время загрузки systemd прослушивает сокеты для всех системных сервисов, поддерживает этот тип активации и передает сокеты этим сервисам сразу после старта сервисов. Это позволяет systemd не только запускать сервисы параллельно, но также дает возможность перезапускать сервисы без потери любых отправленных им сообщений, пока сервисы были недоступны. Соответствующий сокет остается доступным и все сообщения выстраиваются в очередь.
• Активация, основанная на D-Bus. Системные сервисы, использующие D–Bus для межпроцессного взаимодействия, могут быть запущены по требованию, когда клиентское приложение пытается связаться с ними.
• Активация, основанная на девайсах. Системные сервисы, поддерживающие активацию, основанную на девайсах, могут быть запущены, когда определенный тип оборудования подключается или становится доступным.
• Активация, основанная на путях. Системные сервисы могут поддерживать этот вид активации, если изменяется состояние папки или директории.
• Снепшоты системных состояний. Система может сохранять состояние всех юнитов и восстанавливать предыдущее состояние системы.
• Управление точками монтирования и автомонтирования. Systemd отслеживает и управляет точками монтирования и автомонтирования.
• Агрессивная параллелизация Systemd запускает системные сервисы параллельно из-за использования активации, основанной на сокетах. В комбинации с сервисами, поддерживающими активацию по требованию, параллельная активация значительно уменьшает время загрузки системы.
• Транзакционная логика активации юнитов. До активации и деактивации юнитов systemd вычисляет их зависимости, создает временную транзакцию и проверяет целостность этой транзакции. Если транзакция нецелостная, systemd автоматически пытается исправить ее и удалить не требующиеся задания из нее до формирования сообщения об ошибке.
• Обратная совместимость с инициализацией SysV. SystemD полностью поддерживает скрипты инициализации SysV, как описано в спецификации Linux Standard Base (LSB), что упрощает переход на systemd.

Управление сервисами

• systemctl start name.service – запуск сервиса.
• systemctl stop name.service — остановка сервиса
• systemctl restart name.service — перезапуск сервиса
• systemctl try-restart name.service — перезапуск сервиса только, если он запущен
• systemctl reload name.service — перезагрузка конфигурации сервиса
• systemctl status name.service — проверка, запущен ли сервис с детальным выводом состояния сервиса
• systemctl is-active name.service — проверка, запущен ли сервис с простым ответом: active или inactive
• systemctl list-units --type service --all – отображение статуса всех сервисов
• systemctl enable name.service – активирует сервис (позволяет стартовать во время запуска системы)
• systemctl disable name.service – деактивирует сервис
• systemctl reenable name.service – деактивирует сервис и сразу активирует его
• systemctl is–enabled name.service – проверяет, активирован ли сервис
• systemctl list-unit-files --type service – отображает все сервисы и проверяет, какие из них активированы
• systemctl mask name.service – заменяет файл сервиса симлинком на /dev/null, делая юнит недоступным для systemd
• systemctl unmask name.service – возвращает файл сервиса, делая юнит доступным для systemd

Работаем с целями (targets) Systemd

• poweroff.target (runlevel0.target) – завершение работы и отключение системы
• rescue.target (runlevel1.target) – настройка оболочки восстановления
• multi–user.target (runlevel2.target, runlevel3.target, runlevel4.target) – настройка неграфической многопользовательской системы
• graphical.target (runlevel5.target) – настройка графической многопользовательской системы
• reboot.target (runlevel6.target) – выключение и перезагрузка системы

Выключение и перезагрузка системы

Управление systemd на удаленной машине

Типичный systemd .service

[Unit]
Description=Daemon to detect crashing apps
After=syslog.target

[Service]
ExecStart=/usr/sbin/abrtd
Type=forking

[Install]
WantedBy=multi-user.target

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

Установка CentOS

label auto 
  menu label ^Auto install CentOS Linux 7 
  kernel vmlinuz
  append initrd=initrd.img inst.ks=cdrom:/dev/cdrom:/ks.cfg

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

label linux
  menu label ^Install CentOS 7
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=hd:LABEL=CentOS\x207\x20x86_64 quiet

Можно также добавить текстовую загрузку:

label text
  menu label ^Text install CentOS 7
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=hd:LABEL=CentOS\x207\x20x86_64 quiet text

Установка и Настройка OpenSSH-сервера

Устанавливаем статический ip

Ставит LEMP

Установка dokuwiki

Возня с SELinux

Перенос из KVM в VMware

dokuwiki

error: Failed dependencies:
	epel-release = 7 is needed by remi-release-7.6-2.el7.remi.noarch

Настройка брадмаузера

GNOME

А сначала нам нужно установить компоненты рабочего стола — а именно GNOME. Сделать это можно следующим образом.

Получим список групп доступного для установки программного обеспечения

yum grouplist

или так

yum groups list

Среди текста вывода команд мы увидим строку «GNOME Desktop»

Она то нам и нужна.

Запустить установку мы можем одной из следующих команд

yum groupinstall "GNOME Desktop"

или

yum groups install "GNOME Desktop"

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

yum groupinstall "Server with GUI"

или

yum groups install "Server with GUI"

После этого нам нужно указать, чтобы по умолчанию система загружалась в графический режим.

systemctl set-default graphical.target

Для того, чтобы активировать его без перезагрузки

systemctl start graphical.target

xrdp

Теперь перейдем к xrdp.

Сначала добавим нужный нам репозиторий. А понадобится нам EPEL — Extra Packages for Enterprise Linux. Найти ссылку на его текущую версию мы можем, заглянув по адресу http://download.fedoraproject.org/pub/epel.

В моем случае команды будут выглядеть следующим образом

wget http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-6.noarch.rpm
rpm -ivh epel-release-7-6.noarch.rpm

Еще одним вариантом, и соответственно, с тем же результатом, будет следующая команда, которая представляет из себя объединение двух предыдущих строк

rpm -ivh http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-6.noarch.rpm

Теперь, если мы введем команду

yum repolist

в списке вывода мы должны увидеть нечто подобное

epel/x86_64   Extra Packages for Enterprise Linux 7 - x86_64   10,042

Далее нам нужно установить xrdp.

yum install xrdp

Если после этого мы попытаемся запустить xrdp, то это у нас скорее всего не получится, а в логах (команда journalctl -xe) мы увидим сообщения «Failed at step EXEC spawning /usr/sbin/xrdp-sesman: Permission denied» и «Failed at step EXEC spawning /usr/sbin/xrdp: Permission denied».

Чтобы все-таки их запустить, нам нужно изменить контекст безопасности SELinux для этих двух файлов.

chcon -t bin_t /usr/sbin/xrdp
chcon -t bin_t /usr/sbin/xrdp-sesman

Запустить xrdp можно командой

systemctl start xrdp

а проверить, запустился ли он

systemctl status xrdp

Чтобы xrdp запускался каждый раз при старте системы

systemctl enable xrdp

Для подтверждения того, что он ожидает подключений на полагающемся ему порту 3389 можно ввести следующую команду

netstat -antup | grep xrdp

Firewall

Если на вашей системе активен межсетевой экран, потребуется разрешить прохождение трафика на порт 3389. Сделать это можно следующими командами

firewall-cmd --permanent --zone=public --add-port=3389/tcp
firewall-cmd --reload

Теперь можно попробовать подключиться к системе при помощи rdp-клиента, например, Microsoft Remote Desktop Connection.