vbalykin

Обнаружил сегодня в логах Cisco 9300T ругань на один из портов, объединённых в etherchannel: May 25 2022 21:44:55 VLDK: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/8, changed state to down May 25 2022 21:44:56 VLDK: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/8, changed state to down May 25 2022 21:44:59 VLDK: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/8, changed state to up May 25 2022 21:45:00 VLDK: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/8, changed state to up May 25 2022 21:45:06 VLDK: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/8, changed state to down May 25 2022 21:45:07 VLDK: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/8, changed state to down May 25 2022 21:45:09 VLDK: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/8, changed state to up May 25 2022 21:45:11 VLDK: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/8, changed state to up May 25 2022 21:48:16 VLDK: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/8, changed state to down May 25 2022 21:48:17 VLDK: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/8, changed state to down May 25 2022 21:48:19 VLDK: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/8, changed state to up May 25 2022 21:48:20 VLDK: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/8, changed state to up May 25 2022 21:49:10 VLDK: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1/0/8, changed state to down May 25 2022 21:49:11 VLDK: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/8, changed state to down May 25 2022 21:49:18 VLDK: %ETC-5-CANNOT_BUNDLE2: Gi1/0/8 is not compatible with Gi2/0/8 and will be suspended (speed of Gi1/0/8 is 100M, Gi2/0/8 is 1000M) May 25 2022 21:49:20 VLDK: %LINK-3-UPDOWN: Interface GigabitEthernet1/0/8, changed state to up И действительно, один из портов находится в статусе s (suspended): #show etherchannel 8 sum Flags: D - down P - bundled in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator M - not in use, minimum links not met u - unsuitable for bundling w - waiting to be aggregated d - default port A - formed by Auto LAG Number of channel-groups in use: 18 Number of aggregators: 18 Group Port-channel Protocol Ports ------+-------------+-----------+----------------------------------------------- 8 Po8(SU) LACP Gi1/0/8(s) Gi2/0/8(P) К этим портам подключен сервер Fujitsu RX200 S6 с гигабитными сетевыми адаптерами Intel 82575EB, на нём крутится Proxmox v5.2-6. Вот фрагмент лога из /var/log/messages: May 25 21:44:54 pve80 kernel: [8679920.776723] igb 0000:01:00.0 ens1f0: igb: ens1f0 NIC Link is Down May 25 21:44:56 pve80 kernel: [8679923.417013] igb 0000:01:00.0 ens1f0: igb: ens1f0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX May 25 21:44:57 pve80 kernel: [8679923.496746] bond0: link status definitely up for interface ens1f0, 1000 Mbps full duplex May 25 21:45:04 pve80 kernel: [8679931.200718] igb 0000:01:00.0 ens1f0: igb: ens1f0 NIC Link is Down May 25 21:45:07 pve80 kernel: [8679933.901045] igb 0000:01:00.0 ens1f0: igb: ens1f0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX May 25 21:45:07 pve80 kernel: [8679934.000750] bond0: link status definitely up for interface ens1f0, 1000 Mbps full duplex May 25 21:48:14 pve80 kernel: [8680121.056715] igb 0000:01:00.0 ens1f0: igb: ens1f0 NIC Link is Down May 25 21:48:17 pve80 kernel: [8680123.721015] igb 0000:01:00.0 ens1f0: igb: ens1f0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX May 25 21:48:17 pve80 kernel: [8680123.848778] bond0: link status definitely up for interface ens1f0, 1000 Mbps full duplex May 25 21:49:08 pve80 kernel: [8680175.144716] igb 0000:01:00.0 ens1f0: igb: ens1f0 NIC Link is Down May 25 21:49:17 pve80 kernel: [8680184.381067] igb 0000:01:00.0 ens1f0: igb: ens1f0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX May 25 21:49:17 pve80 kernel: [8680184.381180] igb 0000:01:00.0 ens1f0: Link Speed was downgraded by SmartSpeed May 25 21:49:17 pve80 kernel: [8680184.396767] bond0: link status definitely up for interface ens1f0, 100 Mbps full duplex Настройка бондинга на Proxmox v5.2-6 /etc/network/interfaces iface ens1f0 inet manual iface ens1f1 inet manual auto bond0 iface bond0 inet manual slaves ens1f0 ens1f1 bond_miimon 100 bond-mode 802.3ad bond-lacp-rate slow Выжимка из lshw: *-network:0 description: Ethernet interface product: 82575EB Gigabit Network Connection vendor: Intel Corporation physical id: 0 bus info: pci@0000:01:00.0 logical name: ens1f0 version: 02 serial: 00:26:2d:09:3b:18 size: 100Mbit/s capacity: 1Gbit/s width: 32 bits clock: 33MHz capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.4.0-k duplex=full firmware=2.1.5 latency=0 link=yes multicast=yes port=twisted pair slave=yes speed=100Mbit/s resources: irq:24 memory:ce160000-ce17ffff memory:ce140000-ce15ffff ioport:2000(size=32) memory:ce100000-ce103fff memory:ce120000-ce13ffff *-network:1 description: Ethernet interface product: 82575EB Gigabit Network Connection vendor: Intel Corporation physical id: 0.1 bus info: pci@0000:01:00.1 logical name: ens1f1 version: 02 serial: 00:26:2d:09:3b:18 size: 1Gbit/s capacity: 1Gbit/s width: 32 bits clock: 33MHz capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation configuration: autonegotiation=on broadcast=yes driver=igb driverversion=5.4.0-k duplex=full firmware=2.1.5 latency=0 link=yes multicast=yes port=twisted pair slave=yes speed=1Gbit/s resources: irq:38 memory:ce1c0000-ce1dffff memory:ce1a0000-ce1bffff ioport:2020(size=32) memory:ce104000-ce107fff memory:ce180000-ce19ffff Настройки бондинга на Cisco 9300T: interface Port-channel8 switchport mode trunk switchport nonegotiate ! interface GigabitEthernet1/0/8 switchport mode trunk switchport nonegotiate channel-group 8 mode active ! interface GigabitEthernet2/0/8 switchport mode trunk switchport nonegotiate channel-group 8 mode active ! Версия IOS: Cisco IOS XE Software, Version 17.03.04 Cisco IOS Software [Amsterdam], Catalyst L3 Switch Software (CAT9K_IOSXE), Version 17.3.4, RELEASE SOFTWARE (fc3) В этот момент времени никаких работ не проводилось, какая-либо нагрузка тоже отсутствовала. Кто виноват в данной ситуации: Cisco, Proxmox, кто-то ещё?

Промахнулся с разделом, прошу модераторов удалить тему.

Имеется в наличии сервер с материнской платой Gigabyte X99-UD3-CF и процессором Intel® Core i7-5820K CPU @ 3.30GHz. Сетевые адаптеры: 82599 10 Gigabit Dual Port Network Connection - наружу, двухпортовая 82576 Gigabit Network Connection в бондинге - внутрь. # lspci 03:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Network Connection (rev 01) 03:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Network Connection (rev 01) 04:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 04:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) ОС: CentOS 6.6. Ядро из ELRepo: 3.10.82-1.el6.elrepo.x86_64. Основная задача: раздача канала Интернет в локальную сеть. Текущая загрузка канала около 0,9-1 Гбит. Строка загрузки: kernel /vmlinuz-3.10.82-1.el6.elrepo.x86_64 ro root=UUID=cf3f5006-9a57-4c46-8cbd-1b5d0b63cf5c LANG=ru_RU.UTF-8 rd_NO_LUKS rd_MD_UUID=6bbd30d8:cd1327d3:ef8a5f0e:4d4853f8 rd_MD_UUID=87b79310:10324238:687ab647:896d9326 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=ru rd_NO_LVM rd_NO_DM rhgb iommu=off intel_iommu=off intel_idle.max_cstate=0 processor.max_cstate=1 idle=poll quiet Драйвера последние с сайта Intel. Выжимка из /var/log/messages: Intel(R) Gigabit Ethernet Network Driver - version 5.3.2 Copyright (c) 2007-2015 Intel Corporation. igb: 0000:04:00.0: igb_validate_option: RSS - RSS multiqueue receive count set to 2 igb: 0000:04:00.0: igb_validate_option: QueuePairs - Tx/Rx queue pairs for interrupt handling Enabled igb 0000:04:00.0: added PHC on eth1 igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection igb 0000:04:00.0: eth1: (PCIe:2.5GT/s:Width x4) igb 0000:04:00.0 eth1: MAC: 00:1b:21:36:5c:82 igb 0000:04:00.0: eth1: PBA No: E43709-003 igb 0000:04:00.0: LRO is disabled igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s) igb: 0000:04:00.1: igb_validate_option: RSS - RSS multiqueue receive count set to 2 igb: 0000:04:00.1: igb_validate_option: QueuePairs - Tx/Rx queue pairs for interrupt handling Enabled igb 0000:04:00.1: added PHC on eth1 igb 0000:04:00.1: Intel(R) Gigabit Ethernet Network Connection igb 0000:04:00.1: eth1: (PCIe:2.5GT/s:Width x4) igb 0000:04:00.1 eth1: MAC: 00:1b:21:36:5c:83 igb 0000:04:00.1: eth1: PBA No: E43709-003 igb 0000:04:00.1: LRO is disabled igb 0000:04:00.1: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s) Intel(R) 10 Gigabit PCI Express Network Driver - version 4.1.2 Copyright (c) 1999-2015 Intel Corporation. ixgbe: Receive-Side Scaling (RSS) set to 2 ixgbe: 0000:03:00.0: ixgbe_check_options: FCoE Offload feature enabled ixgbe: allow_unsupported_sfp Enabled ixgbe 0000:03:00.0 (unregistered net_device): WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation ixgbe 0000:03:00.0: PCI Express bandwidth of 32GT/s available ixgbe 0000:03:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%) ixgbe 0000:03:00.0 eth1: MAC: 2, PHY: 17, SFP+: 5, PBA No: E66560-003 ixgbe 0000:03:00.0: 00:1b:21:90:fe:f8 ixgbe 0000:03:00.0 eth1: Enabled Features: RxQ: 2 TxQ: 2 FdirHash ixgbe 0000:03:00.0 eth1: Intel(R) 10 Gigabit Network Connection ixgbe: Receive-Side Scaling (RSS) set to 2 ixgbe: 0000:03:00.1: ixgbe_check_options: FCoE Offload feature enabled ixgbe: allow_unsupported_sfp Enabled ixgbe 0000:03:00.1: PCI Express bandwidth of 32GT/s available ixgbe 0000:03:00.1: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%) ixgbe 0000:03:00.1 eth4: MAC: 2, PHY: 1, PBA No: E66560-003 ixgbe 0000:03:00.1: 00:1b:21:90:fe:f9 ixgbe 0000:03:00.1 eth4: Enabled Features: RxQ: 2 TxQ: 2 FdirHash ixgbe 0000:03:00.1 eth4: Intel(R) 10 Gigabit Network Connection При работе наблюдаем странность, а именно повышенную нагрузку read_hpet: # perf top 84,79% [kernel] [k] cpu_idle_loop 7,16% [kernel] [k] read_hpet 0,59% [kernel] [k] module_get_kallsym 0,39% [kernel] [k] _raw_spin_lock 0,34% [kernel] [k] kallsyms_expand_symbol.clone.0 0,33% [kernel] [k] u32_classify 0,20% [kernel] [k] format_decode 0,17% [kernel] [k] add_interrupt_randomness 0,15% perf [.] symbols__insert 0,13% [kernel] [k] strnlen 0,11% [kernel] [k] vsnprintf В настоящий момент clocksource выбран HPET: /sys/devices/system/clocksource/clocksource0/current_clocksource hpet После изучения форума сложилось впечатление, что должно помочь изменение clocksource с hpet на tsc, но tsc нет в списке доступных источников: /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm TSC по какой-то причине отключается на этапе загрузки: tsc: Fast TSC calibration using PIT tsc: Detected 3300.005 MHz processor Calibrating delay loop (skipped), value calculated using timer frequency.. 6600.01 BogoMIPS (lpj=3300005) smpboot: CPU0: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz (fam: 06, model: 3f, stepping: 02) TSC deadline timer enabled Performance Events: no PEBS fmt2+, generic architected perfmon, Intel PMU driver. ... version: 3 ... bit width: 48 ... generic registers: 8 ... value mask: 0000ffffffffffff ... max period: 000000007fffffff ... fixed-purpose events: 3 ... event mask: 00000007000000ff smpboot: Booting Node 0, Processors #1 TSC synchronization [CPU#0 -> CPU#1]: Measured 193093878915547 cycles TSC warp between CPUs, turning off TSC clock. tsc: Marking TSC unstable due to check_tsc_sync_source failed С чем может быть связано отключение TSC? Это программная или аппаратная проблема? Можно ли как-то принудительно включить TSC на этапе загрузки? Ни на одном из доступных компьютеров подобной проблемы не наблюдается, поиск в Google ни к чему не привёл. Какие ещё варианты можно попробовать? Может ли помочь обновление BIOS, обновление ядра?

Имеется в наличии сервер с материнской платой Gigabyte X99-UD3-CF и процессором Intel® Core i7-5820K CPU @ 3.30GHz. Сетевые адаптеры: 82599 10 Gigabit Dual Port Network Connection - наружу, двухпортовая 82576 Gigabit Network Connection в бондинге - внутрь. # lspci 03:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Network Connection (rev 01) 03:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port Network Connection (rev 01) 04:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 04:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) ОС: CentOS 6.6. Ядро из ELRepo: 3.10.82-1.el6.elrepo.x86_64. Основная задача: раздача канала Интернет в локальную сеть. Текущая загрузка канала около 0,9-1 Гбит. Строка загрузки: kernel /vmlinuz-3.10.82-1.el6.elrepo.x86_64 ro root=UUID=cf3f5006-9a57-4c46-8cbd-1b5d0b63cf5c LANG=ru_RU.UTF-8 rd_NO_LUKS rd_MD_UUID=6bbd30d8:cd1327d3:ef8a5f0e:4d4853f8 rd_MD_UUID=87b79310:10324238:687ab647:896d9326 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=ru rd_NO_LVM rd_NO_DM rhgb iommu=off intel_iommu=off intel_idle.max_cstate=0 processor.max_cstate=1 idle=poll quiet Драйвера последние с сайта Intel. Выжимка из /var/log/messages: Intel(R) Gigabit Ethernet Network Driver - version 5.3.2 Copyright (c) 2007-2015 Intel Corporation. igb: 0000:04:00.0: igb_validate_option: RSS - RSS multiqueue receive count set to 2 igb: 0000:04:00.0: igb_validate_option: QueuePairs - Tx/Rx queue pairs for interrupt handling Enabled igb 0000:04:00.0: added PHC on eth1 igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection igb 0000:04:00.0: eth1: (PCIe:2.5GT/s:Width x4) igb 0000:04:00.0 eth1: MAC: 00:1b:21:36:5c:82 igb 0000:04:00.0: eth1: PBA No: E43709-003 igb 0000:04:00.0: LRO is disabled igb 0000:04:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s) igb: 0000:04:00.1: igb_validate_option: RSS - RSS multiqueue receive count set to 2 igb: 0000:04:00.1: igb_validate_option: QueuePairs - Tx/Rx queue pairs for interrupt handling Enabled igb 0000:04:00.1: added PHC on eth1 igb 0000:04:00.1: Intel(R) Gigabit Ethernet Network Connection igb 0000:04:00.1: eth1: (PCIe:2.5GT/s:Width x4) igb 0000:04:00.1 eth1: MAC: 00:1b:21:36:5c:83 igb 0000:04:00.1: eth1: PBA No: E43709-003 igb 0000:04:00.1: LRO is disabled igb 0000:04:00.1: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s) Intel(R) 10 Gigabit PCI Express Network Driver - version 4.1.2 Copyright (c) 1999-2015 Intel Corporation. ixgbe: Receive-Side Scaling (RSS) set to 2 ixgbe: 0000:03:00.0: ixgbe_check_options: FCoE Offload feature enabled ixgbe: allow_unsupported_sfp Enabled ixgbe 0000:03:00.0 (unregistered net_device): WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation ixgbe 0000:03:00.0: PCI Express bandwidth of 32GT/s available ixgbe 0000:03:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%) ixgbe 0000:03:00.0 eth1: MAC: 2, PHY: 17, SFP+: 5, PBA No: E66560-003 ixgbe 0000:03:00.0: 00:1b:21:90:fe:f8 ixgbe 0000:03:00.0 eth1: Enabled Features: RxQ: 2 TxQ: 2 FdirHash ixgbe 0000:03:00.0 eth1: Intel(R) 10 Gigabit Network Connection ixgbe: Receive-Side Scaling (RSS) set to 2 ixgbe: 0000:03:00.1: ixgbe_check_options: FCoE Offload feature enabled ixgbe: allow_unsupported_sfp Enabled ixgbe 0000:03:00.1: PCI Express bandwidth of 32GT/s available ixgbe 0000:03:00.1: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%) ixgbe 0000:03:00.1 eth4: MAC: 2, PHY: 1, PBA No: E66560-003 ixgbe 0000:03:00.1: 00:1b:21:90:fe:f9 ixgbe 0000:03:00.1 eth4: Enabled Features: RxQ: 2 TxQ: 2 FdirHash ixgbe 0000:03:00.1 eth4: Intel(R) 10 Gigabit Network Connection При работе наблюдаем странность, а именно повышенную нагрузку read_hpet: # perf top 84,79% [kernel] [k] cpu_idle_loop 7,16% [kernel] [k] read_hpet 0,59% [kernel] [k] module_get_kallsym 0,39% [kernel] [k] _raw_spin_lock 0,34% [kernel] [k] kallsyms_expand_symbol.clone.0 0,33% [kernel] [k] u32_classify 0,20% [kernel] [k] format_decode 0,17% [kernel] [k] add_interrupt_randomness 0,15% perf [.] symbols__insert 0,13% [kernel] [k] strnlen 0,11% [kernel] [k] vsnprintf В настоящий момент clocksource выбран HPET: /sys/devices/system/clocksource/clocksource0/current_clocksource hpet После изучения форума сложилось впечатление, что должно помочь изменение clocksource с hpet на tsc, но tsc нет в списке доступных источников: /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm TSC по какой-то причине отключается на этапе загрузки: tsc: Fast TSC calibration using PIT tsc: Detected 3300.005 MHz processor Calibrating delay loop (skipped), value calculated using timer frequency.. 6600.01 BogoMIPS (lpj=3300005) smpboot: CPU0: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz (fam: 06, model: 3f, stepping: 02) TSC deadline timer enabled Performance Events: no PEBS fmt2+, generic architected perfmon, Intel PMU driver. ... version: 3 ... bit width: 48 ... generic registers: 8 ... value mask: 0000ffffffffffff ... max period: 000000007fffffff ... fixed-purpose events: 3 ... event mask: 00000007000000ff smpboot: Booting Node 0, Processors #1 TSC synchronization [CPU#0 -> CPU#1]: Measured 193093878915547 cycles TSC warp between CPUs, turning off TSC clock. tsc: Marking TSC unstable due to check_tsc_sync_source failed С чем может быть связано отключение TSC? Это программная или аппаратная проблема? Можно ли как-то принудительно включить TSC на этапе загрузки? Ни на одном из доступных компьютеров подобной проблемы не наблюдается, поиск в Google ни к чему не привёл. Какие ещё варианты можно попробовать? Может ли помочь обновление BIOS, обновление ядра?

Проблема решена. Алгоритм такой: 1. Проверяем сборочную среду: если ядро PAE, то нужно ставить kernel-PAE-devel, иначе после сборки будет ругань Unknown symbol in module, or unknown parameter. 2. Обновляем iptables пакетами из OpenFusion: # rpm -Uvh iptables-1.4.3.2-2.of.el5.i386.rpm iptables-ipv6-1.4.3.2-2.of.el5.i386.rpm iptables-devel-1.4.3.2-2.of.el5.i386.rpm 3. Качаем xtables-addons-1.15-1.of.src.rpm из http://www.openfusion.com.au/labs/srpms/ и устанавливаем. # rpm -ivh xtables-addons-1.15-1.of.src.rpm 4. Распаковываем исходные тексты программы с наложением патчей (фаза %prep): # cd /usr/src/redhat/SPECS # rpmbuild -bp xtables-addons.spec При этом в каталоге /usr/src/redhat/BUILD/xtables-addons-1.15 находятся 2 каталога: оригинальный (extensions.dist) и патченный (extensions). 5. Комментируем объявление функции функции csum_unfold в файле compat_xtnu.h патченного каталога extensions: #if LINUX_VERSION_CODE <= KERNEL_VERSION(2, 6, 19) /* static inline __wsum csum_unfold(__sum16 n) { return (__force __wsum)n; } */ #endif 6. Готовим новый diff-файл файл: # cd /usr/src/redhat/BUILD/xtables-addons-1.15 # diff -Npru extensions.dist extensions > /usr/src/redhat/SOURCES/new.patch 7. Правим spec-файл xtables-addons.spec, изменив в нём номер релиза, версию ядра и имя патча: #%define kern_version 2.6.18-128.1.6.el5 %define kern_version 2.6.18-194.el5PAE #Release: 1%{org_tag}%{dist} Release: 1new #Patch0: %{name}-1.15-el5-tweakage.patch Patch0: new.patch 8. Можно производить сборку: # rpmbuild -bb --target=i686 xtables-addons.spec Модули, собранные для одного из ядер серии PAE подходят для ЛЮБЫХ ядер PAE из CentOS 5.

По наводке местных знатоков и совету товарища из вот этой темы всё-таки получилось поправить исходники и собрать нужные модули: # make make all-recursive make[1]: Entering directory `/root/test/xtables-addons-1.15' Making all in extensions make[2]: Entering directory `/root/test/xtables-addons-1.15/extensions' GEN modules make[3]: Entering directory `/usr/src/kernels/2.6.18-194.el5-i686' CC [M] /root/test/xtables-addons-1.15/extensions/compat_xtables.o CC [M] /root/test/xtables-addons-1.15/extensions/xt_TEE.o Building modules, stage 2. MODPOST CC /root/test/xtables-addons-1.15/extensions/compat_xtables.mod.o LD [M] /root/test/xtables-addons-1.15/extensions/compat_xtables.ko CC /root/test/xtables-addons-1.15/extensions/xt_TEE.mod.o LD [M] /root/test/xtables-addons-1.15/extensions/xt_TEE.ko make[3]: Leaving directory `/usr/src/kernels/2.6.18-194.el5-i686' CC libxt_TEE.oo CCLD libxt_TEE.so make[2]: Leaving directory `/root/test/xtables-addons-1.15/extensions' make[2]: Entering directory `/root/test/xtables-addons-1.15' sed -e '/@MATCHES@/ r extensions/matches.man' -e '/@TARGET@/ r extensions/targets.man' xtables-addons.8.in >xtables-addons.8; make[2]: Leaving directory `/root/test/xtables-addons-1.15' make[1]: Leaving directory `/root/test/xtables-addons-1.15' Но при попытке их загрузить получаю: # modprobe xt_TEE FATAL: Error inserting xt_TEE (/lib/modules/2.6.18-194.el5PAE/extra/xt_TEE.ko): Unknown symbol in module, or unknown parameter (see dmesg) Отыскал репозиторий OpenFusion, где имеются собранные модули для CentOS 5 (пакеты kernel-module-xtables-addons-2.6.18-128.1.6.el5-1.15-1.of.el5.i386.rpm, iptables-1.4.3.2-2.of.el5.i386.rpm, iptables-devel-1.4.3.2-2.of.el5.i386.rpm, iptables-ipv6-1.4.3.2-2.of.el5.i386.rpm), то есть сборка в принципе возможна. Но там они для другой версии ядра и при загрузке на моём ядре получаю точно такую же ошибку Unknown symbol in module, or unknown parameter. SRC.RPM файлов к пакету kernel-module-xtables-addons-2.6.18-128.1.6.el5-1.15-1.of.el5.i386.rpm, чтобы пересобрать его, отыскать не удалось. Буду рад любым советам.

Пытаюсь сделать зеркалирование трафика с помощью xtables-addons. На СеntOS 6 данная процедура прошла без проблем. А вот на CentOS 5.5 возникли проблемы. Что имеем: # cat /etc/issue CentOS release 5.5 (Final) Kernel \r on an \m # uname -a Linux localhost.localdomain 2.6.18-194.el5PAE #1 SMP Fri Apr 2 15:37:44 EDT 2010 i686 i686 i386 GNU/Linux Подготовка к сборке. Все необходимое для сборки установил, дополнительно доставил пакет perl-Text-CSV_XS-0.80-1.el5.rf.i386.rpm из rpm-forge. Почему-то в CentOS 5.5 отсутствует файл /usr/include/linux/netfilter/xtables.h, поэтому сделал симлинк на /usr/include/linux/netfilter/x_tables.h Дополнительно сделал симлинк 2.6.18-194.el5-PAE-i686 на /usr/src/kernels/2.6.18-194.el5-i686. Версии xtables-addons-1.47.1 и xtables-addons-1.20 при configure сразу ругаются на ... checking for linux/netfilter/x_tables.h... yes WARNING: This distribution's shipped kernel is not supported. make: *** /lib/modules/2.6.18-194.el5PAE/build: No such file or directory. Stop. Found kernel version ...0 in /lib/modules/2.6.18-194.el5PAE/build ./configure: line 11710: test: : integer expression expected ./configure: line 11712: test: : integer expression expected Поэтому пробую более древние версии, а именно xtables-addons-1.10 и xtables-addons-1.5.7, которые вроде бы должны работать с ядром 2.6.18. Файл mconfig обрезал до минимально возможного состояния: # -*- Makefile -*- # build_CHAOS= build_DELUDE= build_DHCPADDR= build_ECHO= build_IPMARK= build_LOGMARK= build_SYSRQ= build_TARPIT= build_TEE=m build_condition= build_fuzzy= build_geoip= build_ipp2p= build_ipset= build_portscan= build_quota2= configure отрабатывает без видимых проблем: #./configure --with-xtables=/usr/include/linux/netfilter ... checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate appending configuration tag "F77" to libtool checking xtables.h presence... /usr/include/linux/netfilter/xtables.h configure: creating ./config.status config.status: creating Makefile config.status: creating extensions/GNUmakefile config.status: creating extensions/ipset/GNUmakefile config.status: WARNING: extensions/ipset/GNUmakefile.in seems to ignore the --datarootdir setting config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands А вот при сборке получаем ошибку: # make make all-recursive make[1]: Entering directory `/root/test/xtables-addons-1.5.7' Making all in extensions make[2]: Entering directory `/root/test/xtables-addons-1.5.7/extensions' make -C /lib/modules/2.6.18-194.el5PAE/build M=/root/test/xtables-addons-1.5.7/extensions XA_TOPSRCDIR=/root/test/xtables-addons-1.5.7 modules; make[3]: Entering directory `/usr/src/kernels/2.6.18-194.el5-i686' CC [M] /root/test/xtables-addons-1.5.7/extensions/compat_xtables.o In file included from /root/test/xtables-addons-1.5.7/extensions/compat_xtables.c:20: /root/test/xtables-addons-1.5.7/extensions/compat_skbuff.h:26: ошибка: redefinition of ‘skb_reset_network_header’ include/linux/skbuff.h:1122: ошибка: previous definition of ‘skb_reset_network_header’ was here /root/test/xtables-addons-1.5.7/extensions/compat_skbuff.h:30: ошибка: redefinition of ‘tcp_hdr’ include/linux/tcp.h:169: ошибка: previous definition of ‘tcp_hdr’ was here /root/test/xtables-addons-1.5.7/extensions/compat_skbuff.h:34: ошибка: redefinition of ‘udp_hdr’ include/linux/udp.h:33: ошибка: previous definition of ‘udp_hdr’ was here In file included from /root/test/xtables-addons-1.5.7/extensions/compat_xtables.c:21: /root/test/xtables-addons-1.5.7/extensions/compat_xtnu.h:9: ошибка: redefinition of typedef ‘bool’ include/linux/types.h:36: ошибка: previous declaration of ‘bool’ was here /root/test/xtables-addons-1.5.7/extensions/compat_xtnu.h:10: ошибка: redeclaration of enumerator ‘false’ include/linux/stddef.h:16: ошибка: previous definition of ‘false’ was here /root/test/xtables-addons-1.5.7/extensions/compat_xtnu.h:10: ошибка: redeclaration of enumerator ‘true’ include/linux/stddef.h:18: ошибка: previous definition of ‘true’ was here /root/test/xtables-addons-1.5.7/extensions/compat_xtables.c: In function ‘xtnu_ip_route_me_harder’: /root/test/xtables-addons-1.5.7/extensions/compat_xtables.c:302: ошибка: слишком много аргументов в вызове функции ‘ip_route_me_harder’ /root/test/xtables-addons-1.5.7/extensions/compat_xtables.c: На верхнем уровне: /root/test/xtables-addons-1.5.7/extensions/compat_xtables.c:387: ошибка: expected ‘)’ before ‘*’ token /root/test/xtables-addons-1.5.7/extensions/compat_xtables.c:394: ошибка: expected ‘)’ before ‘*’ token /root/test/xtables-addons-1.5.7/extensions/compat_xtables.c:398: ошибка: ‘xtnu_csum_replace2’ undeclared here (not in a function) /root/test/xtables-addons-1.5.7/extensions/compat_xtables.c:398: предупреждение: в декларации ‘xtnu_csum_replace2’ по умолчанию установлен тип ‘int’ make[4]: *** [/root/test/xtables-addons-1.5.7/extensions/compat_xtables.o] Ошибка 1 make[3]: *** [_module_/root/test/xtables-addons-1.5.7/extensions] Ошибка 2 make[3]: Leaving directory `/usr/src/kernels/2.6.18-194.el5-i686' make[2]: *** [modules] Ошибка 2 make[2]: Leaving directory `/root/test/xtables-addons-1.5.7/extensions' make[1]: *** [all-recursive] Ошибка 1 make[1]: Leaving directory `/root/test/xtables-addons-1.5.7' make: *** [all] Ошибка 2 Гуглением нашёл только одну тему с данной проблемой, в которой рекомендовали бросить проблемное ядро от RedHat и перебраться на "ванильное" ядро, но данный "совет" в моём случае не подходит. С чем может быть связана данная ошибка? Кто-нибудь может поделиться опытом сборки модуля TEE для xtables-addons на CentOS 5?

Имеется сервер с БД, содержащей персональные данные абонентов. Сам сервер стоит в отдельном помещении под замком с решётками на окнах. Нужно ли дополнительно устанавливать на него средства защиты от несанкционированного доступа?

Наша компания является небольшим провайдером с базой около 2000 абонентов. Ожидаем визит Роскомнадзора с проверкой по персональным данным. В качестве биллинга используем UTM5, к базе имеют доступ 2 кассира, главбух и директор. Класс ИСДПн - К3. Просим совета у знающих людей. Посоветуйте, какое железо и ПО нужно поставить на компьютерах людей, работающих с персональными данными? Сами склоняемся к Secret Net, но запутались в её версиях: есть ли возможность обойтись без сервера, нужны ли какие-то аппаратные платы или можно обойтись USB-ключами? Порекомендуйте сертифицированный железный файрвол для установки между сервером с базой UTM и клиентской ЛВС? В бюджете ограничены, поэтому интересуют варианты с небольшой стоимостью.

Действительно, в /usr/src/linux я создавал символическую ссылку include на /usr/include/linux. Удалил ее, установил пакет kernel-devel и создал символическую ссылку /usr/src/linux на /usr/src/kernels/2.6.32-71.el6.i686 После данной процедуры сборка прошла успешно. Спасибо, xeb!

Добавил, вот результат: Linking C shared library libsigchld.so cd /root/install/accel-ppp-1.3.5/build/accel-pppd/extra && /usr/bin/cmake -E cmake_link_script CMakeFiles/sigchld.dir/link.txt --verbose=1 /usr/bin/gcc -fPIC -Wall -fvisibility=hidden -fno-strict-aliasing -D_GNU_SOURCE -DPTHREAD_SPINLOCK -fPIC -shared -Wl,-soname,libsigchld.so -o libsigchld.so CMakeFiles/sigchld.dir/sigchld.c.o make[2]: Leaving directory `/root/install/accel-ppp-1.3.5/build' /usr/bin/cmake -E cmake_progress_report /root/install/accel-ppp-1.3.5/build/CMakeFiles 51 [ 98%] Built target sigchld make -f driver/CMakeFiles/pptp_drv.dir/build.make driver/CMakeFiles/pptp_drv.dir/depend make[2]: Entering directory `/root/install/accel-ppp-1.3.5/build' cd /root/install/accel-ppp-1.3.5/build && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /root/install/accel-ppp-1.3.5 /root/install/accel-ppp-1.3.5/driver /root/install/accel-ppp-1.3.5/build /root/install/accel-ppp-1.3.5/build/driver /root/install/accel-ppp-1.3.5/build/driver/CMakeFiles/pptp_drv.dir/DependInfo.cmake --color= Scanning dependencies of target pptp_drv make[2]: Leaving directory `/root/install/accel-ppp-1.3.5/build' make -f driver/CMakeFiles/pptp_drv.dir/build.make driver/CMakeFiles/pptp_drv.dir/build make[2]: Entering directory `/root/install/accel-ppp-1.3.5/build' /usr/bin/cmake -E cmake_progress_report /root/install/accel-ppp-1.3.5/build/CMakeFiles [ 98%] Generating driver/pptp.ko cd /root/install/accel-ppp-1.3.5/build/driver && rm -rf /root/install/accel-ppp-1.3.5/build/driver/driver cd /root/install/accel-ppp-1.3.5/build/driver && mkdir /root/install/accel-ppp-1.3.5/build/driver/driver cd /root/install/accel-ppp-1.3.5/build/driver && ln -sf /root/install/accel-ppp-1.3.5/driver/* /root/install/accel-ppp-1.3.5/build/driver/driver cd /root/install/accel-ppp-1.3.5/build/driver && make -C /usr/src/linux M=/root/install/accel-ppp-1.3.5/build/driver/driver modules make[3]: Entering directory `/usr/src/linux' make[3]: *** No rule to make target `modules'. Stop. make[3]: Leaving directory `/usr/src/linux' make[2]: *** [driver/driver/pptp.ko] Error 2 make[2]: Leaving directory `/root/install/accel-ppp-1.3.5/build' make[1]: *** [driver/CMakeFiles/pptp_drv.dir/all] Error 2 make[1]: Leaving directory `/root/install/accel-ppp-1.3.5/build' make: *** [all] Error 2

Oracle Enterprise Linux 6 uname -a Linux oelinux.lutek.ru 2.6.32-71.el6.i686 #1 SMP Wed Dec 15 09:50:18 EST 2010 i686 i686 i386 GNU/Linux Скачал архив accel-ppp-1.3.5.tar.bz2, распаковал, создал подкаталог build. cd build cmake -DBUILD_DRIVER=TRUE -DRADIUS=FALSE .. make Получаю ошибку: Scanning dependencies of target sigchld [ 98%] Building C object accel-pppd/extra/CMakeFiles/sigchld.dir/sigchld.c.o Linking C shared library libsigchld.so [ 98%] Built target sigchld Scanning dependencies of target pptp_drv [ 98%] Generating driver/pptp.ko make[3]: *** No rule to make target `modules'. Stop. make[2]: *** [driver/driver/pptp.ko] Error 2 make[1]: *** [driver/CMakeFiles/pptp_drv.dir/all] Error 2 make: *** [all] Error 2 Аналогичная ситуация и с версиями 1.3.3 и 1.3.4. Подскажите, в чем может быть проблема?

Столкнулся со следующей проблемой: Имеется расшаренный сетевой ресурс, на котором расположены базы FoxPro. С этими базами должны по сети работать одновременно 2 клиентских программы. Ресурс с базами FoxPro подключается как сетевой диск. При создании общей папки на Windows 2000 все замечательно: оба клиента прекрасно работают с базами. При использовании Centos 4.2 (kernel 2.6) + samba-3.0.10 ситуация следующая: первый клиент запускается и блокирует файлы базы FoxPro, соответственно второй клиент не может получить к ним доступ, пока работает программа первого клиента. Как только первый клиент закрывает свою программу, второй клиент сразу же получает возможность работать с базой. Используемый smb.conf стандартный, идущий с samba, поправлено лишь: security = share [foxpro] path = /path/to/foxpro public = yes guest only = yes writeable = yes Что интересно, на Red Hat 6.2 (kernel 2.0) + samba-2.0.6 (с дефолтным конфигом) проблемы с блокировками нет. Пробовал собирать samba-2.0, samba-2.2 на Centos 4.2, проблема остается. Пытался отключать в конфиге smb.conf все, что связано с oplocks и блокировками: security = share kernel oplocks = no defer sharing violations = no [foxpro] path = /path/to/foxpro public = yes guest only = yes writeable = yes oplocks = no level2 oplocks = no blocking locks = no locking = no strict locking = no не помогает. Посоветуйте, в какую сторону копать, чтобы решить проблему?