битрикс жжет

Я херею. битрик, посаженный в свежий битрикс окружение (с php ветки 5.3), при запуске сканера безопасности сообщает:

Используется опасная версия php       Важно!
Текущая версия php, предположительно содержит ряд критичных уязвимостей
Необходимо обновить php до последней стабильной версии или как минимум до версии не ниже 5.4.0

При этом в битрикс окружении стоит 5.3.3, пруф с офсайта:

Автоматически устанавливаемое и настраиваемое ПО:

• mysql-server 5.*
• web-server (Apache 2.2.*)
• php 5.3.*
• nginx 1.4.*
• memcached
• stunnel
• catdoc
• xpdf
• munin
• nagios
• sphinx

Просто ппц. При этом на их форуме куча негатива на счет попыток накатить 5.4 - куча модулей дохнет. Это первое.
Второе - собсно секюрность.. Рекомендация сменить текущий пых, со всеми секурити патчами на данный момент, на 5.4.0, в котором были реальные дыры - это из разряда вредных советов.

И все это наводит на мысль - весь этот скан безопасности заключается в тупом сравнении веток ПО. Не заморачиваясь с оценкой собственно уязвимостей.

SMART в ESXi

Нашёл, наконец, как этой вашей вмваре - esxi - посмотреть состояние дисков:

~ # esxcli storage core device smart get -d t10.ATA_____ST2000DM0012D9YN164__________________________________Z1E0YH1D
Parameter                     Value  Threshold  Worst
----------------------------  -----  ---------  -----
Health Status                 OK     N/A        N/A 
Media Wearout Indicator       N/A    N/A        N/A 
Write Error Count             N/A    N/A        N/A 
Read Error Count              117    6          99  
Power-on Hours                90     0          90  
Power Cycle Count             100    20         100 
Reallocated Sector Count      100    36         100 
Raw Read Error Rate           117    6          99  
Drive Temperature             26     0          40  
Driver Rated Max Temperature  74     45         69  
Write Sectors TOT Count       200    0          200 
Read Sectors TOT Count        N/A    N/A        N/A 
Initial Bad Block Count       100    99         100 

Девайс берем из:

 ~ # esxcli storage core device list
t10.ATA_____ST2000DM0012D9YN164__________________________________Z1E0YH1D
   Display Name: Local ATA Disk (t10.ATA_____ST2000DM0012D9YN164__________________________________Z1E0YH1D)
   Has Settable Display Name: true
   Size: 1907729
   Device Type: Direct-Access
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/t10.ATA_____ST2000DM0012D9YN164__________________________________Z1E0YH1D
   Vendor: ATA   
   Model: ST2000DM001-9YN1
   Revision: CC4B
   SCSI Level: 5
   Is Pseudo: false
   Status: on
   Is RDM Capable: false
   Is Local: true
   Is Removable: false
   Is SSD: false
   Is Offline: false
   Is Perennially Reserved: false
   Queue Full Sample Size: 0
   Queue Full Threshold: 0
   Thin Provisioning Status: unknown
   Attached Filters:
   VAAI Status: unknown
   Other UIDs: vml.01000000002020202020202020202020205a31453059483144535432303030
   Is Local SAS Device: false
   Is Boot USB Device: false

t10.ATA_____ST2000DM0012D9YN164__________________________________Z1E0YL1P
   Display Name: Local ATA Disk (t10.ATA_____ST2000DM0012D9YN164__________________________________Z1E0YL1P)
   Has Settable Display Name: true
   Size: 1907729
   Device Type: Direct-Access
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/t10.ATA_____ST2000DM0012D9YN164__________________________________Z1E0YL1P
   Vendor: ATA   
   Model: ST2000DM001-9YN1
   Revision: CC4B
   SCSI Level: 5
   Is Pseudo: false
   Status: on
   Is RDM Capable: false
   Is Local: true
   Is Removable: false
   Is SSD: false
   Is Offline: false
   Is Perennially Reserved: false
   Queue Full Sample Size: 0
   Queue Full Threshold: 0
   Thin Provisioning Status: unknown
   Attached Filters:
   VAAI Status: unknown
   Other UIDs: vml.01000000002020202020202020202020205a314530594c3150535432303030
   Is Local SAS Device: false
   Is Boot USB Device: false

Ну хоть что-то.

Xen: Bridges and vlans

Недавно срочно понадобилось на ксеновую ноду запихать машинки из сети из влана, отличного от того, что был прокинут. Времени на то, чтобы разбираться с мостами и вланами не было, просто подцепил второй интерфейс железки, сделал мост и на него машины повесил.
Но это как-то неправильно.
Наконец, дошли руки разобраться с этим вопросом. Интуитивно всё вроде было просто, но не завелось, немного перепутал порядок настройки )

Задача по сути такая: создать несколько мостов для разных вланов. Пусть один нативный, второй с тегом.

1. Настраиваем интерфейс в нативном влане, указывая мост:

# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE="eth1"
BRIDGE="br1"
ONBOOT="yes"
TYPE="Ethernet"
HWADDR="00:9A:8F:11:22:33"

2. Настраиваем бридж для нативного влана:

# cat /etc/sysconfig/network-scripts/ifcfg-br1
DEVICE="br1"
BOOTPROTO="static"
HWADDR="00:9A:8F:11:22:33"
IPADDR="111.222.34.56"
NETMASK="255.255.254.0"
ONBOOT="yes"
TYPE="Bridge"

3. Настраиваем интерфейс с тегом:

# cat /etc/sysconfig/network-scripts/ifcfg-eth1.4
DEVICE="eth1.4"
VLAN="yes"
BRIDGE="br14"
ONBOOT="yes"
TYPE="Ethernet"
HWADDR="00:9A:8F:11:22:33"

4. Настраиваем бридж для этого тега:

# cat /etc/sysconfig/network-scripts/ifcfg-br14
DEVICE="br14"
BOOTPROTO="static"
HWADDR="00:9A:8F:11:22:33"
IPADDR="222.33.45.67"
NETMASK="255.255.254.0"
ONBOOT="yes"
TYPE="Bridge"

Рестарт сети и готово )
Да, возможно модуль для вланов понадобится запихать
modprobe 8021q

Теперь можно прокидывать в виртуалки оба влана, прицепляем новый мост:

xm network-attach test-ve mac=00:16:3e:87:b5:6c bridge=br14 script=vif-bridge

IBM DS3524 serial cable

Короче, клиент стору свою нагнул, чуть позже распишу историю восстановления. Главная тема в том, что нужен адов кабель (minidin 6 M - db9 F), который в поставку не входит. Я нашёл несколько схем, которые вроде бы рабочие, если где-то что-то поменять. Перепаял 6 кабелей - не завелись.В итоге дождались родного. Снял с него распайку:

mini
din 6     db9

1             2
2             3
3             5
4             8
5            
6             7