[root@localhost client]# pvcreate /dev/sda
Can't open /dev/sda exclusively. Mounted filesystem?
Can't open /dev/sda exclusively. Mounted filesystem?
[root@localhost client]# mount | grep /dev/sda
[root@localhost client]#
[root@localhost client]# fuser -m -v /dev/sda1
[root@localhost client]#
[root@localhost client]# cat /proc/mdstat
Personalities :
md127 : inactive sda[0](S)
1875243352 blocks super 1.2
[root@localhost client]# mdadm --stop /dev/md127
mdadm: stopped /dev/md127
[root@localhost client]# cat /proc/mdstat
Personalities :
unused devices: <none>
[root@localhost client]# mdadm --zero-superblock /dev/sda
[root@localhost client]#
Category: Linux
Мои записи касаемо операционной системы Linux
gitlab push -> jenkins build
При настройке автоматического билда из gitlab в jenkins я столкнулся с двумя проблемами.
Первая проблема связана с настройками gitlab
при попытке вызвать url Test->push – выдаёт ошибку 500.
Проблема решается включением опции https://your.git.lab/admin/application_settings
Outbound requests -> [v] Allow requests to the local network from hooks and services
Вторая проблема
Connection: close Date: Sun, 07 Jul 2019 11:52:52 GMT X-Content-Type-Options: nosniff Cache-Control: must-revalidate,no-cache,no-store Content-Type: text/html;charset=iso-8859-1 Content-Length: 415 Server: Jetty(9.4.z-SNAPSHOT)
<html> <head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> <title>Error 403 No valid crumb was included in the request</title> </head> <body><h2>HTTP ERROR 403</h2> <p>Problem accessing /job/Autodeploy/job/autobuild/build. Reason: <pre> No valid crumb was included in the request</pre></p><hr><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.z-SNAPSHOT</a><hr/> </body> </html>
Для подавления этой проблемы нужно отключить защиту от CSRF/XSRF
https://your.jenkins.site/configureSecurity/
CSRF Protection -> [ ] Prevent Cross Site Request Forgery exploits
iscsiadm: No portals found
Iscsi клиент с адреса 10.5.252.5 пытается соединиться с сервером 10.5.4.58 но упорно не видит target который со стороны сервера является вторым target (первый таргет работает с другим клиентом).
Забегая вперёд поясню – проблема в правах доступа.
Одиночный IPv4 адрес в ACL нужно записывать без префикса подсетки /32
Для тех кто хочет понять процесс поиска проблемы опишу немного деталей:
1) selinux временно переключён в Permissive.
[root@localhost server]# setenforce 0 [root@localhost server]# getenforce Permissive
2) iptables принимает входящие соединения на tcp порт 3260
[root@localhost server]# iptables -nvL INPUT | grep 3260
91 46412 ISCSI tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:3260
[root@localhost server]# iptables -nvL ISCSI
Chain ISCSI (1 references)
pkts bytes target prot opt in out source destination
77 4484 ACCEPT all -- bond0 * 10.5.0.0/16 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `ISCSI '
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
3) и iscsi сервер tdtd слушает все нужные адреса и интерфейсы
[root@localhost server]# netstat -nlptu | grep tgt tcp 0 0 0.0.0.0:3260 0.0.0.0:* LISTEN 2555/tgtd tcp 0 0 :::3260 :::* LISTEN 2555/tgtd
4) разумеется, между клиентом и сервером есть сетевая связность на уровне tcp и порта 3260.
[root@localhost client]# tcping 10.5.4.58 3260 10.5.4.58 port 3260 open.
Вот что показывает клиент при попытке получить список target с сервера
[root@localhost client]# iscsiadm --mode discoverydb --type sendtargets --portal 10.5.4.58 --discover iscsiadm: No portals found
А вот настройка ACL со стороны сервера на втором target
[root@localhost server]# tgtadm --op show --mode target
...
...
...
ACL information:
10.5.252.5/32
И кажется что всё ок так как tcpdump показывает двухстороннюю коммуникацию между клиентом и сервером.
Но клиент упорно не видит target.
Запускаем tcpdump на сервере (можно и на клиенте) и после этого на клиенте запускаем команду discover:
[root@localhost server]# tcpdump -nn -i bond0 port 3260 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:42:45.595466 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [S], seq 1277547255, win 64240, options [mss 1366,sackOK,TS val 2794562310 ecr 0,nop,wscale 7], length 0 06:42:45.595500 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [S.], seq 2558380001, ack 1277547256, win 18280, options [mss 9152,sackOK,TS val 2387301250 ecr 2794562310,nop,wscale 7], length 0 06:42:45.613325 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [.], ack 1, win 502, options [nop,nop,TS val 2794562328 ecr 2387301250], length 0 06:42:45.614251 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [P.], seq 1:49, ack 1, win 502, options [nop,nop,TS val 2794562328 ecr 2387301250], length 48 06:42:45.614274 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [.], ack 49, win 143, options [nop,nop,TS val 2387301269 ecr 2794562328], length 0 06:42:45.616822 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [P.], seq 49:309, ack 1, win 502, options [nop,nop,TS val 2794562329 ecr 2387301250], length 260 06:42:45.616845 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [.], ack 309, win 152, options [nop,nop,TS val 2387301271 ecr 2794562329], length 0 06:42:45.616973 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [P.], seq 1:193, ack 309, win 152, options [nop,nop,TS val 2387301271 ecr 2794562329], length 192 06:42:45.635230 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [.], ack 193, win 501, options [nop,nop,TS val 2794562349 ecr 2387301271], length 0 06:42:45.637398 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [P.], seq 309:357, ack 193, win 501, options [nop,nop,TS val 2794562350 ecr 2387301271], length 48 06:42:45.637889 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [P.], seq 357:373, ack 193, win 501, options [nop,nop,TS val 2794562350 ecr 2387301271], length 16 06:42:45.637955 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [.], ack 373, win 152, options [nop,nop,TS val 2387301292 ecr 2794562350], length 0 06:42:45.638005 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [P.], seq 193:241, ack 373, win 152, options [nop,nop,TS val 2387301292 ecr 2794562350], length 48 06:42:45.659009 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [.], ack 241, win 501, options [nop,nop,TS val 2794562371 ecr 2387301292], length 0 06:42:45.661256 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [R.], seq 373, ack 241, win 501, options [nop,nop,TS val 2794562372 ecr 2387301292], length 0 ^C 15 packets captured 15 packets received by filter 0 packets dropped by kernel
Заглянув внутрь пакетов видно что спрашивает клиент и что ему отвечает сервер.
[root@localhost server]# tcpdump -nn -xX -i bond0 port 3260
Из увиденного понятно, что сервер не посылает клиенту списка target.
На другом рабочем target в содержимом одного из последних пакетов видно открытым текстом имя target переданного сервером:
09:45:42.163005 IP 10.5.4.58.3260 > 10.5.252.5.38630: Flags [P.], seq 193:317, ack 373, win 152, options [nop,nop,TS val 2398277817 ecr 2805538873], length 124 0x0000: 4500 00b0 8ee5 4000 4006 9719 0a05 043a E.....@.@......: 0x0010: 0a05 fc05 0cbc 96e6 5bc2 5f01 eb86 52a3 ........[._...R. 0x0020: 8018 0098 14ec 0000 0101 080a 8ef2 d0b9 ................ 0x0030: a739 2039 2480 0000 0000 0049 0000 0000 .9.9$......I.... 0x0040: 0000 0000 0000 0001 ffff ffff 0000 0001 ................ 0x0050: 0000 0002 0000 0002 0000 0000 0000 0000 ................ 0x0060: 0000 0000 5461 7267 6574 4e61 6d65 3d69 ....TargetName=i 0x0070: 716e 2e32 3031 352d 3132 2e63 6f6d 2e76 qn.2015-12.com.v 0x0080: 6473 3a69 7363 7369 6469 736b 3200 5461 ds:iscsidisk2.Ta 0x0090: 7267 6574 4164 6472 6573 733d 3130 2e35 rgetAddress=10.5 0x00a0: 2e34 2e35 383a 3332 3630 2c31 0000 0000 .4.58:3260,1....
Из этого можно предположить что сервер не считает клиента авторизованным для какой либо информации о target
Для дебага на втором target, который не появляется на клиенте, добавляем в ACL все адреса:
[root@localhost server]# tgtadm --lld iscsi --mode target --op bind --tid 2 --initiator-address=ALL
Клиент увидел второй target!
[root@localhost client]# iscsiadm --mode discoverydb --type sendtargets --portal 10.5.4.58 --discover 10.5.4.58:3260,1 iqn.2015-12.com.vds:iscsidisk2
Убираем доступ со всех адресов из ACL. Убираем и адрес с префиксом. И добавляем только адрес одного клиента без префикса.
[root@localhost server]# tgtadm --lld iscsi --mode target --op unbind --tid 2 --initiator-address=ALL
[root@localhost server]# tgtadm --lld iscsi --mode target --op unbind --tid 2 --initiator-address=10.5.252.5/32
[root@localhost server]# tgtadm --lld iscsi --mode target --op unbind --tid 2 --initiator-address=10.5.252.5
[root@localhost server]# tgtadm --op show --mode target
...
...
...
ACL information:
10.5.252.5
Готово.
sshd – запрет вывода о последнем успешном логине и количестве неуспешных логинов
Для средств автоматизации которые выделяют терминал на удалённом сервере бывает необходимо запретить вывод сообщения следующего вида:
Last failed login: Thu Jun 27 04:49:56 EDT 2019 from 206.189.129.131 on ssh:notty There were 752 failed login attempts since the last successful login. Last login: Wed Jun 26 11:44:44 2019 from 22.158.126.144
Запретить можно двумя способами, для индивидуально для определённых пользователей и глобально для системы.
Запрет только для выбратнного пользователя username:
touch /home/username/.hushlogin
Запрет глобально для всей системы:
Отредактируйте файл /etc/ssh/sshd_config
PrintLastLog no systemctl restart httpd
ПРЕДУПРЕЖДЕНИЕ!
Опция PrintLastLog не работает в Match секциях.
Опция работает только глобально! Тоесть её нельзя использовать для пользователя или группы.
Запрет разрешения ipv6 адресов в bind
/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
Настройка статических iproute2 правил в Centos7
Я предпочитаю давать таблице своё уникальное имя. Когда таблиц много это позволяет легче ориентиров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
Команда 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
После этого нужно перелогиниться чтобы счётчик начал верно показывать активных пользователей.
Как получить все IP адреса CoudFlare
Очень просто. Воспользоваться официальной информацией с сайта 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
Отключение wpa_supplicant на VDS или десктопе где нет WiFi
Установка 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
iptables в RHEL 7 / Centos 7
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