Есть у меня куча разной документации и для удобства доступа к ней я поднимаю веб-сервер Apache (httpd) с виртуальным сайтом.
Т.к. по большей части в папках нет индексного файла, я прописываю опцию "+Indexes", чтобы Апач выводил мне список файлов.
Проблем обычно не было, а вот сделал это на машине с CentOS и появилась странная проблема — несмотря на указанную опцию список файлов в корне виртуального сайта не отображался, вместо него выводилась страница из дистрибутива Апача, а в логи записывалась ошибка «Directory index forbidden by Options directive». При этом в подпапках список файлов выводился нормально.
Долго не мог понять в чём проблема, ковыряние в конфигах и эксперименты не помогали.
Пришлось гуглить. Оказалось, что в стандартной установке Апача есть файл /etc/httpd/conf.d/welcome.conf, в котором, собственно, и сказано, что для корня не выводит список файлов, а выводить файл с ошибкой.
Я просто удалил (переименовал) этот файл и перезапустил Апач. Однако при обновлении Апача файл перезаписался и ситуация повторилась, тогда я файл оставил, но закомментировал строки в нём.

По-умолчанию диск не подключается. Диск нормально примонтировался после установки соответствующего модуля из репозитория elrepo:
yum install kmod-hfsplus

Соответствующая часть вывода команды mount:

/dev/sdd10 on /media/A1 type hfsplus (rw,nosuid,nodev,uhelper=hal)
/dev/sdd12 on /media/A2 type hfsplus (rw,nosuid,nodev,uhelper=hal)

Подключение к репозиторию CentOS7:

rpm --import http://elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm

Есть интерфейс из ВЛАН-10, на котором уже имеется IPv4-адрес, надо добавить второй адрес, но уже из IPv6-сети. Это можно сделать вот так:
ip addr add 2001:0db8:3:4:0:0:0:3/64 dev eth0.10

Удалить вот так:
ip addr del 2001:0db8:3:4:0:0:0:3/64 dev eth0.10

А чтобы при перезагрузке компьютера этот адрес появился снова добавляем записи для IPv6 в уже существующий файл /etc/sysconfig/network-scripts/ifcfg-eth0.10:
DEVICE=eth0.10
PHYSDEV=eth0
ONBOOT=yes
VID=10
IPADDR=10.1.1.3
NETMASK=255.255.255.0
BOOTPROTO=static
VLAN=yes
USERCTL=no
GATEWAY=10.1.1.1
PEERDNS=yes
DNS1=10.1.1.1
DNS2=10.1.1.2
DOMAIN=elcat.kg
# Добавляем данные для IPv6:
IPV6INIT=yes
IPV6ADDR=2001:0db8:3:4:0:0:0:3/64
IPV6_DEFAULTGW=2001:0db8:3:4:0:0:0:1

Пингуем командой ping6, а путь смотрим командой tracepath6.

Несколько примеров просмотра, удаления и добавления IPv6-маршрутов:
ip -6 route show
ip -6 route show ::/0
ip -6 route show default
ip -6 route delete ::/0
ip -6 route add default via 2001:0db8:3:4:0:0:0:1
ip -6 route add 2001:0db8:33:44::/64 via 2001:0db8:3:4:0:0:0:1
ip -6 route delete 2001:0db8:33:44::/64

К сожалению маршрут до конкретного хоста из подсети, на которую добавлен маршрут, не показывается:
ip -6 route show 2001:0db8:33:44:0:0:0:13
Только для заданной подсети:
ip -6 route show 2001:0db8:33:44::/64

Ну или старый, добрый netstat:
netstat -rn --inet6

В процессе загрузки нажать любую клавишу и прервать процесс:
Press any key to enter the menu
Bootins CentOS (...) in 4 seconds…

Выбираем нужное нам ядро и жмем «e» (edit).

Еще раз жмём «е» для того, чтобы отредактировать параметры.

В конце строки с параметрами дописываем «single».

Проверить можно командой /sbin/runlevel — будет буква S.

Перемонтировать корневой раздел на запись:
mount -n -o remount /

Какие сервисы запускаются на каких уровнях:
chkconfig --list

Какие уровни что означают:

# /etc/inittab
# Default runlevel. The runlevels used are:
# 0 — halt (Do NOT set initdefault to this)
# 1 — Single user mode
# 2 — Multiuser, without NFS (The same as 3, if you do not have
# networking)
# 3 — Full multiuser mode
# 4 — unused
# 5 — X11
# 6 — reboot (Do NOT set initdefault to this)

Примеры:

1. В каких случаях запускать mysqld:
chkconfig --level 23 mysqld on
2. Не запускать апач на уровнях 2 и 3:
chkconfig --level 23 httpd off
3. Не запускать апач вообще:
chkconfig httpd off

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

Тут нужен policy-routing — маршрутизация на основе определённых правил. Логика получается такая: ответы на запросы из подсети Б к моему адресу из подсети А отправлять с адреса из подсети А (т.е. на шлюз подсети А).

Маркируем соединения из сети Б к нашему адресу из сети А при помощи iptables и таблицу mangle (используется для изменения пакетов):
iptables -t mangle -I INPUT -i eth0 -s 10.1.100.0/24 -d 10.2.96.3 -j CONNMARK --set-mark 1
А на выходе копируем маркировку соединения в маркировку пакетов, насколько я понимаю, это означает, что мы маркируем пакеты промаркированных ранее соединений:
iptables -t mangle -I OUTPUT -s 10.2.96.3 -d 10.1.100.0/24 -j CONNMARK --restore-mark
Вероятно, в этом правиле можно обойтись и без указания адресов источника и адресата, но мне кажется так будет правильнее, более точно чтоли )

В таблицу маршрутизации 111 добавляем маршрут для сети Б, но на шлюз из подсети А:
ip route add to 10.1.100.0/24 via 10.2.96.1 dev eth0 table 111
И, наконец, добавляем правило для перенаправления пакетов с нашей маркировкой в отдельную таблицу маршрутизации:
ip rule add fwmark 1 lookup 111

Для удобства можно назначить название для таблицы в файле /etc/iproute2/rt_tables, которое можно будет использовать вместо номера.

Так же нужно проверить не включена ли проверка обратного пути (reverse path checking):
sysctl net.ipv4.conf.eth0.rp_filter
Если включена, то система будет проверять пакеты на соответствие источника интерфейсу, с которого пакет получен. Например, если пакет пришёл с адреса, который виден через другой интерфейс (а не тот, с которого пакет пришёл), то значит этот пакет надо отбросить.

Если всё заработало как надо, то сохраняем правила iptables в файл "/etc/sysconfig/iptables", а правила для маршрутизации в файл "/etc/sysconfig/network-scripts/route-eth0".

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

Посмотреть определённую таблицу маршрутизации:
ip route show table 111
Удалить маршрут из указанной таблицы
ip route del table 111 to 10.1.100.0/24
Посмотреть правила маршрутизации:
ip rule show
Удалить правило маршрутизации:
ip rule del fwmark 1

Как посмотреть правила iptables писать не буду )

В папке /proc можно найти много всякой полезной статистики, например:
/proc/meminfo — статистика по памяти;
/proc/diskstats — статистика по дискам;
/proc/net/dev — счётчики трафика на сетевых картах;

А ещё есть данные в папке /sys/class, например счётчики трафика на отдельных сетевых картах:

/sys/class/net/eth0/statistics/rx_bytes
/sys/class/net/eth0/statistics/tx_bytes
/sys/class/net/eth0/statistics/rx_packets
/sys/class/net/eth0/statistics/tx_packets

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

Для Firefox:
mkdir ~/.mozilla/plugins

Для Opera:
mkdir ~/.opera/plugins

Качаем с сайта Adobe install_flash_player_11_linux_i386.tar.gz и копируем оттуда файл libflashplayer.so в созданную папку. Перезапускаем браузер.

Добавление:
Opera сама подняла плагин, установленный для Firefox-а, т.к. путь к нему указан в настройках Opera: Preferences — Advanced — Plug-in Options — Plug-in path.
Список путей можно исправить.

Запарила служба NetworkManager, с ней толком непонятно что и почему не работает. То фиг разберёшь где ДНС-серверы указать, то не перезапускаются нормально сетевые настройки, то аська не подключается…
Довольно часто встречается совет вырубить нафиг эту службу. А, действительно, работал же я под ФриБСД без неё.
Остановить службу можно вот так:

sudo service NetworkManager stop

И, о чудо, перезапуск сети работает без ошибок, аська подключилась без проблем.

Убедимся, что эта служба не запустится после ребута:

#chkconfig --list | grep NetworkManager
NetworkManager  0:off   1:off   2:off   3:off   4:off   5:off   6:off

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

Посмотрел время в BIOS и убедился, что время на час вперёд:
#hwclock
Wed 13 Nov 2019 07:49:18 PM +06 -0.250483 seconds

Поменял время:
#hwclock --set --date «Wed 13 Nov 2019 06:54 PM»

Проверил — всё нормально теперь:
#hwclock
Wed 13 Nov 2019 06:54:03 PM +06 -0.130003 seconds

Все команды, в том числе для просмотра, должны выполняться от пользователя root.