Мои записи касаемо операционной системы Linux
/etc/sysconfig/named
OPTIONS="-4"
/etc/named.conf
filter-aaaa-on-v4 yes;
и в зависимости что вы используете
# systemctl list-unit-files | grep named named-chroot-setup.service static named-chroot.service enabled named-setup-rndc.service static named.service disabled
перезапустить named-chroot (в моём случае)
systemctl restart named-chroot
или просто named (у меня он запрещён, привожу для примера)
systemctl restart named
Я предпочитаю давать таблице своё уникальное имя. Когда таблиц много это позволяет легче ориентировaться.
[root@server /] # cat /etc/iproute2/rt_tables # # reserved values # 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep # здесь добавить таблицу с уникальным ID и именем 102 directroute
После определения имени таблицы добавим файл /etc/sysconfig/network-scripts/route-vlan707
где vlan707 – имя интерфейса на котором определён IP и к которому будет привязан маршрут.
У меня это vlan.
[root@server /] # cat /etc/sysconfig/network-scripts/route-vlan707 # добавить route2 маршруты для directroute # таблица directroute определена в /etc/iproute2/rt_tables 109.122.38.249/32 dev vlan707table directroute default via 109.122.38.193 dev vlan707table directroute
Во втором файле определяем правило
[root@server /] # cat /etc/sysconfig/network-scripts/rule-vlan707 # add route2 rule for direct routing from 109.122.38.249/32 lookup directroute
Тепер чтобы правила попали в таблицу маршрутизации необходимо “передёрнуть” интерфейс
ifdown vlan707 && ifup vlan707
Либо перезапустить систему. В результате получим следующее:
[root@server /] # ip route show table directroute default via 109.122.38.193 dev vlan707 109.122.38.249 dev vlan707scope link [root@server /] # ip rule show all 0: from all lookup local 32765: from 109.122.38.249 lookup directroute 32766: from all lookup main 32767: from all lookup default
Команда w и who сильно тормозят при старте. А top тормозит при старте и во время работы. А кроме этого прилично жрёт процессор.
Кроме этого w отображает неверное количество залогиненных пользователей
[root@server ~]# w 18:52:03 up 444 days, 9:43, 51 user, load average: 0.01, 0.01, 0.01 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/2 180.118.262.14 18:32 0.00s 0.01s 0.00s w
Выяснилось что причиной послужил слишком большой файл /var/run/utmp
ls -la /var/run/utmp -rw-rw-r-- 1 root utmp 505323384 Oct 18 18:32 /var/run/utmp > /var/run/utmp
После этого нужно перелогиниться чтобы счётчик начал верно показывать активных пользователей.
Очень просто. Воспользоваться официальной информацией с сайта CoudFlare.
https://www.cloudflare.com/ips/
Для автоматизации можно использовать следующий запрос.
Например, этот bash скрипт создаст разрешающий список IPv4 для apache который можно поместить в конфиг или .htaccess
$ curl --silent https://www.cloudflare.com/ips-v4 | xargs 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 104.16.0.0/12 108.162.192.0/18 131.0.72.0/22 141.101.64.0/18 162.158.0.0/15 172.64.0.0/13 173.245.48.0/20 188.114.96.0/20 190.93.240.0/20 197.234.240.0/22 198.41.128.0/17
Установка NetworkManager тянет за собой кучу ненужных зависимостей которые часто не нужны и которые нельзя удалить но хочется заблокировать. Одна из них wpa_supplicant.
663 ? Ss 2:29 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation 666 ? S 0:03 /usr/sbin/chronyd 706 ? Ss 0:16 /usr/sbin/crond -n 716 tty1 Ss+ 0:00 /sbin/agetty --noclear tty1 linux 749 ? Ss 0:00 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant
Остановить
Запретить
И “слить” в /dev/null
systemctl stop wpa_supplicant systemctl disable wpa_supplicant systemctl mask wpa_supplicant.service
Centos 7 как вернуть iptables вместо firewalld
Я считал, считаю и буду считать, что iptables в его старом чистом виде больше подходит для серверов чем новомодный firewalld который сначала запихнули в дистрибутивы федоры начиная с 18-й, а теперь ещё и в RHEL7 и Centos 7. Во-первых потому, что firewalld генерирует большое количество бессмысленных правил которые излишне тормозят работу iptables. Я пробежался по цепочке INPUT пустого настроенного по умолчанию firewalld и насчитал там 14!!! пустых переходов! Возможно это гениальное приложение с очень продуманной архитектурой, но вот однозначно ему не место в высоконагруженных системах. Во-вторых читать и понимаеть вывод iptables -nvL без обработки практически невозможно.
В-третьих на серверах нет нужды динамически управлять iptables, а fail2ban при небольших доработках конфигов прекрасно справляется со своей работой.
Поэтому если я устанавливаю сервер на Centos 7, то первым делом я возвращаю iptables.
Continue reading iptables в RHEL 7 / Centos 7
При отключённом ipv6 в centos 6.7 (Final) столкнулся с тем что не запускается сеть и не создаётся бридж.
[root@fileserver ~]# virsh net-start routed error: Failed to start network routed error: Unable to create bridge virbr1: Package not installed
В логе
Apr 13 13:41:35 fileserver kernel: bridge: Unknown symbol ipv6_dev_get_saddr
Для исправления нужно в файле disable-ipv6.conf прописать правильную опцию
cat /etc/modprobe.d/disable-ipv6.conf #install ipv6 /bin/true options ipv6 disable_ipv6=1
И убрать ipv6 и net-pf-10 если они были добавлены в файл /etc/modprobe.d/blacklist.conf
[root@fileserver modprobe.d]# virsh net-start routed Network routed started
[root@fileserver modprobe.d]# virsh net-list --all Name State Autostart Persistent -------------------------------------------------- default inactive no yes routed active no yes
Apr 13 13:46:26 fileserver kernel: NET: Registered protocol family 10 Apr 13 13:46:26 fileserver kernel: lo: Disabled Privacy Extensions Apr 13 13:46:26 fileserver kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready Apr 13 13:46:26 fileserver kernel: tun0: Disabled Privacy Extensions Apr 13 13:46:26 fileserver kernel: Bridge firewalling registered Apr 13 13:46:26 fileserver kernel: device virbr1-nic entered promiscuous mode Apr 13 13:46:26 fileserver kernel: virbr1: starting userspace STP failed, starting kernel STP
В повседневной работе я пользуюсь десятками включённых VPN клиентов. Эти клиенты соединяются с разными серверами, а серверы имеют разные настройки. Так например у меня возникала ситуация когда нужный мне роут пробрасывался через TUN интерфейс который PUSH-ился с сервера. Если бы сервер использовал только я стоило бы перенастроить только сервер чтобы это исправить. Однако сервером пользуются и другие люди и там этот PUSH необходим. Сначала я руками переписывал роут и забывал до следующего переподключения. Но последнее время часто приходилось переподключаться и вечное переписывание роута стало раздражать. В документации к OpenVPN написано что в настройках с недавнего времени появился ключ который поможет клиенту отвергнуть то что ему предлагает сервер.
Continue reading OpenVPN как не принять предложение сервера о настройке интерфейсов
Время идёт и постепенно старые алгоритмы шифрования становятся небезопасными. Разрабочики софта конечно же постепенно их отключают. Но для админа-то обычно это просиходит внезапно и ой как не вовремя и становится чертовски неприятным сюрпризом, особенно если обновления накатываются атоматически. Так обновление на Fedora 23 подарило мне пару незабываемых часов когда я не мог достучаться на большую часть серверов которыми управляю. Казалось бы что обновление openssl, openssh в любом виде должно стать красной тряпкой, но пока что стереотип поведения не сложился. И последнее обновление openssh.i686 7.2p1-2.fc23, openssh-server.i686 7.2p1-2.fc23, openssh-clients.i686 7.2p1-2.fc23 снова подарило неожиданный сюрприз в виде невозможности залогиниться на клиентский mikrotik.
[user001@localhost ~]$ ssh root@192.168.88.1 ssh_dispatch_run_fatal: Connection to 192.168.88.1 port 22: DH GEX group out of range
И как обычно бывает в свежих случаях гугл и яндекс не показали ничего интересного.
— Упс, сказал я и полез в мануал.
Continue reading Обновление ssh и очередное отключение устаревших алгоритмов
Когда вы редактируете файл /etc/sudoers или создаёте подключаемые к нему файлы в каталоге /etc/sudoers.d/* то неплохо бы сразу проверить синтаксис. Если вы редактируете sudoers в его редакторе visudo то он автоматически проверит синтаксис при сохранении. А если как я больше пользуетесь mcedit то после редактирования sudoers можно выполнить проверку указав ключ:
[root@d01 sudoers.d]# visudo -c /etc/sudoers: parsed OK /etc/sudoers.d/zabbix_sudo: parsed OK
Как видите синтаксис проверился вместе со вложением /etc/sudoers.d/zabbix_sudo.
Но на боевом сервере, где sudo активно используется системой мониторинга или каким либо скриптом из crontab, не стоит проводить правку файла по-живому. Для этого его можно скопировать в другое место и там редактировать. А после редактирования проверить всё той же командой но с дополнительным ключом:
[root@d01 sudoers.d]# visudo -cf /root/sudoers.new /root/sudoers.new: parsed OK
После этого его можно смело копировать на место боевого файла. Не забудтре однако правильно поставить права 440 для владелеца и группы root:root.