Отключить репозитории UEK в Oracle Linux 6.9

У меня много машин с ядром, совместимым с Red Hat, и раньше это не было проблемой. Однако, последнее поведение по умолчанию, похоже, таково, что файл конфигурации репозитория обновляется с включенным UEK4 в «yum update»

Следующее «yum update» установит UEK4 и установит его в качестве ядра по умолчанию. Любые проблемы, вызванные этим, будут обнаружены при сбое следующей загрузки.

Было бы лучше, если бы я мог предварительно отключить репозиторий UEK4 до того, как файл репозитория будет даже обновлен с помощью yum.

Репозиторий yum по умолчанию файл конфигурации /etc/yum.repos.d/public-yum-ol6.repo , установленный с обновлением 9 OL6, содержит ссылки на переменные $ uek , $ uek3 и $ uek4 , предполагающий, что репозитории UEK можно отключить центральным способом.

[public_ol6_UEKR4]
name=Latest Unbreakable Enterprise Kernel Release 4 for Oracle Linux $releasever ($basearch)
baseurl=http://yum.oracle.com/repo/OracleLinux/OL6/UEKR4/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=$uekr4

Откуда yum может получить эти значения?

Могу ли я установить их где-нибудь, чтобы предотвратить "

Есть идеи, как это отладить?

Я сделал 2 дампа TCP.

Не работает:

15:10:07.281993 IP p4FC4B365.dip0.t-ipconnect.de.3237 > hetzner3.1740: Flags [S], seq 3664811831, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
15:10:10.281742 IP p4FC4B365.dip0.t-ipconnect.de.3237 > hetzner3.1740: Flags [S], seq 3664811831, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
15:10:16.282033 IP p4FC4B365.dip0.t-ipconnect.de.3237 > hetzner3.1740: Flags [S], seq 3664811831, win 8192, options [mss 1452,nop,nop,sackOK], length 0

Работает

15:11:01.929326 IP p4FC4B365.dip0.t-ipconnect.de.3238 > hetzner3.1740: Flags [S], seq 513688945, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
15:11:04.931110 IP p4FC4B365.dip0.t-ipconnect.de.3238 > hetzner3.1740: Flags [S], seq 513688945, win 8192, options [mss 1452,nop,wscale 8,nop,nop,sackOK], length 0
15:11:10.930925 IP p4FC4B365.dip0.t-ipconnect.de.3238 > hetzner3.1740: Flags [S], seq 513688945, win 8192, options [mss 1452,nop,nop,sackOK], length 0
15:11:10.930964 IP hetzner3.1740 > p4FC4B365.dip0.t-ipconnect.de.3238: Flags [S.], seq 4087654018, ack 513688946, win 29200, options [mss 1460,nop,nop,sackOK], length 0
15:11:10.960346 IP p4FC4B365.dip0.t-ipconnect.de.3238 > hetzner3.1740: Flags [.], ack 1, win 65340, length 0
15:11:10.971341 IP p4FC4B365.dip0.t-ipconnect.de.3238 > hetzner3.1740: Flags [P.], seq 1:513, ack 1, win 65340, length 512
15:11:10.971371 IP hetzner3.1740 > p4FC4B365.dip0.t-ipconnect.de.3238: Flags [.], ack 513, win 30016, length 0
15:11:10.971377 IP p4FC4B365.dip0.t-ipconnect.de.3238 > hetzner3.1740: Flags [P.], seq 513:627, ack 1, win 65340, length 114
15:11:10.971388 IP hetzner3.1740 > p4FC4B365.dip0.t-ipconnect.de.3238: Flags [.], ack 627, win 30016, length 0
15:11:10.974736 IP hetzner3.1740 > p4FC4B365.dip0.t-ipconnect.de.3238: Flags [P.], seq 1:129, ack 627, win 30016, length 128
15:11:10.975473 IP hetzner3.1740 > p4FC4B365.dip0.t-ipconnect.de.3238: Flags [P.], seq 129:281, ack 627, win 30016, length 152
15:11:11.006089 IP p4FC4B365.dip0.t-ipconnect.de.3238 > hetzner3.1740: Flags [.], ack 281, win 65060, length 0
0
задан 22 April 2017 в 15:11
1 ответ

У меня недостаточно репутации, чтобы задать вопрос, так что это больше комментарий / вопрос, чем ответ.

Успешная трассировка показывает, что сервер отвечает после того, как параметр масштабирования окна удален из SYN.

У вас есть примеры, когда сервер отвечает после первого SYN? Есть ли у них опция масштабирования окон?

Включено ли на сервере масштабирование окон? Что делает sysctl -a | grep scal show?

РЕДАКТИРОВАТЬ: Эта проблема / решение похоже на ваше: Почему сервер не отправляет пакет SYN / ACK в ответ на пакет SYN

1
ответ дан 4 December 2019 в 16:17

Теги

Похожие вопросы