AccessD Lab

kafka: decrease topic replication factor

noreply@blogger.com (AccessD) — Fri, 12 May 2017 23:10:00 +0300

Внезапно пришлось редусить кластер кафки с 5 до 3 нод. Все топики были с репликейшн фактор 3, что на 3х нодах расточительно. Просто так нельзя взять и уменьшить его, но есть прикольный, хоть и чуть геморный способ через ручное назначение партиций.
Итак, порядок примерно такой:
1. делаем json со списком топиков.
2. генерим для json с распределением партиций по нодам (можно например указать только оставшие 3 брокера, если мы еще не убили 2 оставшихся и не перенесли партиции)
3. удаляем из него по одной ноде для каждой партиции
4. скармливаем json кафке
5. проверяем, что в дескрайбе фактор стал 2.

Пример на тестовом топике, заодно выводим из работы из 3 брокеров одного:

root@kafka1:~# /opt/kafka/bin/kafka-topics.sh --zookeeper zoo1:2181/kafka --create --topic repl-test --replication-factor 3 --partitions 8
Created topic "repl-test".
root@kafka1:~# /opt/kafka/bin/kafka-topics.sh --zookeeper zoo1:2181/kafka --describe --topic repl-test
Topic:repl-test PartitionCount:8 ReplicationFactor:3 Configs:
Topic: repl-test Partition: 0 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
Topic: repl-test Partition: 1 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Topic: repl-test Partition: 2 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1
Topic: repl-test Partition: 3 Leader: 3 Replicas: 3,2,1 Isr: 3,2,1
Topic: repl-test Partition: 4 Leader: 1 Replicas: 1,3,2 Isr: 1,3,2
Topic: repl-test Partition: 5 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
Topic: repl-test Partition: 6 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
Topic: repl-test Partition: 7 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
root@kafka1:~# vi topic.json
root@kafka1:~# cat topic.json
{"topics":
[{"topic": "repl-test"}],
"version":1
}
root@kafka1:~# /opt/kafka/bin/kafka-reassign-partitions.sh --zookeeper zoo1:2181/kafka --topics-to-move-json-file topic.json --broker-list "1,2,3" --generate
Current partition replica assignment

{"version":1,"partitions":[{"topic":"repl-test","partition":2,"replicas":[2,3,1]},{"topic":"repl-test","partition":7,"replicas":[1,2,3]},{"topic":"repl-test","partition":5,"replicas":[2,1,3]},{"topic":"repl-test","partition":3,"replicas":[3,2,1]},{"topic":"repl-test","partition":0,"replicas":[3,1,2]},{"topic":"repl-test","partition":4,"replicas":[1,3,2]},{"topic":"repl-test","partition":1,"replicas":[1,2,3]},{"topic":"repl-test","partition":6,"replicas":[3,1,2]}]}
Proposed partition reassignment configuration

{"version":1,"partitions":[{"topic":"repl-test","partition":2,"replicas":[2,3,1]},{"topic":"repl-test","partition":7,"replicas":[1,2,3]},{"topic":"repl-test","partition":5,"replicas":[2,1,3]},{"topic":"repl-test","partition":3,"replicas":[3,2,1]},{"topic":"repl-test","partition":0,"replicas":[3,1,2]},{"topic":"repl-test","partition":4,"replicas":[1,3,2]},{"topic":"repl-test","partition":1,"replicas":[1,2,3]},{"topic":"repl-test","partition":6,"replicas":[3,1,2]}]}
root@kafka1:~# vi tmppart.json
root@kafka1:~# cat tmppart.json
{"version":1,"partitions":[{"topic":"repl-test","partition":2,"replicas":[2,3,1]},{"topic":"repl-test","partition":7,"replicas":[1,2,3]},{"topic":"repl-test","partition":5,"replicas":[2,1,3]},{"topic":"repl-test","partition":3,"replicas":[3,2,1]},{"topic":"repl-test","partition":0,"replicas":[3,1,2]},{"topic":"repl-test","partition":4,"replicas":[1,3,2]},{"topic":"repl-test","partition":1,"replicas":[1,2,3]},{"topic":"repl-test","partition":6,"replicas":[3,1,2]}]}
root@kafka1:~# cat tmppart.json| python -m json.tool > part_cur.json root@kafka1:~# cat part_cur.json
{
"partitions": [
{
"partition": 2,
"replicas": [
2,
3,
1
],
"topic": "repl-test"
},
{
"partition": 7,
"replicas": [
1,
2,
3
],
"topic": "repl-test"
},
{
"partition": 5,
"replicas": [
2,
1,
3
],
"topic": "repl-test"
},
{
"partition": 3,
"replicas": [
3,
2,
1
],
"topic": "repl-test"
},
{
"partition": 0,
"replicas": [
3,
1,
2
],
"topic": "repl-test"
},
{
"partition": 4,
"replicas": [
1,
3,
2
],
"topic": "repl-test"
},
{
"partition": 1,
"replicas": [
1,
2,
3
],
"topic": "repl-test"
},
{
"partition": 6,
"replicas": [
3,
1,
2
],
"topic": "repl-test"
}
],
"version": 1
}
root@kafka1:~# cp part_cur.json part_new.json
root@kafka1:~# vi part_new.json
root@kafka1:~# cat part_new.json
{
"partitions": [
{
"partition": 2,
"replicas": [
2,
1
],
"topic": "repl-test"
},
{
"partition": 7,
"replicas": [
1,
2
],
"topic": "repl-test"
},
{
"partition": 5,
"replicas": [
2,
1
],
"topic": "repl-test"
},
{
"partition": 3,
"replicas": [
2,
1
],
"topic": "repl-test"
},
{
"partition": 0,
"replicas": [
1,
2
],
"topic": "repl-test"
},
{
"partition": 4,
"replicas": [
1,
2
],
"topic": "repl-test"
},
{
"partition": 1,
"replicas": [
1,
2
],
"topic": "repl-test"
},
{
"partition": 6,
"replicas": [
1,
2
],
"topic": "repl-test"
}
],
"version": 1
}
root@kafka1:~# /opt/kafka/bin/kafka-reassign-partitions.sh --zookeeper zoo1:2181/kafka --reassignment-json-file part_new.json --verify
Status of partition reassignment:
ERROR: Assigned replicas (3,1,2) don't match the list of replicas for reassignment (1,2) for partition [repl-test,0]
ERROR: Assigned replicas (1,3,2) don't match the list of replicas for reassignment (1,2) for partition [repl-test,4]
ERROR: Assigned replicas (2,3,1) don't match the list of replicas for reassignment (2,1) for partition [repl-test,2]
ERROR: Assigned replicas (1,2,3) don't match the list of replicas for reassignment (1,2) for partition [repl-test,7]
ERROR: Assigned replicas (3,1,2) don't match the list of replicas for reassignment (1,2) for partition [repl-test,6]
ERROR: Assigned replicas (2,1,3) don't match the list of replicas for reassignment (2,1) for partition [repl-test,5]
ERROR: Assigned replicas (3,2,1) don't match the list of replicas for reassignment (2,1) for partition [repl-test,3]
ERROR: Assigned replicas (1,2,3) don't match the list of replicas for reassignment (1,2) for partition [repl-test,1]
Reassignment of partition [repl-test,0] failed
Reassignment of partition [repl-test,4] failed
Reassignment of partition [repl-test,2] failed
Reassignment of partition [repl-test,7] failed
Reassignment of partition [repl-test,6] failed
Reassignment of partition [repl-test,5] failed
Reassignment of partition [repl-test,3] failed
Reassignment of partition [repl-test,1] failed
root@kafka1:~# ((
> ^C
root@kafka1:~# /opt/kafka/bin/kafka-topics.sh --zookeeper zoo1:2181/kafka --describe --topic repl-test
Topic:repl-test PartitionCount:8 ReplicationFactor:3 Configs:
Topic: repl-test Partition: 0 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
Topic: repl-test Partition: 1 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Topic: repl-test Partition: 2 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1
Topic: repl-test Partition: 3 Leader: 3 Replicas: 3,2,1 Isr: 3,2,1
Topic: repl-test Partition: 4 Leader: 1 Replicas: 1,3,2 Isr: 1,3,2
Topic: repl-test Partition: 5 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
Topic: repl-test Partition: 6 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
Topic: repl-test Partition: 7 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
root@kafka1:~# /opt/kafka/bin/kafka-reassign-partitions.sh --zookeeper zoo1:2181/kafka --reassignment-json-file part_new.json --execute
Current partition replica assignment

{"version":1,"partitions":[{"topic":"repl-test","partition":2,"replicas":[2,3,1]},{"topic":"repl-test","partition":7,"replicas":[1,2,3]},{"topic":"repl-test","partition":5,"replicas":[2,1,3]},{"topic":"repl-test","partition":3,"replicas":[3,2,1]},{"topic":"repl-test","partition":0,"replicas":[3,1,2]},{"topic":"repl-test","partition":4,"replicas":[1,3,2]},{"topic":"repl-test","partition":1,"replicas":[1,2,3]},{"topic":"repl-test","partition":6,"replicas":[3,1,2]}]}

Save this to use as the --reassignment-json-file option during rollback
Successfully started reassignment of partitions {"version":1,"partitions":[{"topic":"repl-test","partition":0,"replicas":[1,2]},{"topic":"repl-test","partition":4,"replicas":[1,2]},{"topic":"repl-test","partition":2,"replicas":[2,1]},{"topic":"repl-test","partition":7,"replicas":[1,2]},{"topic":"repl-test","partition":6,"replicas":[1,2]},{"topic":"repl-test","partition":5,"replicas":[2,1]},{"topic":"repl-test","partition":3,"replicas":[2,1]},{"topic":"repl-test","partition":1,"replicas":[1,2]}]}
root@kafka1:~# /opt/kafka/bin/kafka-topics.sh --zookeeper zoo1:2181/kafka --describe --topic repl-test
Topic:repl-test PartitionCount:8 ReplicationFactor:2 Configs:
Topic: repl-test Partition: 0 Leader: 1 Replicas: 1,2 Isr: 1,2
Topic: repl-test Partition: 1 Leader: 1 Replicas: 1,2 Isr: 1,2
Topic: repl-test Partition: 2 Leader: 2 Replicas: 2,1 Isr: 2,1
Topic: repl-test Partition: 3 Leader: 2 Replicas: 2,1 Isr: 2,1
Topic: repl-test Partition: 4 Leader: 1 Replicas: 1,2 Isr: 1,2
Topic: repl-test Partition: 5 Leader: 2 Replicas: 2,1 Isr: 2,1
Topic: repl-test Partition: 6 Leader: 1 Replicas: 1,2 Isr: 1,2
Topic: repl-test Partition: 7 Leader: 1 Replicas: 1,2 Isr: 1,2

и опять часики

noreply@blogger.com (AccessD) — Thu, 20 Nov 2014 12:51:00 +0300

На ноде ставим часы в UTC:

# cat /etc/sysconfig/clock
UTC=yes
ZONE="Europe/Moscow"

Смотрим, что системное время правильное с правильное зоной и впихиваем его в hw часы:

# hwclock --systohc --utc

Проверяем, что в конфиге машины:

<clock offset='utc' adjustment='reset'/>

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

В VPS не работает conntrack

noreply@blogger.com (AccessD) — Fri, 5 Sep 2014 12:53:00 +0400

Чел добавляет правила с -m state и они не добавляются.

vzctl stop 99111
vzctl set 99111 --save --iptables ipt_conntrack --iptables ipt_state --iptables iptable_filter --iptables ip_tables
vzctl start 99111

та-дам ))

Не грузится RAID контроллер после загрузки FC контроллера

noreply@blogger.com (AccessD) — Fri, 5 Sep 2014 12:13:00 +0400

Мать X8DTU-LN4F+, стоят контроллеры FC emulex и RAID adaptec 6405.
Проблема - после загрузки FC контроллера RAID даже не пытается подняться, как следствие - сервер не видит диски и не грузится.
Однако если при загрузке жмакнуть "выбор загрузочного устройства" - все прогружается и адаптек собственно является единственным вариантом.

В эмулексе загрузка с сана отключена.
Попробовал поменять местами железки местами - 0.

Перерыл все, что связанно с загрузкой в биосе, ничего нет.
В итоге стал тыркать режимы PCI, и внезапно при принудительном режиме x8/x8 оно заработало как надо:

FC id

noreply@blogger.com (AccessD) — Thu, 4 Sep 2014 17:55:00 +0400

Выдернуть wwid с FC карточки:

systool -c fc_host -v

В выводе среди прочего будет что-то типа:

port_name = "0x21000024ffxxxxxx"

Удаление зависимостей

noreply@blogger.com (AccessD) — Tue, 2 Sep 2014 17:50:00 +0400

Cнес к чертям 2 онлайн гамы, в которые играл больше года. Вот так вот )

Рекурсивный рерайт на CGI

noreply@blogger.com (AccessD) — Wed, 20 Aug 2014 17:42:00 +0400

Сделал челу пых как cgi (без супхп), у него стала валиться 500 ошибка из-за косяка с рерайтами:

Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace
r->uri = /cgi-bin/php/index.php
redirected from r->uri = /index.php
redirected from r->uri = /cgi-bin/php/index.php
redirected from r->uri = /index.php
redirected from r->uri = /cgi-bin/php/index.php
redirected from r->uri = /index.php
redirected from r->uri = /cgi-bin/php/index.php
redirected from r->uri = /index.php
redirected from r->uri = /cgi-bin/php/index.php
redirected from r->uri = /index.php
redirected from r->uri = /

Сделал отдельный рерайт для cgi-bin/php, помогло:

RewriteCond %{REQUEST_URI} ^/cgi-bin/php(.*)
RewriteRule . - [L]

Замена диска в софтовом md рэйде

noreply@blogger.com (AccessD) — Wed, 13 Aug 2014 17:12:00 +0400

Чтобы в маны не лазить:

# sfdisk -d /dev/sdb > sdb.out
# sfdisk /dev/sdc < sdb.out
# mdadm --manage /dev/md0 --remove /dev/sda2
# mdadm --manage /dev/md1 --add /dev/sdc2
# cat /proc/mdstat

# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sda3[2](F) sdb3[1]
      273659136 blocks [2/1] [_U]
      bitmap: 39/131 pages [156KB], 1024KB chunk

md0 : active raid1 sdc2[2] sdb2[1]
      8193024 blocks [2/1] [_U]
      [>....................] recovery = 1.5% (128000/8193024) finish=2.0min speed=64000K/sec
      bitmap: 0/126 pages [0KB], 32KB chunk

md1 : active raid1 sdb1[1] sda1[2](F)
      30716160 blocks [2/1] [_U]
      bitmap: 48/235 pages [192KB], 64KB chunk

# mdadm --manage /dev/md1 --remove /dev/sda1
# mdadm --manage /dev/md1 --add /dev/sdc1
# mdadm --manage /dev/md2 --remove /dev/sda3
# mdadm --manage /dev/md2 --add /dev/sdc3

# cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sdc3[2] sdb3[1]
      273659136 blocks [2/1] [_U]
        resync=DELAYED
      bitmap: 39/131 pages [156KB], 1024KB chunk

md0 : active raid1 sdc2[0] sdb2[1]
      8193024 blocks [2/2] [UU]
      bitmap: 0/126 pages [0KB], 32KB chunk

md1 : active raid1 sdc1[2] sdb1[1]
      30716160 blocks [2/1] [_U]
      [=====>...............] recovery = 28.7% (8835968/30716160) finish=6.7min speed=54126K/sec
      bitmap: 48/235 pages [192KB], 64KB chunk

Centos 5: from baremetal to Xen domU

noreply@blogger.com (AccessD) — Sun, 3 Aug 2014 23:42:00 +0400

Понадобилось перенести железный сервер с Centos 5 в ксен. Как обычно сделал лвмку, засинкал, поправил fstab, grub - не грузится. Ядро не катит.
Вспомнил, что pvops в Centos 5 не было, решил в чруте на лвмке поставить ксеновое ядро. Да вот хрен там. Видимо, с инитрд косяк. Тогда поступил так:
1. на исходном сервере установил ксеновое ядро.
2. отсинкал сервер заново
3. поправил fstab, поправил grub.conf, приведя ксеновую секцию к виду:

title CentOS (2.6.18-371.11.1.el5xen)
        root (hd0,0)
        kernel /boot/vmlinuz-2.6.18-371.11.1.el5xen ro root=/dev/xvda1
        initrd /boot/initrd-2.6.18-371.11.1.el5xen.img

4. на всякий пожарный пересобрал инитрд
5. поправил /etc/modprobe.conf:

alias eth0 xennet
alias eth1 xennet
alias scsi_hostadapter xenblk
#alias eth0 e1000
#alias eth1 e1000
#alias eth2 e1000
#alias scsi_hostadapter aacraid
#alias scsi_hostadapter1 ata_piix

После этого виртуалка поднялась.

UPDATE

Проделал то же самое с ещё одной машиной - не поднялась. Паника:

XENBUS: Device with no driver: device/console/0
XENBUS: Device with no driver: device/vbd/51713
XENBUS: Device with no driver: device/vbd/51714
XENBUS: Device with no driver: device/vif/0
XENBUS: Device with no driver: device/vif/1
Initalizing network drop monitor service
Write protecting the kernel read-only data: 506k
USB Universal Host Controller Interface driver v3.0
SCSI subsystem initialized
Adaptec aacraid driver 1.1-5[24702]
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.11.6-ioctl (2011-02-18) initialised: dm-devel@redhat.com
device-mapper: dm-raid45: initialized v0.2594l
Kernel panic - not syncing: Attempted to kill init!

Решил так:

mount /dev/vg_vm/s9 /1
mount --bind /proc /1/proc/
mount --bind /sys /1/sys
chroot /1/
yum erase kernel-xen
yum install kernel-xen
vi /boot/grub/grub.conf

Видимо, руками инитрд плохо пересобрал

Xen: Freebsd 10 install

noreply@blogger.com (AccessD) — Sun, 3 Aug 2014 23:29:00 +0400

Как поставить на ксен фряху:

virt-install -n testbsd -r 512 --vcpus=1 -v --hvm --cdrom /root/FreeBSD-10.0-RELEASE-amd64-disc1.iso --disk path=/dev/vg_vm/testbsd --vnc --network=bridge:br0

После чего заходим по vnc и просто сетапим )

Xen domU wrong clock

noreply@blogger.com (AccessD) — Thu, 31 Jul 2014 14:02:00 +0400

Проблема с ксеном и часами - в виртуалках время сбито вперед на размер таймзоны. Т.е. время 12:00 MSK, а в машине 16:00 MSK. И так и сяк ковырял, пробовал разные ежимы часов для машины - только ещё хуже становилось, на двойной размер уползали часы.
Правил время через NTP. Пока не наткнулся, на машину, которая не переводила часы через NTP.
Стал опять возится с часами. Решил на ноде включить часы в UTC - и помогло, часы в виртуалках встали как надо:

hwclock -w --utc --debug

Как попасть в Sagrada Familia без очереди

noreply@blogger.com (AccessD) — Wed, 9 Jul 2014 12:55:00 +0400

Если вы были в Барселоне, то наверняка ходили посмотреть на Саграда Фамилиа. И наверняка она вам понравилась и вы захотели попасть внутрь ) и внезапно очередь, которая тянется огибая весь квартал, в котором стоит базилика. Стоять там можно от 2 до 4 часов.
Попасть без очереди в нее очень просто - надо купить билеты онлайн.

Заходим на офсайт: http://www.sagradafamilia.cat/sf-eng/docs_serveis/infoTarifesInd.php
Выбираем нужный нам вид посещения - например с аудиогидом и посещением башни:

Попадаем на https://www.clorian.com/site/SagradaFamilia/product/15/type/1?lang=en
Выбираем посетителей, число и время посещения, врямя захода в башню, например на Страстном фасаде:

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

Получаем на почту PDF с билетами.

ВНИМАНИЕ! Во вложении именно билеты! Ничего распечатывать в банкоматах не надо!

Осталось распечатать PDF. Возможно, что печатать билеты не надо, я заметил на входе для онлайн билетов табличку: "Ticket, smartfone, tablet".

Но на всякий случай, думаю, стоит напечать. Напечатать можно в т.н. переговорных - Locuteria, типа интернет кафе. В Йорет де Мар (Lloret de Mar) нашёл только в одном месте, подсказала тетушка из кафе, в котором обедали - рядом с Автовокзалом (bus terminal):

Вход с онлайн билетами с противоположной от касс стороны базилики - со стороны фасада Рождества.

Косяк с местом в openvz

noreply@blogger.com (AccessD) — Fri, 16 May 2014 17:25:00 +0400

Контейнер занимает 16 гиг, df внутри показывает 35 гиг.
vzquota show тоже показывает 35.

Лечим так:

vzqouta show 100
vzctl stop 100
vzquota drop 100
vzctl start 100
vzqouta show 100

Видим разницу )

Заявочка

noreply@blogger.com (AccessD) — Mon, 12 May 2014 11:00:00 +0400

Ппц тут тикет свалился:

Около 6-8 месяцев назад, была подключена функция параллельного отражения электронной почтя на смартфоне I-phone 5.

Функция служебной электронной почты корректно работала в течении этого периода.

Вчера около 15 часов сообщения эл. Почты перестали приходить на смартфон.
На смартфоне всплывает окно – «подключение к серверу не удалось».

Настройки смартфона в разделе эл. Почте не изменялись.
Все настройки установлены в прежнем формате.

Я плакал

На EX4200 из VC не заводится RE

noreply@blogger.com (AccessD) — Mon, 21 Apr 2014 17:12:00 +0400

Был VC из 2х EX4200. Демонтировал, убрал на склад. Через некоторое время один из них понадобилось поставить отдельно.
Включаю, он говорил, что он linecard, даже конфиг не сохраняет.
Убрал из конфига синхронизацию конфига, закоммитилось.

Дальше выяснилось, что свич считает, что он член разделенного шасси и re на себе не запускает. Деактивация всей ветки vc не помогла. Добавил в конфиг vc no-split-detection и свич стал мастером )

openvpn bridge и selinux

noreply@blogger.com (AccessD) — Tue, 18 Mar 2014 23:04:00 +0400

Появилась нужда поднять openvpn как мост. Чтобы сразу клиента в частную сеть совать.
Сделал ключи, серты - как обычно.
Настроил сервер:

port 1194
proto tcp
dev tap0
tls-server
keepalive 10 120
persist-key
client-config-dir /etc/openvpn/cc
server-bridge 172.30.4.0 255.255.254.0 172.30.5.240 172.30.5.253
duplicate-cn
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/vpnserver.crt
key /etc/openvpn/keys/vpnserver.key
dh /etc/openvpn/keys/dh2048.pem

Сделал тап и мост:

# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
HWADDR=00:AA:BB:11:22:33
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
BRIDGE=br1

# cat /etc/sysconfig/network-scripts/ifcfg-tap0
DEVICE=tap0
ONBOOT=yes
TYPE=Tap
BOOTPROTO=none
BRIDGE=br1

# cat /etc/sysconfig/network-scripts/ifcfg-br1
DEVICE=br1
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=static
IPADDR=172.30.4.1
NETMASK=255.255.254.0

А дальше запускаю сервер - и selinux не дает ему взлететь из-за отсутствия прав на тап:

Mar 18 22:24:09 vpn openvpn[1103]: ERROR: Cannot ioctl TUNSETIFF tap0: Permission denied (errno=13)
Mar 18 22:24:09 vpn openvpn[1103]: Exiting due to fatal error

type=SYSCALL msg=audit(1395167049.663:28): arch=c000003e syscall=16 success=no exit=-13 a0=6 a1=400454ca a2=7fffa15bc350 a3=8 items=0 ppid=1094 pid=1103 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="openvpn" exe="/usr/sbin/openvpn" subj=unconfined_u:system_r:openvpn_t:s0 key=(null)
type=AVC msg=audit(1395167130.413:29): avc: denied { relabelfrom } for pid=1122 comm="openvpn" scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=tun_socket

Решил не отключать селинукс, а сделать разрешение.

# audit2allow -w -a
type=AVC msg=audit(1395167049.663:28): avc: denied { relabelfrom } for pid=1103 comm="openvpn" scontext=unconfined_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=tun_socket
        Was caused by:
                Unknown - would be allowed by active policy
                Possible mismatch between this policy and the one under which the audit message was generated.

                Possible mismatch between current in-memory boolean settings vs. permanent ones.

# audit2allow -a
#============= openvpn_t ==============

#!!!! This avc is allowed in the current policy
allow openvpn_t initrc_t:tun_socket relabelfrom;

# audit2allow -a -M myopenvpn
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i myopenvpn.pp

# cat myopenvpn.te

module myopenvpn 1.0;

require {
        type openvpn_t;
        type initrc_t;
        class tun_socket relabelfrom;
}

#============= openvpn_t ==============

#!!!! This avc is allowed in the current policy
allow openvpn_t initrc_t:tun_socket relabelfrom;

# semodule -i myopenvpn.pp

Вот теперь все работает )

битрикс жжет

noreply@blogger.com (AccessD) — Wed, 29 Jan 2014 17:09:00 +0400

Я херею. битрик, посаженный в свежий битрикс окружение (с 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

noreply@blogger.com (AccessD) — Fri, 24 Jan 2014 20:51:00 +0400

Нашёл, наконец, как этой вашей вмваре - 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

noreply@blogger.com (AccessD) — Wed, 22 Jan 2014 22:51:00 +0400

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

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

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

noreply@blogger.com (AccessD) — Fri, 17 Jan 2014 22:40:00 +0400

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

mini
din 6     db9

1             2
2             3
3             5
4             8
5
6             7

cron и mail - attachment вместо body

noreply@blogger.com (AccessD) — Wed, 30 Oct 2013 16:55:00 +0400

Скидываю на мыло некий лог (в кот. есть кириллица).
Отрабатываю из консоли - все ок, приходить письмо с логом в теле.
Сую в крон - текста нет, зато есть аттач.

Прикинул, что mail почему-то считает ввод бинарным. Видимо из-за нестыковок локалей.
Решил проблему добавлением в крон локали:

LANG=ru_RU.UTF-8
LANGUAGE=ru
LC_CTYPE=ru_RU.UTF-8
CONTENT_TYPE="text/plain; charset=utf-8"

0 19 * * * /root/logparse.pl | mail -r noreply@blabla.ru -s "Login report" mail0@gmail.com mail1@gmail.com; echo > /var/log/my.log

Чиним сломанный сайт

noreply@blogger.com (AccessD) — Fri, 18 Oct 2013 16:29:00 +0400

Клиенту сайт поломали. Открывается ппц долго. Решили перед тем, как бекап отдать, сами посмотреть.
Итак - начинаем с предположения, что при запуске пых процесса он коннектится куда-то.

1. Запускаю курлом хит по сайту, на серваке делаю ps aux с грепом по юзеру и netstat -lntp | grep php. Да, куда-то ломится - на 192.151.154.180 По адресу видимо искать смысла нет, в коде наверняка хостнейм. Для очистки совести греп по жумле - нету такого.

2. Ок, давайте найдём хостнейм. Запускаем tcpdump -nnt -A port 53 > dnslog и опять жмакаем по сайту. Отлично, в полученном логе по адресу находим хостнейм.
IP 188.xx.xx.133.53 > 188.xx.xx.21.46260: 951 2/2/4 A 192.151.154.180, (206) api.ipinfodb.com

3. Грепаем по хостнейму файло - находим занятный файлик /home/cpxxxxxx/public_html/libraries/joomla/plugin/qdh1ym.php. В нём, среди прочих няшек, упоминается ещё один: /home/cpxxxxxx/public_html/includes/thx7r.txt

4. Муваем файлики, жмакаем по сайту - открылся сразу, но с ошибкой require. Комментим этот require - сайт работает )

А дальше надо искать дыру, через которую инклюд сделали и посмотреть на предмет ходовых зараз.

Apache: Cannot create SSLMutex Configuration Failed

noreply@blogger.com (AccessD) — Tue, 20 Aug 2013 04:56:00 +0400

Подняли, блин, под утро.. Апач упал, при запуске в лог:

[error] (28)No space left on device: Cannot create SSLMutex Configuration Failed

Семафоры надо дропнуть:

ipcs -s | grep http| awk '{print $2}' > sema
for a in `cat sema`;do ipcrm -s $a;done

Вставки sed'ом

noreply@blogger.com (AccessD) — Thu, 15 Aug 2013 19:03:00 +0400

Вставить пару строк в начало:

sed -i '1iWorkDir: \/var\/www\/mrtg\/\nOptions[_]: growright, bits' sw1.example.ru.cfg

Вставить строчку после определённой:

sed -i '/^prog=nginx/i ulimit -n 16384' /etc/init.d/nginx

cpanel backup config file

noreply@blogger.com (AccessD) — Mon, 3 Jun 2013 14:17:00 +0400

Ха, грепал, грепал и нагрепал )

/etc/cpbackup.conf