Задача: у нас есть файл со списком стилей/скриптов/бинарников (нужное подчернуть) которые надо скопировать или переместить в другое место.
Да. Такие задачи бывают. :)

Допустим выглядит файл как-то так

$ cat css.txt  
css/reset-ls.css  
css/b-browser.css  
css/reg-form.css  
css/old/pop-up.css

Пути либо относительные, либо полные.

Скопировать все в новый локейшн можно простым однострочником

$ for i in $(cat css.txt); do cp $i /tmp/; done

SELinux штука очень мощная и полезная. Но вот незадача: иногда ее настроить бывает слишком тяжело. И можно просто довести систему до состояния, когда она не загружается (особенно если играться с политикой доступа к каталогам :)).
Для таких случаев нужно уметь сбрасывать политики в дефолтное состояние.
Сначала загружаем систему в failback-режиме (там selinux отключен).

Теперь

setenforce 0  
# dnf erase selinux-policy selinux-policy-targeted  
# dnf mv /etc/selinux/targeted{,.backup}  
# reboot

После перезагрузки системы selinux будет отключен.

Нужно поставить пакеты, которые мы удаляли.

# dnf install selinux-policy selinux-policy-targeted

И теперь включить сам механизм. Для этого отредактируем файл /etc/selinux/config и заменим

SELINUX=disabled

на

SELINUX=enforcing

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

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

Документация.

Казалось бы: что может быть проще, чем взять два бекенда и одну точку входа.
Когда первый бекенд не отвечает (или отвечает, но 404), то перенаправлять запрос (как можно прозначнее для пользователя) на второй бекенд.
Правильно! :) Проще быть ничего не может.

location / {  
 # Отправляем все 404 на @backendB  
 error_page 404 = @backendB;  
 proxy_intercept_errors on;  
 log_not_found off;  
 # Try the proxy like normal  
 proxy_set_header X-Forwarded-For $remote_addr;  
 proxy_set_header Host $host;  
 proxy_set_header X-Real-IP $remote_addr;  
 proxy_pass http://127.0.0.1:8081;  
}

location @backendB {  
 # Резервный бекенд  
 proxy_set_header X-Forwarded-For $remote_addr;  
 proxy_set_header Host $host;  
 proxy_set_header X-Real-IP $remote_addr;  
 proxy_pass http://127.0.0.1:8082;

# Настоящую 404ую мы уже получим от этого бекенда.

}

После очередного “незапланированного” обновления у меня вдруг отвалился gitlab.
В логах

/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_su  
pport/dependencies.rb:247:in `require': Incorrect MySQL client library version!  
This gem was compiled for 5.5.42 but the client library is 5.6.25. (RuntimeError  
)

Надо обновлять.
Беда в том, что в ruby я не нашел аналога pip update или что-то в таком духе.

Для обновления предустановленных бандлов нужно удалить старые и поставить новые (заново).

$ sudo -u git mv /home/git/gitlab/vendor/bundle{,.bkp}

sudo -u git -H bundle install --without development test postgres --deployment

Мануал по обновлению гитлаба: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/patch_versions.md.

Создаем виртуальное окружение как указано в доке.
Путь к окружению должен выглядеть как

<путь к проекту>/.venv

И не забудьте добавить эту папку в .gitignore.

Теперь в корне проекта создаем файл .pycharmrc

source ~/.bashrc  
source .venv/bin/activate

Осталось добавить запуск нашего окружения в настройках Tools -> Terminal.

Прописываем свойство Shell path как

/bin/bash --rcfile .pycharmrc