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

Как получить все IP адреса incapsula.com

Отключение 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

Centos. Unable to create bridge virbr1 Package not installed.

При отключённом 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