У меня много машин с ядром, совместимым с 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
У меня недостаточно репутации, чтобы задать вопрос, так что это больше комментарий / вопрос, чем ответ.
Успешная трассировка показывает, что сервер отвечает после того, как параметр масштабирования окна удален из SYN.
У вас есть примеры, когда сервер отвечает после первого SYN? Есть ли у них опция масштабирования окон?
Включено ли на сервере масштабирование окон? Что делает sysctl -a | grep scal show?
РЕДАКТИРОВАТЬ: Эта проблема / решение похоже на ваше: Почему сервер не отправляет пакет SYN / ACK в ответ на пакет SYN