В последнее время участились случаи взлома сайтов на Joomla, использующих компонент Joomla Content Editor (com_jce).

Этот компонент имеет уязвимость вплоть до версии 2.0.10, которая позволяет злоумышленнику загружать на сайт произвольные файлы, в том числе, скрипты php.

Для заражения злоумышленники используют робота, который сканирует сайты на предмет наличия компонента jce и имеющейся в нём уязвимости. Наиболее часто встречающиеся симптомы такого заражения:

• файлы wp-conf.php в корневой директории сайта ./public_html и в корневой директории аккаунта
• файл со случайным названием вида w7792289n.php в ./public_html
• многочисленные файлы index.php, залитые в случайные директории сайта
• файлы с произвольным названием, в т.ч. с вполне осмысленным, залитые в случайные директории сайта.

Модификация файлов сайта в этом случае не производится, и зловредные файлы легко вычислить по дате изменения. Например, если взлом был осуществлён неделю назад, и если за эту неделю на сайте не менялись php-скрипты, то лечение сводится к следующей команде:

cd public_html
find . -type f -mtime -7 -name "*.php" -delete

Для предотвращения повторного взлома через эту уязвимость следует обновить компонент JCE. Скачать его можно здесь.

В качестве альтернативы можно использовать патч, закрывающий данную уязвимость. Для установки патча файл jce_patch.php из архива помещаем рядом с index.php в корне сайта, а в самом index.php ищем строку $mainframe->initialise(); и добавляем за ней строку include ‘jce_patch.php’;

В статье рассматривается способ установки Flashcache на CentOS 6.3 и проводятся несколько различных сравнительных тестов производительности.

В этот раз самой статьи здесь не будет, поскольку я изначально писал её для хабра, где сегодня опубликовал её в песочнице. Вознаграждение в виде инвайта не заставило себя долго ждать. =)

Поэтому, если вам интересно — статья здесь.

В Белтелекоме сеть организована таким образом, что для того, чтобы сервер мог находиться в нескольких подсетях одновременно, на нём следует настроить поддержку VLAN и тегированного трафика.

Далее рассмотрим подключение IP-адресов из других подсетей как напрямую к интерфейсу eth0, так и к интерфейсу, работающему в режиме bridge br0.

За поддержку VLAN отвечает модуль ядра 8021q. Проверим его наличие в системе:

# lsmod | grep 8021q

Если модуль присутствует, можно идти далее. Добавим поддержку VLAN, воспользовавшись утилитой vconfig.

# vconfig add eth0 VLID

Здесь и далее VLID — это тег вашей подсети — число, которое следует узнать у техподдержки Белтелекома.

Проверим, что VLAN появился в системе:

# cat /proc/net/vlan/eth0.VLID

Если всё ОК, идём далее. Создадим файл /etc/sysconfig/network-scripts/ifcfg-eth0.VLID со следующим содержиммым:

VLAN=yes
DEVICE=eth0.VLID
BOOTPROTO=static
ONBOOT=yes
TYPE=Ethernet
IPADDR=aa.bb.cc.dd
NETMASK=ee.ff.gg.hh

здесь aa.bb.cc.dd — IP-адрес из другой подсети, который необходимо добавить к серверу, ee.ff.gg.hh — маска для этой подсети.

Сохраняем файл, перезагружаем сетевой сервис:

# service network restart

Обратите внимание, что операции с сетевыми настройками надо делать крайне внимательно и аккуратно, если конечно у вас на сервере нет IP-KVM. Поскольку, если сеть не поднимется, поездка в ЦОД вам обеспечена.

После перезагрузки сервиса IP aa.bb.cc.dd должен начать отвечать на пинг.

Рассмотрим ситуацию с подключением сервера к VLAN в случае, если основной интерфейс сервера работает в режиме bridge (например, если сервер используется как хост для виртуальных машин Xen или KVM). Подразумеваем, что в вашей системе bridge-интерфейс называется br0.

Как и в первом случае, сначала необходимо добавить поддержку VLAN.

# vconfig add eth0 VLID

Создаём файл /etc/sysconfig/network-scripts/ifcfg-eth0.VLID со следующим содержимым:

VLAN=yes
DEVICE=eth0.VLID
HWADDR=aa:bb:cc:dd:ee:ff
ONBOOT=yes
BRIDGE=br0
BOOTPROTO=none
TYPE=Ethernet

где aa:bb:cc:dd:ee:ff — MAC-адрес вашего сетевого интерфейса.

После этого IP-адреса из другой подсети будут добавляться к виртуальным машинам так же, как и из подсети, закреплённой за вашим портом.

Панель управления виртуальным сервером SolusVM позволяет изменять в сторону увеличения дисковое пространство, отведённое под виртуальную машину. В том числе, это без проблем работает на технологии виртуализации KVM, на которой у нас построены виртуальные машины. Однако, ОС CentOS не может автоматически расширить файловую систему до нового размера отведённого дискового пространства. Переустанавливать систему крайне не хотелось, потому что это обернулось бы значительным простоем сервера. К счастью, нашёлся способ расширить диск и без переустановки системы.

Этот способ подразумевает, что диск вашего виртуального сервера отформатирован в LVM. Кстати, такой тип разделов инсталлятор CentOS предлагает по умолчанию при установке системы.

Сделав бэкап всех данных (обязательная операция!), я принялся за работу. В панели управления SolusVM увеличил объём выделенного дискового пространства с 60 до 140 ГиБ, затем перезагрузил VDS из панели, чтобы изменения вступили в силу. После этого видим, что устройство hda увеличилось до 150 ГБ:

# fdisk -l

Disk /dev/hda: 150.3 GB, 150323855360 bytes
255 heads, 63 sectors/track, 18275 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1          13      104391   83  Linux
/dev/hda2              14        7832    62806117+  8e  Linux LVM

Однако, свободного места больше не стало:

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                      58785924  45142212  10609396  81% /
/dev/hda1               101086     37741     58126  40% /boot
tmpfs                  1556236         0   1556236   0% /dev/shm
/usr/tmpDSK             495844     84942    385302  19% /tmp

Очевидно, у нас появилась свободная неразмеченная область. Создадим логический диск hda3 с таким же типом раздела Linux LVM, как и на диске hda2.

# fdisk /dev/hda

В оболочке fdisk вводим следующие команды:

n — создаём новый раздел;
p — обозначаем его как primary;
так как у нас было 2 логических раздела, то на вопрос Partition number (1-4) отвечаем 3;
t — укажем тип раздела;
опять тот же вопрос Partition number (1-4), конечно же отвечаем 3;
вводим 8e — это код типа раздела, соответствующий Linux LVM;
убедимся, что всё сделано верно, вводим p — показать таблицу разделов:

Disk /dev/hda: 150.3 GB, 150323855360 bytes
255 heads, 63 sectors/track, 18275 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1          13      104391   83  Linux
/dev/hda2              14        7832    62806117+  8e  Linux LVM
/dev/hda3            7833       18275    83883397+  8e  Linux LVM

видим, что добавился раздел hda3, вводим w — сохранение изменений.
Здесь мы получим предупреждение о том, что изменения в данный момент невозможны, но всё будет ОК после перезагрузки.
выходим из оболочки fdisk, нажав Ctrl+Z, и перезагружаем виртуальный сервер.

После перезагрузки идём дальше. Создаём физический том hda3:

# pvcreate /dev/hda3
  Physical volume "/dev/hda3" successfully created

Расширяем группу томов на освободившееся место. Используем наше имя группы томов VolGroup00, которое мы подсмотрели ранее, командой df:

# vgextend /dev/VolGroup00 /dev/hda3
  Volume group "VolGroup00" successfully extended

Расширяем логический том. Для его имени также используем данные команды df:

# lvextend -l+100%FREE /dev/VolGroup00/LogVol00
  Extending logical volume LogVol00 to 137.84 GB
  Logical volume LogVol00 successfully resized

Активируем:

# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "VolGroup00" using metadata type lvm2

# vgchange -ay
  2 logical volume(s) in volume group "VolGroup00" now active

И, наконец, расширяем файловую систему:

# resize2fs /dev/VolGroup00/LogVol00
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/VolGroup00/LogVol00 is mounted on /; on-line resizing required
Performing an on-line resize of /dev/VolGroup00/LogVol00 to 36134912 (4k) blocks.
The filesystem on /dev/VolGroup00/LogVol00 is now 36134912 blocks long.

Это займёт некоторое время, зависящее от размера добавленного места.
После завершения операции видим, что свободное место в файловой системе действительно появилось:

# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                     140012336  44868028  87918352  34% /
/dev/hda1               101086     37741     58126  40% /boot
tmpfs                  1556236         0   1556236   0% /dev/shm
/usr/tmpDSK             495844     84980    385264  19% /tmp

Готово! Я ещё раз перезагружал виртуальный сервер, с тем чтобы убедиться, что всё работает нормально, но видимо это можно было и не делать. Таким образом, с помощью такой методики можно увеличить размер диска без переустановки операционной системы, сведя время недоступности сервера к минимуму — ко времени, требующемуся для 2-3 перезагрузок VDS.

Устанавливаем:

# yum install lm_sensors

Для её работы потребуется установить модуль ядра, который может считывать информацию с температурных датчиков ядер. Его потребуется установить из репозитория elrepo.
Устанавливаем репозиторий:

# rpm --import http://elrepo.org/RPM-GPG-KEY-elrepo.org
# rpm -Uvh http://elrepo.org/elrepo-release-6-4.el6.elrepo.noarch.rpm

Устанавливаем модуль coretemp:

# yum --enablerepo=elrepo install kmod-coretemp
# modprobe coretemp

Запускаем утилиту обнаружения сенсоров, на все задаваемые вопросы жмём enter:

# sensors-detect

Запускаем утилиту sensors:

# sensors
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +27.0°C (high = +74.0°C, crit = +94.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1: +29.0°C (high = +74.0°C, crit = +94.0°C)

coretemp-isa-0002
Adapter: ISA adapter
Core 2: +31.0°C (high = +74.0°C, crit = +94.0°C)

coretemp-isa-0003
Adapter: ISA adapter
Core 3: +29.0°C (high = +74.0°C, crit = +94.0°C)

Утилита вывела температуру по каждому ядру процессора. Вывод можно упростить, используя команду grep Core:

# sensors | grep Core

Четырёхъядерный Xeon E3-1230 оказался весьма холодным без нагрузки. Теперь надо посмотреть, насколько он нагреется под нагрузочным тестом.
Я использовал утилиту stress, которая есть в репозитории DAG.

# rpm -ivh http://download.fedora.redhat.com/pub/epel/6/x86_64/stress-1.0.4-4.el6.x86_64.rpm

Запустим например с такими параметрами:

# stress --cpu 8 --vm 2 --vm-bytes 128M

Здесь создаётся 8 процессов, нагружающих процессор, и 2 процесса, непрерывно создающих и удаляющих блоки по 128МБ в оперативной памяти.
Откроем вторую консоль и проследим за динамикой роста температуры:

# watch 'sensors | grep Core'

Спустя час после запуска утилиты нагрузочного тестирования сенсоры показывают такой результат:

Every 2.0s: sensors | grep Core Mon Dec 4 04:27:01 2011

Core 0: +61.0°C (high = +74.0°C, crit = +94.0°C)
Core 1: +63.0°C (high = +74.0°C, crit = +94.0°C)
Core 2: +66.0°C (high = +74.0°C, crit = +94.0°C)
Core 3: +60.0°C (high = +74.0°C, crit = +94.0°C)

Что ж, выглядит весьма неплохо, и можно определённо сказать, что система охлаждения работает как надо.

Чуть позже я расскажу об измерении температуры на жёстких дисках.

15 сентября 2011 года Совет министров РБ принял постановление об отмене сезонных переводов часов. В связи с этим возникла необходимость перенастройки временных зон на компьютерах, смартфонах, серверах, чтобы предотвратить автоматический переход на зимнее время ночью с 30 по 31 октября.
В этой статье мы расскажем, как исправить временную зону в CentOS.

Российским пользователям RHEL/CentOS повезло: репозитории уже обновились, и для корректного исправления временной зоны достаточно выполнить одну команду:

yum update tzdata

Белорусским же пользователям повезло меньше, и поэтому для обновления зон необходимо произвести несколько дополнительных действий.

Сначала нужно убедиться, что зона требует обновления.

zdump -v Europe/Minsk | grep 2011
Europe/Minsk  Sat Mar 26 23:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 EET isdst=0 gmtoff=7200
Europe/Minsk  Sun Mar 27 00:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 EEST isdst=1 gmtoff=10800
Europe/Minsk  Sat Oct 29 23:59:59 2011 UTC = Sun Oct 30 02:59:59 2011 EEST isdst=1 gmtoff=10800
Europe/Minsk  Sun Oct 30 00:00:00 2011 UTC = Sun Oct 30 02:00:00 2011 EET isdst=0 gmtoff=7200

Если команда вывела 4 строки, то зону необходимо обновить.

Проверим, какая зона установлена в системе.

cat /etc/sysconfig/clock

Если команда вывела

ZONE="Europe/Minsk"

значит зона установлена верно, если нет — необходимо отредактировать этот файл.
Далее нужно скачать обновлённый файл временных зон и скомпилировать его.
Скачать его можно здесь.

wget http://www.iana.org/time-zones/repository/releases/tzdata2011m.tar.gz

Распакуем архив во временную папку.

tar xzf tzdata2011m.tar.gz

Наша зона находится в файле europe, можете открыть его для просмотра, найти Minsk и почитать ради интереса, что там написано.

Скомпилируем файл europe с помощью утилиты zic.

zic europe

Утилита без параметра -d компилирует и размещает файлы зон сразу в директорию /usr/share/zoneinfo, поэтому проверим, обновилось или нет.

zdump -v Europe/Minsk | grep 2011
Europe/Minsk  Sat Mar 26 23:59:59 2011 UTC = Sun Mar 27 01:59:59 2011 FET isdst=0 gmtoff=7200
Europe/Minsk  Sun Mar 27 00:00:00 2011 UTC = Sun Mar 27 03:00:00 2011 FET isdst=0 gmtoff=10800

Если видим 2 строки — то всё сделано верно, и теперь наша система узнала о необычной временной зоне FET.
Остался последний штрих — обновить локальное время системы.
Создадим ссылку на файл зоны.

ln -sf /usr/share/zoneinfo/Europe/Minsk /etc/localtime

Сверим часы: проверьте текущее время компьютера командой date.