[Sysadmins] IPsec, p10, ядро 5.10.174-std-def-alt1, strongswan 5.9.10-alt1 и Кинетик с Микротиком

[Alex Moskalenko]

Здравствуйте.

В попытках установить IPsec-туннель между сервером на стареньком Xeon с 
AES-NI, AVX и без AVX2 и двумя удаленными точками с Keenetic и Mikrotik 
наткнулся на непонятное поведение скорее всего ядра.


Пытаюсь поднять обычный IKEv2 туннель между сетями с параметрами IKE 
AES_CBC_256/HMAC_SHA2_256_128/MODP_2048 и параметрами ESP 
AES_CBC_256/HMAC_SHA2_256_128/MODP_2048. Согласование проходит, 
соединение устанавливается, ESP SAs создаются (с одинаковыми ключами на 
обоих сторонах), маршрут также создается - но трафик не ходит. При этом 
на каждый отправленный любой из сторон ESP-пакет увеличивается счетчик 
failed на другой стороне туннеля.


Путем экспериментов было выяснено, что если в ESP (и только в ESP) 
изменить SHA256 на SHA1 (получается AES_CBC_256/HMAC_SHA1_96/MODP_2048) 
- проблема исчезает, счетчики ошибок нулевые и трафик ходит.


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


Подскажите пожалуйста, из-за чего может возникать такая ситуация и как 
все-таки заставить работать SHA256 в ESP.


___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] DNS-over-TLS proxy

[Alex Moskalenko]

Здравствуйте.

Подскажите пожалуйста, чем в наших дистрибутивах правильно пользоваться 
для организации прокси DNS-over-TLS? Для DNS-over-HTTPS есть 
dnscrypt-proxy, а для DNS-over-TLS что?


Заранее спасибо.

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] P9 OpenVZ7 - автоматическое добавление veth-интерфейса в бридж

[Alex Moskalenko]

В процессе "исследований" выяснилось следующее:

1. При создании veth-интерфейса запускается 
/usr/share/libvzctl/scripts/vz-netns_dev_add


2. В нем вызывается функция vzconfbridge из 
/usr/share/libvzctl/scripts/vz-functions


3. vzconfbridge проверяет, установлена ли переменная BRIDGE, и если да - 
то добавляет интерфейс в мост $BRIDGE.


Вопрос - где и что нужно указать, чтобы эта $BRIDGE была установлена в 
момент вызова vz-netns_dev_add. Указание BRIDGE=br0, ручное добавление 
bridge=br0 в NETIF=... конфигурационного файла VE и export BRIDGE=br0 в 
mount-скрипте VE не сработало. Но указание BRIDGE=br0 в vz.conf ВНЕЗАПНО 
сработало - интерфейс добавился в указанный мост. Но если разные VE или 
разные интерфейсы одной VE нужно подключать к разным мостам - это не 
вариант.


04.12.2020 11:35, Alex Moskalenko пишет:


2. Непонятно пока, что делать с контейнерами, использующими veth. В p8 
был файл vznet.conf, в котором указывался внешний скрипт, добавляющий 
veth-интерфейс со стороны хоста в указанный в конфигурационном файле 
VE мост. В p9 vzctl вообще не знает параметр bridge= в конфигурации 
VE, а файлы vznet.conf похоже вообще не читается и внешний скрипт не 
вызывается. В mount-скрипте интерфейс еще не создан. Как теперь 
правильно добавлять veth-интерфейсы контейнеров в бридж



___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] P9 OpenVZ7 - автоматическое добавление veth-интерфейса в бридж

[Alex Moskalenko]

Здравствуйте.

Есть система на p8 с некоторым количеством OpenVZ-контейнеров с ядром 
ovz-el. Есть желание перенести ее на p9 и ядро ovz-el7. Собственно 
процесс переноса хост-системы особх вопросов не вызывает, а вот с 
переносом контейнеров есть вопросы. Может, я что-то пропустил в 
документации, поэтому прошу поправить и направить.


1. Перенос собственно контейнеров (часть в simfs, часть в ploop) проще 
всего провести через создание архива rootfs, удаление старого контейнера 
и создание нового с распаковкой rootfs в него. Скрипты миграции, которые 
находятся в инете, делают по сути то же самое. Это правильное решение? 
Даунтайм контейнеров приемлем.


2. Непонятно пока, что делать с контейнерами, использующими veth. В p8 
был файл vznet.conf, в котором указывался внешний скрипт, добавляющий 
veth-интерфейс со стороны хоста в указанный в конфигурационном файле VE 
мост. В p9 vzctl вообще не знает параметр bridge= в конфигурации VE, а 
файлы vznet.conf похоже вообще не читается и внешний скрипт не 
вызывается. В mount-скрипте интерфейс еще не создан. Как теперь 
правильно добавлять veth-интерфейсы контейнеров в бридж



___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] P9, переезд с /var/{run,lock} -> /{run,run/lock}

[Alex Moskalenko]

Здравствуйте.

Наткнулся еще на две проблемы после переезда /var/run->run на sysvinit.

1. Каталог /var/run/devecot присутствует в пакете dovecot, файл для 
tmpfiles.d отсутствует. #37554.
2. sqlgrey не может работать со своим pid-файлом в /var/run. Предлагаю 
перенести его в /var/run/sqlgrey с соответствующими правками 
/etc/sqlgrey/sqlgrey.conf, /etc/init.d/sqlgrey и созданием файла для 
tmpfiles.d. #37555.

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] P9, переезд с /var/{run,lock} -> /{run,run/lock}

[Alex Moskalenko]

Антон Мидюков писал 14.11.2019 17:41:

14.11.2019 21:37, Alex Moskalenko пишет:
Попробовал провести процедуру на другой машине (libvirt там правда 
нет). Поймал две проблемы:


1. Не стартует amavisd из-за неправильных прав на каталог 
/var/run/amavis - выставлены 755, нужны 775. Ошибка в файле 
/lib/tmpfiles.d/amavisd.conf.
2. При старте nginx ругается на невозможность создать 
/var/lock/nginx/nginx. Этот каталог файлах tmpfiles.d не указан, но 
прописан как LOCKFILE в init-скрипте nginx. Тут склоняюсь к тому. что 
неправ init-скрипт и lock-файл нужно создавать в стандартном месте - 
/var/lock/subsys.


Стоит вешать баги на amavisd-new и nginx по этому поводу (sysvinit 
все-таки...)?

Конечно же стоит!


#37488 для amavisd-new, #37489 для nginx.

---
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] P9, переезд с /var/{run,lock} -> /{run,run/lock}

[Alex Moskalenko]

Антон Мидюков писал 13.11.2019 13:32:

13.11.2019 16:53, Alex Moskalenko пишет:

Антон Мидюков писал 13.11.2019 11:33:
Я правильно понимаю, что нужно переместить текущее содержимое 
/var/lock в /run/lock, /var/run в /run, удалить /var/{run,lock} и 
создать симлинки /var/run->/run и /var/lock->/run/lock?



Да. Но возможны сбои работы в системе до перезагрузки, поэтому уже
установленные системы пользователи должны переводить сами, при
необходимости.
Переместил содержимое и сделал симлинки, предварительно остановив и 
запустив после создания симлинков тех, кто использовал 
/var/{run/lock}. Сейчас так:

ls -l /var
.
lrwxrwxrwx  1 root root  9 ноя 13 11:53 lock -> /run/lock
lrwxrwxrwx  1 root root  4 ноя 13 11:52 run -> /run

Из использовавших файлы в /var/run оказались fail2ban, monit, 
zabbix_agentd, crond, chronyd и acpid. Также в /var/lock есть 
каталоги, которых нет в /run/lock. То же с /var/run и /run.
Мучает вопрос - после перезагрузки эти каталоги с нужными правами 
будут созданы заново? Или это мусор, оставшийся в процессе обновлений 
системы? Пока перезагрузиться и проверить не могу...


В /run будут созданы каталоги, которые прописаны в конфигах:

/lib/tmpfiles.d/*.conf

/etc/tmpfiles.d/*.conf

Если какие-то пакеты всё ещё напрямую содержат каталоги в /var/run и
не имеют конфигов tmpfiles.d, то на них нужно заводить баги и срочно
исправлять.
Попробовал провести процедуру на другой машине (libvirt там правда нет). 
Поймал две проблемы:


1. Не стартует amavisd из-за неправильных прав на каталог 
/var/run/amavis - выставлены 755, нужны 775. Ошибка в файле 
/lib/tmpfiles.d/amavisd.conf.
2. При старте nginx ругается на невозможность создать 
/var/lock/nginx/nginx. Этот каталог файлах tmpfiles.d не указан, но 
прописан как LOCKFILE в init-скрипте nginx. Тут склоняюсь к тому. что 
неправ init-скрипт и lock-файл нужно создавать в стандартном месте - 
/var/lock/subsys.


Стоит вешать баги на amavisd-new и nginx по этому поводу (sysvinit 
все-таки...)?

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] P9, libvirt-5.7.0 - не работают virsh, virt-manager

[Alex Moskalenko]

Антон Мидюков писал 13.11.2019 11:33:
Я правильно понимаю, что нужно переместить текущее содержимое 
/var/lock в /run/lock, /var/run в /run, удалить /var/{run,lock} и 
создать симлинки /var/run->/run и /var/lock->/run/lock?



Да. Но возможны сбои работы в системе до перезагрузки, поэтому уже
установленные системы пользователи должны переводить сами, при
необходимости.
Переместил содержимое и сделал симлинки, предварительно остановив и 
запустив после создания симлинков тех, кто использовал /var/{run/lock}. 
Сейчас так:

ls -l /var
итого 64
drwxr-xr-x  2 root root   4096 авг 28  2018 adm
drwxr-xr-x 10 root root   4096 авг 28  2018 cache
drwxr-xr-x  3 root root   4096 сен 30 12:55 db
dr-xr-xr-x  2 root root   4096 авг 28  2018 empty
drwxr-xr-x  6 root root   4096 июн 28 14:19 hasplm
drwxr-xr-x 32 root root   4096 ноя 12 17:23 lib
drwxr-xr-x  2 root root   4096 авг 28  2018 local
lrwxrwxrwx  1 root root  9 ноя 13 11:53 lock -> /run/lock
drwxr-xr-x 21 root root   4096 ноя 10 04:02 log
lrwxrwxrwx  1 root root 10 сен 12 15:25 mail -> spool/mail
drwxr-xr-x  2 root root   4096 авг 28  2018 nis
drwxr-x---  2 root nobody 4096 авг 28  2018 nobody
drwxr-xr-x  2 root root   4096 авг 28  2018 opt
drwxr-xr-x  2 root root   4096 авг 28  2018 preserve
drwxr-xr-x  5 root root   4096 апр 29  2019 resolv
lrwxrwxrwx  1 root root  4 ноя 13 11:52 run -> /run
drwxr-xr-x  8 root root   4096 сен 12 15:27 spool
drwxrwxrwt  2 root root   4096 авг 28  2018 tmp
drwxr-xr-x  2 root root   4096 авг 28  2018 yp

Из использовавших файлы в /var/run оказались fail2ban, monit, 
zabbix_agentd, crond, chronyd и acpid. Также в /var/lock есть каталоги, 
которых нет в /run/lock. То же с /var/run и /run.
Мучает вопрос - после перезагрузки эти каталоги с нужными правами будут 
созданы заново? Или это мусор, оставшийся в процессе обновлений системы? 
Пока перезагрузиться и проверить не могу...

---
WBR, Alex Moskalenko

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] P9, libvirt-5.7.0 - не работают virsh, virt-manager

[Alex Moskalenko]

Антон Мидюков писал 13.11.2019 10:44:

13.11.2019 14:36, Alex Moskalenko пишет:
Есть система на p9 с sysvinit. На ней обновился libvirt c 5.6.0-alt1 
p9+236527.100.1.1 до 5.7.0-alt1 p9+238412.2000.8.2. После обновления 
перестали работать утилиты управления (virsh, virt-manager) с 
одинаковой диагностикой:



ошибка: не удалось подключиться к гипервизору
ошибка: Failed to connect socket to '/var/run/libvirt/libvirt-sock': 
Нет такого файла или каталога

Необходимо перейти на симлинки /var/run -> /run и /var/lock -> run/lock

В новых инсталляциях переход производится постустановочным скриптом.


Спасибо за быстрый ответ.
Я правильно понимаю, что нужно переместить текущее содержимое /var/lock 
в /run/lock, /var/run в /run, удалить /var/{run,lock} и создать симлинки 
/var/run->/run и /var/lock->/run/lock?


Система обновлялась с P8, в ней получается, это не было сделано 
автоматически при апгрейде? У меня несколько таких систем, обновленных 
p8->p9, это нужно сделать везде?

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] P9, libvirt-5.7.0 - не работают virsh, virt-manager

[Alex Moskalenko]

Здравствуйте. 

Есть система на p9 с sysvinit. На ней обновился libvirt c 5.6.0-alt1
p9+236527.100.1.1 до 5.7.0-alt1 p9+238412.2000.8.2. После обновления
перестали работать утилиты управления (virsh, virt-manager) с одинаковой
диагностикой: 

ошибка: не удалось подключиться к гипервизору
ошибка: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Нет
такого файла или каталога 

При этом сам libvirtd, его обвязка (virtlogd, virtlockd) и виртуальные
машины запускаются и работают. 

Было замечено, что после обновления все pid-файлы, сокеты и
соответствующие каталоги переехали из /var/run в /run. Но почему-то
virsh, virt-manager и т.п. по-прежнему пытаются подключиться к сокету в
/var/run. Где можно изменить путь до сокета для клиентов libvirt - не
нашел. В конфигах в /etc/libvirt все строчки с путями до сокетов
раскомментированы. Создание симлинков на сокеты в /var/run проблему
решает. 

В связи с этим вопросы - почему это происходит и как правильно решить
проблему? Есть подозрение, что это из-за отсутствия systemd. Если это
так - то получается, что p9 даже в серверном варианте уже не полностью
работоспособен без systemd, и с этим нужно что-то делать. 

PS Видимо, пришло время даже в серверных вариантах переходить на systemd
с sysvinit 

-- 
WBR, Alex Moskalenko___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Postfix multi-instance

[Alex Moskalenko]

Быстрый хак на предмет поддержки Postfix Multi-instance в chroot.d-скриптах.

Хак со следующими условностями: дополнительные экземпляры должны иметь 
spool_directory там же, где и основной экземпляр, и их имена должны 
начинаться с postfix (так и происходит при создание дополнительных 
экземпляров с помощью postmulti с параметрами по умолчанию). Сделано для 
того, чтобы какой-нибудь экземпляр с queue_directory=/ не спровоцировал 
удаление системных /{etc,lib,lib64} при работе скриптов из chroot.d.


Есть смысл на эту тему баг заводить или это дикая экзотика?


09.11.2019 18:28, Alex Moskalenko пишет:

Здравствуйте.

Я правильно понимаю, что какая-либо поддержка Multi-instance в 
chroot.d-скриптах postfix'а у нас отсутствует совсем?


Понадобилось поднять несколько экземпляров Postfix'а на одной машине. 
Создал их с помощью postmulti, настроил, и понял, что без ручного 
копирования в их каталоги нужных файлов и библиотек ничего не работает.


Нет ли каких-нибудь наработок в этой области?

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins
diff -uNr old/postfix.conf new/postfix.conf
--- old/postfix.conf	2016-03-02 17:52:33.0 +0300
+++ new/postfix.conf	2019-11-09 23:32:07.173447039 +0300
@@ -5,33 +5,35 @@
 
 [ -n "$verbose" ] && err_null= || err_null='2>/dev/null'
 postconf='/usr/sbin/postconf -E'
-eval $postconf >/dev/null $err_null || exit
 
-cd /var/spool/postfix
-
-incompatible_maps="alias_database alias_maps"
-force_alias=
-force_alias_maps=
-force_map=
-if [ -n "$force" ]; then
+for pinst in /etc/postfix $($postconf -h multi_instance_directories); do
+eval $postconf -c $pinst >/dev/null $err_null || continue
+cd "$($postconf -c $pinst -h queue_directory)"
+pwd | grep -q "^/var/spool/postfix.*" || continue
+
+incompatible_maps="alias_database alias_maps"
+force_alias=
+force_alias_maps=
+force_map=
+if [ -n "$force" ]; then
 	force_alias=1
 	force_alias_maps=1
 	force_map=1
 	# Purge all configs from chroot
 	rm -f etc/*
-fi
+fi
 
-copy_resolv_conf
+copy_resolv_conf
 
-suffix_hash=db
-suffix_cdb=cdb
+suffix_hash=db
+suffix_cdb=cdb
 
-# alias_database
-if [ -z "$force_alias" ]; then
+# alias_database
+if [ -z "$force_alias" ]; then
 	for type in hash cdb; do
 		update_alias=
 		eval suffix=\$suffix_$type
-		for src in `$postconf -h alias_database |
+		for src in `$postconf -c $pinst -h alias_database |
 tr -s ', 	' '\n' |
 sort -u |
 sed -n 's,^'$type':\(/.*\),\1,p'`; do
@@ -42,16 +44,16 @@
 			break 2
 		done
 	done
-fi
-if [ -n "$force_alias" -o -n "$update_alias" ]; then
-	/usr/bin/newaliases $verbose ||
-		Fatal "failed to update alias database"
-fi
+fi
+if [ -n "$force_alias" -o -n "$update_alias" ]; then
+	/usr/bin/newaliases -C $pinst $verbose ||
+		Info "failed to update alias database for $pinst"
+fi
 
 # alias_maps
-for type in hash cdb; do
+for type in hash cdb; do
 	eval suffix=\$suffix_$type
-	for src in `$postconf -h alias_maps |
+	for src in `$postconf -c $pinst -h alias_maps |
 			tr -s ', 	' '\n' |
 			sort -u |
 			sed -n 's,^'$type':\(/.*\),\1,p'`; do
@@ -63,22 +65,22 @@
 update_alias_map=1
 		fi
 		if [ -n "$force_alias_map" -o -n "$update_alias_map" ]; then
-			postalias $verbose "$src" ||
-Fatal "failed to update alias map $src database"
+			postalias -c $pinst $verbose "$src" ||
+Info "failed to update alias map $src database for $pinst"
 		fi
 	done
-done
+done
 
 # other maps
-for type in hash cdb; do
+for type in hash cdb; do
 	eval suffix=\$suffix_$type
-	for src in `$postconf |
+	for src in `$postconf -c $pinst |
 			tr -s ', 	' '\n' |
 			sort -u |
 			sed -n 's,^'$type':\(/.*\),\1,p'`; do
 		# Filter out incompatible maps
 		for map in $incompatible_maps; do
-			test "`$postconf -h $map`" = "$type:$src" && src="" && break || :
+			test "`$postconf -c $pinst -h $map`" = "$type:$src" && src="" && break || :
 		done
 		[ -f "$src" ] || continue
 		update_map=
@@ -88,14 +90,15 @@
 update_map=1
 		fi
 		if [ -n "$force_map" -o -n "$update_map" ]; then
-			postmap $verbose "$type:$src" ||
-Fatal "failed to update $src database"
+			postmap -c $pinst $verbose "$type:$src" ||
+Info "failed to update $src database for $pinst"
 		fi
 	done
-done
+done
 
-nono='no
+nono='no
 no'
-if [ "`$postconf -h smtp_use_tls smtpd_use_tls`" != "$nono" ]; then
+if [ "`$postconf -c $pinst -h smtp_use_tls smtpd_use_tls`" != "$nono" ]; then

Re: [Sysadmins] Обновление samba-DC 4.7.12 ->4.9.13

[Alex Moskalenko]

Хм, а жизнь-то похоже налаживается...

В текущем P9 (samba-4.10.8-alt2.x86_64, bind-9.11.6.P1-alt1.x86_64) 
выполнил samba_upgradedns --dns-backend=SAMBA_INTERNAL; samba_upgradedns 
--dns-backend=BIND9_DLZ. Перезапустил bind и samba - и регистрации 
записей DNS с Windows-клиентов заработали! Осталась проблема с 
samba_dnsupdate, описанная в 
https://bugzilla.samba.org/show_bug.cgi?id=13066 и
http://samba.2283325.n4.nabble.com/Samba-4-7-2-bind-on-Fedora-27-samba-dlz-spnego-update-failed-td4727145.html. 
После добавления в /etc/sysconfig/bind KRB5RCACHETYPE="none" и 
samba_dnsupdate стал выполняться без ошибок.


Похоже, все вылечилось само каким-то волшебным образом. Если в течение 
недели не будет проблем с обновлением записей DNS - багу закрою.


PS bind из чрута вынут (control bind_chroot disabled) и выполняется от 
пользователя named, как и должен.


---
WBR, Alex Moskalenko

Alex Moskalenko писал 03.10.2019 06:30:

02.10.2019 23:55, so...@shpl.ru пишет:

Судя по посту в рассылке, у Вас bind запускается от пользователя named
А Альте нужно запускать от root и вынуть из chroot.


Из chroot bind вынут. В chroot'е оно вообще работать не должно никак.
А вот про запуск от root прошу объяснить подробнее - чего не хватает
пользователю bind при соответствующих правах на файлы/каталоги. Более
того, в
https://lists.altlinux.org/pipermail/samba/2019-April/004331.html я
писал, что напускал на bind strace, и в итоге каких-либо ошибок
доступа к чему-либо не обнаружил.

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Обновление samba-DC 4.7.12 ->4.9.13

[Alex Moskalenko]

02.10.2019 23:55, so...@shpl.ru пишет:

Судя по посту в рассылке, у Вас bind запускается от пользователя named
А Альте нужно запускать от root и вынуть из chroot.

Из chroot bind вынут. В chroot'е оно вообще работать не должно никак. А 
вот про запуск от root прошу объяснить подробнее - чего не хватает 
пользователю bind при соответствующих правах на файлы/каталоги. Более 
того, в 
https://lists.altlinux.org/pipermail/samba/2019-April/004331.html я 
писал, что напускал на bind strace, и в итоге каких-либо ошибок доступа 
к чему-либо не обнаружил.






Alex Moskalenko писал 2019-10-02 18:19:

Evgeny Sinelnikov писал 02.10.2019 17:18:

3) "Коллеги, использующие ALT p8 или p9 с samba в качестве AD DC с
DNS-бэкэндом BIND9_DLZ, подскажите, работает ли у вас обновление 
записей

DNS клиентами Windows и samba_dnsupdate?"

Давайте определимся с критерием проверки.
- Что проверяем? Win7 в домене? или samba-клиент?
- Какие ошибки возникают при попытке обновления записей DNS?

Нужны конкретные команды, и вывод и более подробный лог ошибок. Можно
лично. Когда протестирую, перешлю уже проанализированные подробности.
Но лучше сразу сюда, просто объём может быть большим, поэтому обычно
поэтому обходятся минимальными подробностями.


Мои проблемы описаны еще в апреле в списке рассылки samba -
https://lists.altlinux.org/pipermail/samba/2019-April/004329.html
И даже баг в багзилле заведен -
https://bugzilla.altlinux.org/show_bug.cgi?id=36563

Проверяем безопасные обновления DNS, как с клиентов (Win10,
Win2019Server), так и с самого DC с помощью samba_dnsupdate.
С клиентов - ipconfig /registerdns, с самого DC - samba_dnsupdate.
Тестировал домен с 3мя DC - ALT, Ubuntu server 18.04 и Debian Buster
10. На текущий момент samba везде одинаковая - 4.10.8 (в ALT P9 -
штатная, в Ubuntu - из ppa School linux, в Debian - из репозитория
van-belle.nl.

Везде, кроме ALT, зоны успешно обновляются как клиентами, так и
samba_dnsupdate. На ALT же имеем в логах записи вида:
2019-04-04T11:21:17.993406+03:00 dc0 named[14068]: client
@0x7f01141236c0 192.168.0.11#35595/key DC0\$\@AD.LOCAL: update failed:
not authoritative for update zone (NOTAUTH)
2019-04-04T11:21:18.017841+03:00 dc0 named[14068]: client
@0x7f0104031eb0 192.168.0.11#48267/key DC0\$\@AD.LOCAL: update failed:
not authoritative for update zone (NOTAUTH)

На Ubuntu и на Debian в том же AD все работает штатно:
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: starting transaction on
zone ad.local
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: allowing update of
signer=PC-001\$\@AD.LOCAL name=pc-001.ad.local tcpaddr=192.168.0.36
type=
key=1360-ms-7.627-584955d5.1b29d6f6-d7a6-11e9-2986-18602489c1fa/160/0
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: allowing update of
signer=PC-001\$\@AD.LOCAL name=pc-001.ad.local tcpaddr=192.168.0.36
type=A
key=1360-ms-7.627-584955d5.1b29d6f6-d7a6-11e9-2986-18602489c1fa/160/0
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: allowing update of
signer=PC-001\$\@AD.LOCAL name=pc-001.ad.local tcpaddr=192.168.0.36
type=A
key=1360-ms-7.627-584955d5.1b29d6f6-d7a6-11e9-2986-18602489c1fa/160/0
Oct  2 17:12:42 dc1 named[15268]: client @0x7fd0a80d5ab0
192.168.0.36#64406/key PC-001\$\@AD.LOCAL: updating zone
'ad.local/NONE': deleting rrset at 'pc-001.ad.local' 
Oct  2 17:12:42 dc1 named[15268]: client @0x7fd0a80d5ab0
192.168.0.36#64406/key PC-001\$\@AD.LOCAL: updating zone
'ad.local/NONE': deleting rrset at 'pc-001.ad.local' A
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: subtracted rdataset
pc-001.ad.local 'pc-001.ad.local.#0111200#011IN#011A#011192.168.0.36'
Oct  2 17:12:42 dc1 named[15268]: client @0x7fd0a80d5ab0
192.168.0.36#64406/key PC-001\$\@AD.LOCAL: updating zone
'ad.local/NONE': adding an RR at 'pc-001.ad.local' A 192.168.0.36
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: added rdataset
pc-001.ad.local 'pc-001.ad.local.#0111200#011IN#011A#011192.168.0.36'
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: committed transaction on
zone ad.local

При этом на ALT при переключении на SAMBA_INTERNAL обновление зон DNS
с клиентов также не работает. Хотя в логах на сервере при этом пусто
(на loglevel по умолчанию), а на клиентах - предупреждения о
невозможности обновить записи A и .

Готов предоставить дополнительную информацию или даже тестовый стенд,
хотя ничего особенного в конфигурации у меня нет. Та же ситуация
получается при чистой установке с samba-tool domain provision.

Дальнейшее наверное имеет смысл обсуждать в рамках бага в багзилле,
чтоб не захламлять рассылку логами и т.п., а сюда уже написать резюме.
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailma

Re: [Sysadmins] Обновление samba-DC 4.7.12 ->4.9.13

[Alex Moskalenko]

02.10.2019 23:55, so...@shpl.ru пишет:

Судя по посту в рассылке, у Вас bind запускается от пользователя named
А Альте нужно запускать от root и вынуть из chroot.

Из chroot bind вынут. В chroot'е оно вообще работать не должно никак. А 
вот про запуск от root прошу объяснить подробнее - чего не хватает 
пользователю bind при соответствующих правах на файлы/каталоги. Более 
того, в 
https://lists.altlinux.org/pipermail/samba/2019-April/004331.html я 
писал, что напускал на bind strace, и в итоге каких-либо ошибок доступа 
к чему-либо не обнаружил.






Alex Moskalenko писал 2019-10-02 18:19:

Evgeny Sinelnikov писал 02.10.2019 17:18:

3) "Коллеги, использующие ALT p8 или p9 с samba в качестве AD DC с
DNS-бэкэндом BIND9_DLZ, подскажите, работает ли у вас обновление записей
DNS клиентами Windows и samba_dnsupdate?"

Давайте определимся с критерием проверки.
- Что проверяем? Win7 в домене? или samba-клиент?
- Какие ошибки возникают при попытке обновления записей DNS?

Нужны конкретные команды, и вывод и более подробный лог ошибок. Можно
лично. Когда протестирую, перешлю уже проанализированные подробности.
Но лучше сразу сюда, просто объём может быть большим, поэтому обычно
поэтому обходятся минимальными подробностями.


Мои проблемы описаны еще в апреле в списке рассылки samba -
https://lists.altlinux.org/pipermail/samba/2019-April/004329.html
И даже баг в багзилле заведен -
https://bugzilla.altlinux.org/show_bug.cgi?id=36563

Проверяем безопасные обновления DNS, как с клиентов (Win10,
Win2019Server), так и с самого DC с помощью samba_dnsupdate.
С клиентов - ipconfig /registerdns, с самого DC - samba_dnsupdate.
Тестировал домен с 3мя DC - ALT, Ubuntu server 18.04 и Debian Buster
10. На текущий момент samba везде одинаковая - 4.10.8 (в ALT P9 -
штатная, в Ubuntu - из ppa School linux, в Debian - из репозитория
van-belle.nl.

Везде, кроме ALT, зоны успешно обновляются как клиентами, так и
samba_dnsupdate. На ALT же имеем в логах записи вида:
2019-04-04T11:21:17.993406+03:00 dc0 named[14068]: client
@0x7f01141236c0 192.168.0.11#35595/key DC0\$\@AD.LOCAL: update failed:
not authoritative for update zone (NOTAUTH)
2019-04-04T11:21:18.017841+03:00 dc0 named[14068]: client
@0x7f0104031eb0 192.168.0.11#48267/key DC0\$\@AD.LOCAL: update failed:
not authoritative for update zone (NOTAUTH)

На Ubuntu и на Debian в том же AD все работает штатно:
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: starting transaction on
zone ad.local
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: allowing update of
signer=PC-001\$\@AD.LOCAL name=pc-001.ad.local tcpaddr=192.168.0.36
type=
key=1360-ms-7.627-584955d5.1b29d6f6-d7a6-11e9-2986-18602489c1fa/160/0
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: allowing update of
signer=PC-001\$\@AD.LOCAL name=pc-001.ad.local tcpaddr=192.168.0.36
type=A
key=1360-ms-7.627-584955d5.1b29d6f6-d7a6-11e9-2986-18602489c1fa/160/0
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: allowing update of
signer=PC-001\$\@AD.LOCAL name=pc-001.ad.local tcpaddr=192.168.0.36
type=A
key=1360-ms-7.627-584955d5.1b29d6f6-d7a6-11e9-2986-18602489c1fa/160/0
Oct  2 17:12:42 dc1 named[15268]: client @0x7fd0a80d5ab0
192.168.0.36#64406/key PC-001\$\@AD.LOCAL: updating zone
'ad.local/NONE': deleting rrset at 'pc-001.ad.local' 
Oct  2 17:12:42 dc1 named[15268]: client @0x7fd0a80d5ab0
192.168.0.36#64406/key PC-001\$\@AD.LOCAL: updating zone
'ad.local/NONE': deleting rrset at 'pc-001.ad.local' A
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: subtracted rdataset
pc-001.ad.local 'pc-001.ad.local.#0111200#011IN#011A#011192.168.0.36'
Oct  2 17:12:42 dc1 named[15268]: client @0x7fd0a80d5ab0
192.168.0.36#64406/key PC-001\$\@AD.LOCAL: updating zone
'ad.local/NONE': adding an RR at 'pc-001.ad.local' A 192.168.0.36
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: added rdataset
pc-001.ad.local 'pc-001.ad.local.#0111200#011IN#011A#011192.168.0.36'
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: committed transaction on
zone ad.local

При этом на ALT при переключении на SAMBA_INTERNAL обновление зон DNS
с клиентов также не работает. Хотя в логах на сервере при этом пусто
(на loglevel по умолчанию), а на клиентах - предупреждения о
невозможности обновить записи A и .

Готов предоставить дополнительную информацию или даже тестовый стенд,
хотя ничего особенного в конфигурации у меня нет. Та же ситуация
получается при чистой установке с samba-tool domain provision.

Дальнейшее наверное имеет смысл обсуждать в рамках бага в багзилле,
чтоб не захламлять рассылку логами и т.п., а сюда уже написать резюме.
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailma

Re: [Sysadmins] Обновление samba-DC 4.7.12 ->4.9.13

[Alex Moskalenko]

Evgeny Sinelnikov писал 02.10.2019 17:18:

3) "Коллеги, использующие ALT p8 или p9 с samba в качестве AD DC с
DNS-бэкэндом BIND9_DLZ, подскажите, работает ли у вас обновление 
записей

DNS клиентами Windows и samba_dnsupdate?"

Давайте определимся с критерием проверки.
- Что проверяем? Win7 в домене? или samba-клиент?
- Какие ошибки возникают при попытке обновления записей DNS?

Нужны конкретные команды, и вывод и более подробный лог ошибок. Можно
лично. Когда протестирую, перешлю уже проанализированные подробности.
Но лучше сразу сюда, просто объём может быть большим, поэтому обычно
поэтому обходятся минимальными подробностями.


Мои проблемы описаны еще в апреле в списке рассылки samba - 
https://lists.altlinux.org/pipermail/samba/2019-April/004329.html
И даже баг в багзилле заведен - 
https://bugzilla.altlinux.org/show_bug.cgi?id=36563


Проверяем безопасные обновления DNS, как с клиентов (Win10, 
Win2019Server), так и с самого DC с помощью samba_dnsupdate.
С клиентов - ipconfig /registerdns, с самого DC - samba_dnsupdate. 
Тестировал домен с 3мя DC - ALT, Ubuntu server 18.04 и Debian Buster 10. 
На текущий момент samba везде одинаковая - 4.10.8 (в ALT P9 - штатная, в 
Ubuntu - из ppa School linux, в Debian - из репозитория van-belle.nl.


Везде, кроме ALT, зоны успешно обновляются как клиентами, так и 
samba_dnsupdate. На ALT же имеем в логах записи вида:
2019-04-04T11:21:17.993406+03:00 dc0 named[14068]: client 
@0x7f01141236c0 192.168.0.11#35595/key DC0\$\@AD.LOCAL: update failed: 
not authoritative for update zone (NOTAUTH)
2019-04-04T11:21:18.017841+03:00 dc0 named[14068]: client 
@0x7f0104031eb0 192.168.0.11#48267/key DC0\$\@AD.LOCAL: update failed: 
not authoritative for update zone (NOTAUTH)


На Ubuntu и на Debian в том же AD все работает штатно:
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: starting transaction on 
zone ad.local
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: allowing update of 
signer=PC-001\$\@AD.LOCAL name=pc-001.ad.local tcpaddr=192.168.0.36 
type= 
key=1360-ms-7.627-584955d5.1b29d6f6-d7a6-11e9-2986-18602489c1fa/160/0
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: allowing update of 
signer=PC-001\$\@AD.LOCAL name=pc-001.ad.local tcpaddr=192.168.0.36 
type=A 
key=1360-ms-7.627-584955d5.1b29d6f6-d7a6-11e9-2986-18602489c1fa/160/0
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: allowing update of 
signer=PC-001\$\@AD.LOCAL name=pc-001.ad.local tcpaddr=192.168.0.36 
type=A 
key=1360-ms-7.627-584955d5.1b29d6f6-d7a6-11e9-2986-18602489c1fa/160/0
Oct  2 17:12:42 dc1 named[15268]: client @0x7fd0a80d5ab0 
192.168.0.36#64406/key PC-001\$\@AD.LOCAL: updating zone 
'ad.local/NONE': deleting rrset at 'pc-001.ad.local' 
Oct  2 17:12:42 dc1 named[15268]: client @0x7fd0a80d5ab0 
192.168.0.36#64406/key PC-001\$\@AD.LOCAL: updating zone 
'ad.local/NONE': deleting rrset at 'pc-001.ad.local' A
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: subtracted rdataset 
pc-001.ad.local 'pc-001.ad.local.#0111200#011IN#011A#011192.168.0.36'
Oct  2 17:12:42 dc1 named[15268]: client @0x7fd0a80d5ab0 
192.168.0.36#64406/key PC-001\$\@AD.LOCAL: updating zone 
'ad.local/NONE': adding an RR at 'pc-001.ad.local' A 192.168.0.36
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: added rdataset 
pc-001.ad.local 'pc-001.ad.local.#0111200#011IN#011A#011192.168.0.36'
Oct  2 17:12:42 dc1 named[15268]: samba_dlz: committed transaction on 
zone ad.local


При этом на ALT при переключении на SAMBA_INTERNAL обновление зон DNS с 
клиентов также не работает. Хотя в логах на сервере при этом пусто (на 
loglevel по умолчанию), а на клиентах - предупреждения о невозможности 
обновить записи A и .


Готов предоставить дополнительную информацию или даже тестовый стенд, 
хотя ничего особенного в конфигурации у меня нет. Та же ситуация 
получается при чистой установке с samba-tool domain provision.


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

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Обновление samba-DC 4.7.12 ->4.9.13

[Alex Moskalenko]

01.10.2019 22:12, so...@shpl.ru пишет:

Коллеги, что можно сделать в такой ситуации:
Обновил контроллеры домена samba-DC до актуальной через
apt-get update && apt-get dist-upgrade.

Обнаружилось, что зоны не обновляются

Появляется вот такое сообщение например от samba_upgradedns
=
db: unable to dlopen /usr/lib64/ldb/modules/ldb/ldbsamba_extensions.so
: /usr/lib64/samba-dc/libgensec-samba4.so: version `SAMBA_4.7.12' not
found (required by /usr/lib64/ldb/modules/ldb/ldbsamba_extensions.so)
===


Здравствуйте.

Для начала остановите самбу и выполните ldconfig от рута. Затем можно 
перезагрузить машину для пущей уверенности, что все штатно запустится 
само. Ситуация очень напоминает апгрейд p8->p9, после которого samba 
тоже не стартует с похожими симптомами.


Если не помогло - запустите rpm -Va и просмотрите вывод - не побилось ли 
чего.


PS Коллеги, использующие ALT p8 или p9 с samba в качестве AD DC с 
DNS-бэкэндом BIND9_DLZ, подскажите, работает ли у вас обновление записей 
DNS клиентами Windows и samba_dnsupdate? У меня не работает ни то, ни 
другое, при этом в том же AD с теми же настройками и версией samba на 
Ubuntu все работает прекрасно. Хотел бы везде использовать ALT, но 
динамическое обновление DNS победить не могу.



___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] rsyslogd

[Alex Moskalenko]

Yandex писал 19.09.2019 14:53:

Да, так действительно вывод идёт в традиционном формате. Другое дело,
что формат "YYY-MMM-DD HH;mm:ss +03" мне даже больше нравится, но
буква T между датой и временем и куча лишних знаков после запятой в
секундах делает всё очень плохо читаемым глазами.
Так когда стало понятно, почему не отрабатывает задание шаблона, можете 
написать свой шаблон 
(https://www.rsyslog.com/doc/v8-stable/configuration/templates.html) без 
секунд и буквы Т и использовать его.




Кстати, при перезапуске rsyslogd вновя создаётся 00_extrasockets.conf,
идентичный 20_extrasockets.conf, но на формат вывода это уже не
влияет.
Этот файл переименовывать/менять бесполезно - он автоматически создается 
при старте rsyslog Имя файла захардкодено в /etc/rc.d/init.d/rsyslogd. 
Нужно его править в пакете.



___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] p9, zabbix34-agent и system.cpu.util[]

[Alex Moskalenko]

Здравствуйте.

Обнаружил, что zabbix43-agent из p9 отдает все значения 
system.cpu.util[] нулевыми. На p8 c zabbix-agent 3.0.26 значения 
отдаются корректно. Пример:


[zabbix@zabbix ~]$ for i in host-p9 host-p8; do echo -n "$i: version="; 
zabbix_get -s $i -k "agent.version"; for p in idle user system iowait; 
do echo -n "$i: system.cpu.util.[,$p]="; zabbix_get -s $i -k 
"system.cpu.util[,$p]"; done; done

host-p9: version=3.4.15
host-p9: system.cpu.util.[,idle]=0.00
host-p9: system.cpu.util.[,user]=0.00
host-p9: system.cpu.util.[,system]=0.00
host-p9: system.cpu.util.[,iowait]=0.00
host-p8: version=3.0.26
host-p8: system.cpu.util.[,idle]=99.216209
host-p8: system.cpu.util.[,user]=0.266822
host-p8: system.cpu.util.[,system]=0.491954
host-p8: system.cpu.util.[,iowait]=0.016676

Никто не сталкивался с таким? Что это может быть?


--
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] rsyslogd

[Alex Moskalenko]

Alex Moskalenko писал 19.09.2019 10:11:

Багу вешать?


Багу повесил (https://bugzilla.altlinux.org/show_bug.cgi?id=37239).

Еще в 00_common.conf закомментирована строка module(load="imklog")# 
provides kernel logging support (previously done by rklogd)

Без нее сообщения ядра в логи не попадают.
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] rsyslogd

[Alex Moskalenko]

Vladimir Karpinsky писал 18.09.2019 22:07:

После обновления с p8 до p9 и переходе на rsyslogd сообщения в
/var/log/messages стали приходить с датой следующего вида:
2019-09-18T18:01:01.736395+00:00

Можно ли как-то отредактировать формат? Нашёл пару рецептов, но не вижу 
эффекта.


Здравствуйте.

А тут похоже проблема в порядке загрузки файлов из /etc/rsyslog.d.

Я пытался поменять формат таймстампов на традиционный, используемый 
syslogd (с новым форматом сломался pflogsumm). Обнаружил, что в 
00_common.conf уже есть строка module(load="builtin:omfile" 
Template="RSYSLOG_TraditionalFileFormat"), которая по идее должна делать 
именно это. Но нет - таймстампы в логах "точные" и с таймзоной.



После экспериментов выяснилось, rsyslog грузит файлы из этого каталога в 
алфавитном порядке, поэтому сначала загружается 00_classic.conf (на этом 
этапе настройки формата по умолчанию еще не изменены), а затем 
00_common.conf и 00_extrasockets.conf.


При этом файл 00_extrasockets.conf пересоздается каждый раз при 
перезапуске rsyslogd, поэтому переименовать его нельзя. И он обязательно 
должен грузиться после 00_classic.conf, где загружается модуль imuxsock, 
требующийся для создания сокетов из 00_extrasockets.conf.


На мой взгляд, сделать нужно следующее.

1. 00_classic.conf переименовать в например 10_classic.conf
2. 00_extrasockets.conf переименовать в например 20_extrasockets.conf

Тогда сначала отработает 00_common.conf, устанавливающий умолчания, 
затем 10_classic.conf, загружающий imuxsock, а затем 
20_extrasockets.conf, создающйи дополнительный сокеты.


Багу вешать?

---
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] p9, SysVinit, network и syslog

[Alex Moskalenko]

Здравствуйте. 

После обновления системы на sysVinit с p8 на p9 обнаружил следующую
странность. 

В файле /etc/rc.d/init.d/network прописано chkconfig: 345 11 90 и
Should-Start: $syslog. 

Службы, предоставляющие syslog (это syslog-ng и rsyslog, который
заменяет использовавшийся в p8 syslogd) запускаются с приоритетом 30
(chkconfig: 2345 30 99). 

Из-за этого запуск службы network происходит с приоритетом 31 (после
syslog), а не с приоритетом 10. Это позже, чем службы, которые
используют сеть (например, bind - 20, netfs - 25). В результате службы
не могут привязаться к заданным адресам (интерфейсов-то еще нет), да и
сам rsyslog ругается из-за отсутствия сети (используется отсылка логов
на другую машину). 

Как правильно разрешить эту ситуацию? У себя я удалил строку
Should-Start: $syslog из /etc/rc.d/init.d/network. И на кого лучше
повесить багу - на etcnet или на {r}syslog{-ng}? 

-- 
WBR, Alex Moskalenko___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] p8 -> p9

[Alex Moskalenko]

Также наткнулся на то, что входящий в p9 zabbix-agent 4.0 не умеет
общаться со старыми серверами zabbix (2.4). Установил zabbix_agent из
p8.


Для этого случая в p9 и Сизифе специально собирается zabbix34-agent


Спасибо, не заметил пакета zabbix34-agent. С ним все работает штатно.
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] p8 -> p9

[Alex Moskalenko]

Vladimir Karpinsky писал 03.09.2019 20:37:

03.09.2019 19:51, Vladimir Karpinsky пишет:

Пытаюсь обновиться.

2. Не стартует Самба:
Starting Samba SMB/CIFS Server service: /usr/sbin/smbd: error while 
loading shared libraries: libnsl.so.2: cannot open shared object file: 
No such file or directory


Эта проблема сама отпала после обновления ядра и перезагрузки...


Здравствуйте.

Сам наткнулся на такое. Эта проблема исправляется запуском ldconfig. 
Видимо, postinstall-скрипты отрабатывают не очень правильно.


Также наткнулся на то, что входящий в p9 zabbix-agent 4.0 не умеет 
общаться со старыми серверами zabbix (2.4). Установил zabbix_agent из 
p8.

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] dhcpd и chroot

[Alex Moskalenko]

Evgeny Sinelnikov писал 03.04.2019 21:20:

Я такой ручки не помнил, но глянул в исходники, обнаружил опцию -j
Видимо, это ручка выглядит так:
DHCPDARGS="-j /"
в /etc/sysconfig/dhcpd
Спасибо, "ручка" сработала с дополнением в виде "-lf 
/var/lib/dhcp/dhcpd/state/dhcpd.leases".


Итоговый вид /etc/sysconfig/dhcpd:
DHCPDARGS="-j / -lf /var/lib/dhcp/dhcpd/state/dhcpd.leases"

В будущем вполне можно сделать control по аналогии с bind-chroot - 
действия требуются практически такие же.


Еще раз спасибо!

PS Правда, реализовать обновление DNS пока не получилось - см. 
https://lists.altlinux.org/pipermail/samba/2019-April/004329.html Но это 
уже не к dhcpd.

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] dhcpd и chroot

[Alex Moskalenko]

Evgeny Sinelnikov писал 03.04.2019 21:37:

ср, 3 апр. 2019 г. в 22:20, Evgeny Sinelnikov :
Вообще, я тут подумал и припомнил вот такой инструмент:
[sin@xpi dhcp]$ net ads dns
Invalid command: net ads dns
Usage:
net ads dns registerAdd host dns entry to AD
net ads dns unregister  Remove host dns entry from AD
net ads dns gethostbyname   Look up host

Обновлять DNS-записи в домене - это не задача dhcp-сервера. Это задача
самого клиента. Клиент обращается со своими учётными данными (точнее
компьютер обращается со своими учётными данными в /etc/krb5.keytab) и
сам обновляет свои DNS-записи. Так оно задумано и все инструменты для
это имеются. Их можно хуками на dhcp-клиенте прописать.


Это все очень правильно, но, к сожалению, реализуемо только для клиентов 
Windows (встроено в DNS-клиент) и UNIX (как Вы написали). В моей сети, 
помимо компьютеров, есть МФУ, к которым тоже хочется обращаться по 
имени. Они не являются членами AD и не умеют сами обновлять DNS.


Вообще, структура у меня следующая. Сегмент /24, в нем классический NT4 
домен. Серверы - linux, клиенты - Windows и Linux, присутствуют 
принт-серверы и МФУ. Сегмент обслуживается DHCP и DNS-серверами, записи 
DNS обновляет сервер DHCP. Регистрация DNS-имен на клиентах отключена.

Задача - перевести домен NT4 на AD с помощью classicupgrade.

Рассматривал 3 варианта.
1. Перенос AD в поддомен основного домена. Прямая DNS-зона для AD будет 
обслуживаться самбой+BIND_DLZ, клиенты будут динамически в ней 
регистрироваться штатными средствами. Для обслуживания обратной зоны 
придется, и отдачи разных доменных имен по DHCP придется городить 
костыли для dhcpd - машины Windows и Linux в домен AD, остальное в 
родительский домен. Показалось слишком сложным и непонятным, к тому же 
возможны проблемы с классификацией клиентов DHCP.
2. Classicupgrade в существующей доменной зоне со штатными средствами 
для обновления DNS. Требует ручной регистрации в DNS всех МФУ. В 
дальнейшем потребуется отслеживание актуальности сопоставления имен МФУ 
адресам, либо фиксация адресов для МФУ в конфигурации dhcpd, либо ручная 
настройка параметров IP в МФУ. Не понравилась по причине присутствия 
ручной работы.
3. Classicupgrade в существующей доменной зоне с автоматическим 
обновлением DNS с сервера DHCP. Требует донастройки dhcpd, но работает 
гораздо более логично, чем вариант (1) и не имеет возможных проблем с 
классификацией клиентов по варианту (1).


В результате остановился на варианте (3). Возможно, есть более логичные 
решения, и очень хотелось бы с ними ознакомиться. Пока все происходит в 
песочнице, и эксперименты приветствуются. :)

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] dhcpd и chroot

[Alex Moskalenko]

Здравствуйте!

Подскажите пожалуйста, нельзя ли наш dhcpd "вынуть" из чрута по аналогии 
с текущим bind (что-то типа control dhcpd-chroot disabled)? Есть у нас 
такая возможность?


Захотелось попробовать реализовать обновление DNS на контроллере AD по 
мотивам 
https://wiki.samba.org/index.php/Configure_DHCP_to_update_DNS_records_with_BIND9, 
но, получается или dhcpd из чрута нужно вынимать, или ему в chroot 
копировать библиотеки от используемых в скрипте программ (скрипт конечно 
можно упростить, но от sh/kinit/klist/nsupdate/awk не деться никуда).


Может есть какая не очень заметная "ручка" для dhcpd?


--
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] P8 sysvinit: multipath и open-iscsi - порядок запуска и PID-файлы

[Alex Moskalenko]

04.09.2018 14:51, Michael Shigorin пишет:

On Thu, Aug 23, 2018 at 09:40:26AM +0300, Alex Moskalenko wrote:

На любого, главное -- поставьте на всякий в копию
shaba@ (и можно меня): он их оба нынче собирает.

В сизифе то же самое, поэтому повесил на пакеты из него.

По поводу PID - #35286
По поводу порядка запуска - #35287

Вчера вышел из отпуска и наконец добрался; спасибо!


Спасибо!


Хотелось бы, чтобы  в p8 эти изменения тоже попали.

--
WBR, Alex Moskalenko

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Запуск текущего P8 с ядром ovz-el

[Alex Moskalenko]

В Thu, 23 Aug 2018 10:44:58 +0300
Сергей пишет:

> В чём смысл  временной замены ядра на Сизифное?
> 
> Не связывался с Сизифом ранее.
> 
> В какой момент обновлять ядро?
> 
> Обновить существующее ядро P7->Сизиф?
> 
> В Сизифе вижу два ядра
> 
> http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/x86_64/RPMS.classic/kernel-image-ovz-el-2.6.32-alt162.x86_64.rpm
> 
> а сейчас стоит
> 2.6.32-ovz-el-alt152 #1 SMP Thu May 18 17:15:52 UTC 2017 x86_64
> GNU/Linuxи
> 
> http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/x86_64/RPMS.classic/kernel-image-ovz-el7-3.10.0-alt2.693.17.1.vz7.45.7.x86_64.rpm
> 
> Это поновее, но не факт что на старом сервере заработает.
> 
> По процедуре: надо apt-repo натравить на Сизиф и сделать
> update-kernel?
Смысл использования ядра из сизифа в том, только в нем есть syscall
prlimit64, без которого текущий сизиф (а значит и следующие бранчи)
вообще работать не смогут, в том числе и в контейнерах. Также оно
основано на более поздней (но, к сожалению, тоже не последней) сборке
оригинального OVZ-ядра, а в ней много чего интересного исправлено.

С openVZ использовать получится только ovz-el. ovz-el7 у меня не
заработало (контейнеры не стартуют, venet не создается).

Можете скачать нужный(е) rpm с packages.altlinux.org (посмотрите, что у
Вас стоит из модулей для текущего ядра), а потом установить его
через apt-get install /path/to/downloaded_package.rpm. Тогда не надо
нацеливать apt на сизиф.

Обновлять ядро лучше после последнего dist-upgrade системы - тогда в
initrd попадут актуальные версии файлов. Проблем в функционировании
текущего p8 даже на древнем ядре из p7 (что-то типа alt126 было) я не
обнаружил. С alt152 точно будет работать.
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] P8 sysvinit: multipath и open-iscsi - порядок запуска и PID-файлы

[Alex Moskalenko]

В Tue, 21 Aug 2018 17:15:59 +0300
Michael Shigorin  пишет:

> На любого, главное -- поставьте на всякий в копию
> shaba@ (и можно меня): он их оба нынче собирает.

В сизифе то же самое, поэтому повесил на пакеты из него.

По поводу PID - #35286
По поводу порядка запуска - #35287
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Запуск текущего P8 с ядром ovz-el

[Alex Moskalenko]

В Wed, 22 Aug 2018 11:52:32 +0300
Сергей  пишет:

> Теперь надо придумать, как в процессе upgrade правильный udev
> подсунуть ( он у меня есть на сервере, который до отпуска апрейдил)
> 
> Правильно ли будет
> 1. поставить  udev на hold в apt,
> 2. dist-upgrade
> 3. поставить udev-233 через rpm (а что он тянет за собой?)
> 4. перезагрузить и искать  другие грабли.

Я делал следующим образом:

1. apt-repo rm all

2. Добавил в sources.list архив P8 от 03.04.2018
rpm [updates]
http://ftp.altlinux.org/pub/distributions/archive/p8/date/2018/04/03
x86_64 classic
rpm [updates]
http://ftp.altlinux.org/pub/distributions/archive/p8/date/2018/04/03
x86_64-i586 classic
rpm [updates]
http://ftp.altlinux.org/pub/distributions/archive/p8/date/2018/04/03
noarch classic

3. dist-upgrade

4. Поставил udev и systemd на холд
RPM::Hold {
"^udev.*";
"^libudev.*";
"^libsystemd.*";
"^systemd.*";
};

5. apt-repo rm all; apt-repo add p8
6. dist-upgrade
7. update-kernel

После этого имеем текущий p8 с последним рабочим udev-233.
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Периодические падения dovecot-auth и ntlm_auth - P8

[Alex Moskalenko]

24.07.2018 15:18, Sergey V Turchin пишет:

Попробуйте http://git.altlinux.org/tasks/210566/


Спасибо. Установил, буду смотреть. Ошибка в auth-worker появляется 
нечасто и в основном под нагрузкой, поэтому нужно время для 
тестирования. На ошибки ntlm_auth это вряд ли повлияет - тут вопросы к 
самбе.


С новым dovecot-2.2.36-alt0.M80P.1 вылезла новая ошибка в логе:
Jul 24 22:15:12 mail dovecot: lmtp(user@host): Error: 
open(/proc/self/io) failed: Permission denied
Jul 24 22:17:12 mail dovecot: lmtp(user@host): Error: 
open(/proc/self/io) failed: Permission denied
Jul 24 22:17:12 mail dovecot: lmtp(user@host): Error: 
open(/proc/self/io) failed: Permission denied


Виноват в этом используемый плагин stats. На доставку почты сообщение не 
влияет, дабы не засорять логи плагин отключил.


Вообще, права на /proc/$PID/io 400 root:root для любого процесса, так 
что непонятно, что можно настроить для того, чтобы процессы dovecot, 
выполняющиеся из-под vmail, получили к нему доступ. Разве что это 
очередной баг?


___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Загрузка ALT Linux Rescue по PXE

[Alex Moskalenko]

В Tue, 10 Apr 2018 16:01:14 +0200
Konstantin Lepikhov  пишет:

> Подпишитесь на https://bugzilla.altlinux.org/show_bug.cgi?id=34347 и
> запаситесь попкорном. Похоже, вы не одиноки с этой проблемой.
> 

Подписался и добавил ссылку на наше обсуждение. Спасибо!

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Загрузка ALT Linux Rescue по PXE

[Alex Moskalenko]

В Tue, 10 Apr 2018 14:57:35 +0200
Konstantin Lepikhov  пишет:

> Hi Alex!
> 
> On 04/10/2018, at 03:44:55 PM you wrote:
> 
> > В Tue, 10 Apr 2018 14:29:41 +0200
> > Konstantin Lepikhov  пишет:
> >   
> > > propagator запускает udev перед собственно поиском устройств, т.е.
> > > если карта там не обнаружилась, то в dmesg должно быть что-то.
> > > Есть ли еще сообщения на других консолях?
> > >   
> > 
> > Сразу после сообщения "No network device found" переключаюсь на
> > вторую консоль (оболочка). lsmod - пусто. ls /sys/class/net - lo.
> > udevd --resolve-names=never в процессах присутствует. На 4й консоли
> > - обычный лог загрузки ядра, никаких попыток загрузить какие-либо
> > модули не наблюдается.
> > 
> > Если на второй консоли в шелле выполнить udevadm trigger
> > --action=add, то загружаются модули для найденных устройств, в том
> > числе и сетевой карты, появляется /sys/class/net/eth0 и propagator
> > продолжает свою работу (поднимает eth0, получает ip, загружает
> > stage2), правда, в ручном режиме.
> > 
> > Может, нужно куда-нибудь вставить этот самый udevadm trigger
> > --action=add?...  
> 
> Хм, интересно:
> 
> [lakostis@lks propagator]$ git grep udevtrigger_add
> cdrom.c:extern char *udevtrigger_add[];
> cdrom.c:spawn(udevtrigger_add);
> disk.c:extern char *udevtrigger_add[];
> disk.c: spawn(udevtrigger_add);
> init.c:char *udevtrigger_add[] = {"/sbin/udevadm", "udevadm",
> "trigger", "--action=add", NULL};
> 
> [lakostis@lks propagator]$ git grep udevtrigger
> init.c:char *udevtrigger[] = {"/sbin/udevadm", "udevadm", "trigger",
> NULL}; init.c: if (waitpid(spawn(udevtrigger), _status, 0) < 0 ||
> init.c: warn("udevtrigger");
> 
> т.е. propagator при загрузке дергает udevadm trigger на ранней стадии,
> далее trigger --action=add дергается только для методов disk и cdrom.
> Наверное, это баг, и стоит добавить udevtrigger_add для метода
> network?
> 
> PS все мои познания propagator основаны опыте 10ти-летней давности,
> так что я никак не разработчик этой программы )
> 

Ну я тут точно не помогу, так как у меня познания по "внутренностям"
propagator'а просто отсутствуют. :) Разве что баг могу повесить.

Хотя терзают меня сомнения - неужели никто не пытался
установить/загрузить liveCD ALT Linux по сети? Ведь это должно
обязательно вылезти при установке! Может, все-таки что-то не так у меня?
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Загрузка ALT Linux Rescue по PXE

[Alex Moskalenko]

В Tue, 10 Apr 2018 14:29:41 +0200
Konstantin Lepikhov  пишет:

> propagator запускает udev перед собственно поиском устройств, т.е.
> если карта там не обнаружилась, то в dmesg должно быть что-то. Есть
> ли еще сообщения на других консолях?
> 

Сразу после сообщения "No network device found" переключаюсь на вторую
консоль (оболочка). lsmod - пусто. ls /sys/class/net - lo. udevd
--resolve-names=never в процессах присутствует. На 4й консоли - обычный
лог загрузки ядра, никаких попыток загрузить какие-либо модули не
наблюдается.

Если на второй консоли в шелле выполнить udevadm trigger --action=add,
то загружаются модули для найденных устройств, в том числе и сетевой
карты, появляется /sys/class/net/eth0 и propagator продолжает свою
работу (поднимает eth0, получает ip, загружает stage2), правда, в
ручном режиме.

Может, нужно куда-нибудь вставить этот самый udevadm trigger
--action=add?...
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Загрузка ALT Linux Rescue по PXE

[Alex Moskalenko]

В Tue, 10 Apr 2018 11:15:13 +0200
Konstantin Lepikhov  пишет:

> > На текущий момент положил vmlinuz и full.cz (с добавленными модулями
> > для поддержки сетевых карт) на tftp-сервер, образ rescue - на
> > ftp-сервер, прописал в pxelinux.cfg соответствующие параметры
> > (fastboot live
> > automatic=method:ftp,network:dhcp,server:192.168.1.1,directory:/rescue/32
> > ramdisk_size=45 stagename=rescue showopts). Начинается загрузка,
> > которая останавливается на сообщении "No network device found".
> > Переход на вторую консоль и выполнение там udevadm trigger
> > --action=add; udevadm settle подгружает модуль для сетевой карты,
> > после чего можно продолжить загрузку (rescue скачивается с ftp и
> > далее все загружается обычным образом).
> > 
> > Никак не могу понять, каким образом заставить
> > udev/propagator/кто-этим-должен-заниматься загружать модули для
> > сетевой карты автоматически.  
> Насколько я помню, propagator все делает сам, и если имя сетевого
> интерфейса не совпадает с ожидаемым, то он выкидывает эту ошибку.
> Посмотрите отладочную консоль, там должно быть все написано что ему не
> нравится.
> 

На 3й консоли есть следующее:
* welcome to the ALT Linux install(alt-stage1, built ...)
* opening /proc/cmdline...
*   initrd=. (строка APPEND из pxelinux)
* AUTOMATIC MODE: got 4 params
*  got 8 args
* spawning a shell
* unsetting automatic

Похоже, все ему нравится, просто модуля для сетевой карты никто не
загружает. Интерфейс только lo. lsmod - пусто. После ручной загрузки
модуля (через вторую консоль с шеллом) и нажатия Ok в propagator у него
все получается - поднимается интерфейс, получается IP, загружается по
FTP образ и т.д.

Никак не могу понять, как и кого попросить грузить модуль для сетевой
карты. Все нужное в initrd есть - модули, udev.
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] Загрузка ALT Linux Rescue по PXE

[Alex Moskalenko]

Здравствуйте!

Подскажите пожалуйста, как правильно грузить Rescue по PXE?

На текущий момент положил vmlinuz и full.cz (с добавленными модулями
для поддержки сетевых карт) на tftp-сервер, образ rescue - на
ftp-сервер, прописал в pxelinux.cfg соответствующие параметры
(fastboot live
automatic=method:ftp,network:dhcp,server:192.168.1.1,directory:/rescue/32
ramdisk_size=45 stagename=rescue showopts). Начинается загрузка,
которая останавливается на сообщении "No network device found". Переход
на вторую консоль и выполнение там udevadm trigger --action=add; udevadm
settle подгружает модуль для сетевой карты, после чего можно продолжить
загрузку (rescue скачивается с ftp и далее все загружается обычным
образом).

Никак не могу понять, каким образом заставить
udev/propagator/кто-этим-должен-заниматься загружать модули для сетевой
карты автоматически.

Как правильно организовать загрузку?
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Обновление сервера p7->p8

[Alex Moskalenko]

Здравствуйте.

У меня не поднимались сетевые интерфейсы на p8 с ядрами 2.6.32-ovz-el. 
Проблема похоже в несовместимости этих ядер и новых версий ip.


В etcnet используются конструкции вида $IP -o link show dev $NAME для 
определения состояния интерфейса, но на ядвах 2.6.32 они возвращают 
invalid argument. при этом ip -o link show (без указания устройства) 
отрабатывает штатно.


Для себя я проблему решил прaвкой файла /etc/net/scripts/functions:

--- functions.orig 2016-09-23 18:13:41.0 +0300 +++ functions 
2016-06-19 10:37:52.0 +0300 @@ -220,7 +220,8 @@ iface_is_up() { 
local NAME=${1:?missing 1st argument to $FUNCNAME} - $IP -o link show 
dev $NAME 2>/dev/null | cut -d' ' -f3 | grep -qs '[<,]UP[,>]' +# $IP -o 
link show dev $NAME 2>/dev/null | cut -d' ' -f3 | grep -qs '[<,]UP[,>]' 
//mav: does not working on this kernel + $IP -o link show 2>/dev/null | 
grep ": $NAME: " | cut -d' ' -f3 | grep -qs '[<,]UP[,>]' } # Invoke 
program which understands the "-o NAME" option - @@ -427,7 +428,8 @@ 
iface_exists() { local NAME=${1:?missing 1st argument to $FUNCNAME} - 
$IP li sh dev $NAME >/dev/null 2>&1 +# $IP li sh dev $NAME >/dev/null 
2>&1 //mav: not working on current kernel + $IP -o li sh | grep ": 
$NAME:" >/dev/null 2>&1 } seen_iface ()


Возможно, у Вас та же проблема.

WBR, Alex Moskalenko

23.09.2016 18:04, Соломонов Сергей пишет:


Здравствуйте!

Обновлял сервер. Некогда обновлённый с p6 до P7

Обновления пакетов прошли.

Обновил ядро до

2.6.32-el-smp-alt31

После перезагрузки не поднялись ip.

То есть интерфейсы есть и на местах, а ip нет.

Eсли задать вручную, например через ifconfig, то ОК.

Вопрос, что мешает поднять ip при старте?

Пробовал ядро std-def.

Сервер уходит в перезагрузку после долгого размышления.Кстати это у 
него с ядрами старше 2.6 наблюдается.


--

С уважением,

Соломонов Сергей

Государственная публичная историческая библиотека России



___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins


___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] Asterisk+Voicemail+IMAP

[Alex Moskalenko]

Здравствуйте!

Есть ли у нас люди, использовавшие Asterisk+VoiceMail с хранением 
сообщений в папках IMAP? В наших пакетах варианта app_voicemail с 
поддержкой IMAP Storage нет совсем, но самостоятельно собрать его 
получилось и оно с виду даже работает. Хотелось бы услышать мнение 
опытных астерисководов и майнтейнеров в следующих вопросах:


- Насколько жизнеспособна голосовая почта с сообщениями в IMAP? 
Настораживает использование uw-imap c-client toolkit (похоже мертвого 
совсем) и наличие некоторого количества открытых багов в багзилле астериска;
- Есть ли противопоказания к сборке пакета app_voicemail_imap в 
дополнение к обычному app_voicemail? Переключаться между ними можно, 
например, альтернативами, а сборка исправляется добавлением -lssl 
-lcrypto -lpam к опциям сборки и подсовыванием папки с последним 
доступным uw-imap. С системным uw-imap-devel тоже собирается, но и 
использовать как-то страшно - уж очень он древний, и линкуется с ним 
app_voicemail статически, не используя никаких библиотек.


--
WBR, Alex Moskalenko

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Расчет загрузки софтового raid`а

[Alex Moskalenko]

01.09.2014 16:57, Alexandr ANDREEV пишет:

к примеры имею сервачек с 10 ГБитным линком, и корзиной на 20 и 40 HDD
настроен раздел raid6+1(HotSpare) -
Но на выходе скорость - 10 МБит/сек - что как-бы не совсем
соответствует ожиданиям.

Здравствуйте.

А что у Вас при этом происходит с системой? В каком состоянии массив 
(cat /proc/mdstat), насколько и чем загружена система (top, atop, dstat 
и им подобные)? Посмотрите загрузку (скоросто обмена) дисков массива и 
загрузку ядер процессора и Load Average системы реальном времени (dstat 
например). Если LA/загрузка CPU высокие - посмотреть кем именно. Если 
все упирается в дисковый ввод/вывод - возможно, не выровнены 
разделы/границы блоков массива относительно границ физических секторов 
дисков.


Можно результаты сюда.

PS Вообще RAID5/6 довольно тяжелы при активной записи. Может быть, имеет 
смысл рассмотреть RAID10?


--
WBR, Alex Moskalenko

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Многопортовый последовательный адаптер в P5

[Alex Moskalenko]

А параметр 8250.nr_uarts=16 (как пример, или сколько Вам требуется 
портов) не забыли добавить в опции загрузки ядра (cat /proc/cmdline)? По 
умолчанию включены 4 порта, и все они заняты стандартными com-портами 
(даже если их физически нет).



24.06.2014 00:02, А. Куликовский пишет:

23.06.2014 20:36, Sergey пишет:

On Monday 23 June 2014, А. Куликовский wrote:

Долгие годы на старом тазике под ALT Linux 2.4 трудился вот такой 
девайс:

# lspci
04:02.0 Serial controller: Titan Electronics Inc VScom 400H 4 port
serial adaptor



http://cateee.net/lkddb/web-lkddb/SERIAL_8250.html

vendor: 14d2 (Titan Electronics Inc), device: a003 (VScom 400H 4 
port serial adaptor)


Похож ?


Оно самое!
В ALM2.4 (ядро 2.4.26) драйвер вкомпилирован - нашел строки в 
/proc/kсore, а в p5 (ядро 2.6.27) как будто нет.
Пробовал в p5 загружать модули 8250_* (их там 5 шт.), но устройств 
ttyS4 и т.д. как не было так и нет.

Значит придётся поднимать ALM2.4...




--
WBR, Alex Moskalenko

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] P7, OpenVZ, Samba 4.0.5

[Alex Moskalenko]

) [0x7f50a0be4cfd]
   #18 /usr/lib64/samba/libsmbd_base.so(smbd_process+0xc21) 
[0x7f50a33088f1]

   #19 /usr/sbin/smbd() [0x409de4]
   #20 /usr/lib64/libsmbconf.so.0(run_events_poll+0x187) [0x7f50a21e3637]
   #21 /usr/lib64/libsmbconf.so.0(+0x448b9) [0x7f50a21e38b9]
   #22 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7f50a0be4cfd]
   #23 /usr/sbin/smbd(main+0x1385) [0x406995]
   #24 /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f50a0852ad5]
   #25 /usr/sbin/smbd() [0x406d2d]
[2013/10/09 18:58:28.892421,  0] ../source3/lib/dumpcore.c:317(dump_core)
  dumping core in /var/log/samba/cores/smbd
[2013/10/09 18:58:29.061172,  0] ../lib/tdb_wrap/tdb_wrap.c:64(tdb_wrap_log)
  tdb(/var/lib/samba/locking.tdb): tdb_rec_read bad magic 0x42424242 at 
offset=6718024

[2013/10/09 18:58:29.072362,  0] ../lib/tdb_wrap/tdb_wrap.c:64(tdb_wrap_log)
  tdb(/var/lib/samba/locking.tdb): tdb_rec_read bad magic 0x42424242 at 
offset=6718024

[2013/10/09 18:58:29.072463,  0] ../lib/tdb_wrap/tdb_wrap.c:64(tdb_wrap_log)
  tdb(/var/lib/samba/locking.tdb): tdb_rec_read bad magic 0x42424242 at 
offset=6718024

[2013/10/09 18:58:29.072545,  0] ../lib/tdb_wrap/tdb_wrap.c:64(tdb_wrap_log)
  tdb(/var/lib/samba/locking.tdb): tdb_rec_read bad magic 0x42424242 at 
offset=6718024

[2013/10/09 18:58:29.072615,  0] ../lib/tdb_wrap/tdb_wrap.c:64(tdb_wrap_log)
  tdb(/var/lib/samba/locking.tdb): tdb_rec_read bad magic 0x42424242 at 
offset=6718024

[2013/10/09 18:58:29.072688,  0] ../lib/tdb_wrap/tdb_wrap.c:64(tdb_wrap_log)
  tdb(/var/lib/samba/locking.tdb): tdb_rec_read bad magic 0x42424242 at 
offset=6718024
[2013/10/09 18:58:29.072766,  0] 
../source3/locking/share_mode_lock.c:224(share_mode_data_destructor)

  store returned NT_STATUS_UNSUCCESSFUL
[2013/10/09 18:58:29.072862,  0] ../source3/lib/util.c:810(smb_panic_s3)
  PANIC (pid 5036): could not store share mode entry: 
NT_STATUS_UNSUCCESSFUL

[2013/10/09 18:58:29.073787,  0] ../source3/lib/util.c:921(log_stack_trace)
  BACKTRACE: 26 stack frames:
   #0 /usr/lib64/libsmbconf.so.0(log_stack_trace+0x1a) [0x7f50a21c46ca]
   #1 /usr/lib64/libsmbconf.so.0(smb_panic_s3+0x20) [0x7f50a21c47a0]
   #2 /usr/lib64/libsamba-util.so.0(smb_panic+0x2f) [0x7f50a36ff0bf]
   #3 /usr/lib64/samba/libsmbd_base.so(+0x18faa0) [0x7f50a336daa0]
   #4 /usr/lib64/libtalloc.so.2(+0x7b49) [0x7f50a0df5b49]
   #5 /usr/lib64/libtalloc.so.2(_talloc_free+0x1d5) [0x7f50a0df15d5]
   #6 /usr/lib64/samba/libsmbd_base.so(+0x10b727) [0x7f50a32e9727]
   #7 /usr/lib64/samba/libsmbd_base.so(+0x10e1de) [0x7f50a32ec1de]
   #8 /usr/lib64/samba/libsmbd_base.so(create_file_default+0x20a) 
[0x7f50a32ed16a]

   #9 /usr/lib64/samba/libsmbd_base.so(+0x1db43b) [0x7f50a33b943b]
   #10 /usr/lib64/samba/libsmbd_base.so(smb_vfs_call_create_file+0xa5) 
[0x7f50a32f3ae5]
   #11 /usr/lib64/samba/libsmbd_base.so(reply_ntcreate_and_X+0x3c6) 
[0x7f50a32b09f6]

   #12 /usr/lib64/samba/libsmbd_base.so(+0x127ed1) [0x7f50a3305ed1]
   #13 /usr/lib64/samba/libsmbd_base.so(+0x128fa0) [0x7f50a3306fa0]
   #14 /usr/lib64/samba/libsmbd_base.so(+0x129438) [0x7f50a3307438]
   #15 /usr/lib64/libsmbconf.so.0(run_events_poll+0x187) [0x7f50a21e3637]
   #16 /usr/lib64/libsmbconf.so.0(+0x448b9) [0x7f50a21e38b9]
   #17 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7f50a0be4cfd]
   #18 /usr/lib64/samba/libsmbd_base.so(smbd_process+0xc21) 
[0x7f50a33088f1]

   #19 /usr/sbin/smbd() [0x409de4]
   #20 /usr/lib64/libsmbconf.so.0(run_events_poll+0x187) [0x7f50a21e3637]
   #21 /usr/lib64/libsmbconf.so.0(+0x448b9) [0x7f50a21e38b9]
   #22 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x9d) [0x7f50a0be4cfd]
   #23 /usr/sbin/smbd(main+0x1385) [0x406995]
   #24 /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f50a0852ad5]
   #25 /usr/sbin/smbd() [0x406d2d]
[2013/10/09 18:58:29.074735,  0] ../source3/lib/dumpcore.c:317(dump_core)
  dumping core in /var/log/samba/cores/smbd

Лечится удалением разрушенных файлов и перезапуском smbd.

2. В 4.0.5 из p7 все еще жива проблема из моего бага 
https://bugzilla.altlinux.org/show_bug.cgi?id=26182. То есть 
использование кириллицы в имени принтера (именно в имени) приводит к 
отказу подсистему печати. Лечится правкой реестра на сервере samba - 
удалением кариллицы из имени.


Прошу помощи в подтверждении и/или решении этих проблем. Проблема (1) 
жить не дает совсем, проблему (2) можно обойти, не используя кириллицу в 
имени принтера.


PS Возможно, в p7 есть смысл положить новые версии samba (4.0.5 - 
4.0.10) и/или ядра ovz-el (alt102 - alt104)? Ядро в целом и 
ovz-контейнер в частности вообще может влиять на поведение подсистемы 
tdb в samba?


--
WBR, Alex Moskalenko

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] OpenVZ: CPU idle и iowait в контейнере

[Alex Moskalenko]

Здравствуйте!

После установки ядра 2.6.32-ovz-el-alt70 столкнулся с тем, что внутри 
контейнеров перестали учитываться iowait и idle CPU time в /proc/stat.

В результате имеем следующую картину в контейнере:
1) cat /proc/stat
cpu  265519 32541 83101 0 0 0 0 4758
cpu0 110591 6482 22605 0 0 0 0 1610
cpu1 66653 11526 26524 0 0 0 0 1498
cpu2 44562 5746 14750 0 0 0 0 812
cpu3 43711 8786 19221 0 0 0 0 836
intr 0
swap 0 0
Учитываются usr,sys,nice,sirq. Остальное всегда 0;

2) vmstat в контейнере падает:
vmstat 1 999
procs ---memory-- ---swap-- -io --system-- 
-cpu-
 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy 
id wa st
 0  0  0 1867204  0 39148800  1063   7480 1096 77 
22  0  0  1

Floating point exception
Похоже, что происходит это в не сильно загруженных контейнерах, когда за 
1 период измерений usr,sys,nice и sirq оказываются нулями, в результате 
чего при расчете процентов vmstat делит на 0;


3) top в контейнере показывает или полное отсутствие загрузки CPU (то 
есть по нулям все, включая idle), или неадекватные цифры sys,user и nice 
(причина похоже в том, что idle и iowait всегда 0, из-за чего 
неправильно считается процентное отношение загрузки);


4) Monit в контейнере также пказывает неадекватные цифры загрузки CPU, о 
чем постоянно жалуется.


На ядре 2.6.32-ovz-el-alt60 подобных проблем не замечалось. Среди 
изменений между alt60 и alt70 встречаются
[fairsched] accuracy of idle/iowait time stats reported through 
/proc/stat has been increased (PCLIN-30724) в 042stab056.8,
[scheduler] idle time stat reported by /proc/stat has been corrected 
(PCLIN-30773) в 042stab056.11.


Подскажите пожалуйста - это такая политика партии теперь - не считать 
idle в контейнерах и нужно отключать мониторинг загрузки CPU в них, или 
это все-таки баг?


--
WBR, Alex Moskalenko

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] iSCSI target в ALTLinux

[Alex Moskalenko]

Здравствуйте!

Поделитесь пожалуйста опытом в вопросе использования iSCSI target в 
дистрибутивах ALT.


На данный момент у нас есть 2 варианта target:
1) iSCSI Enterprise Target. Модулей для ядра нет, юзерспейс есть. На 
2.6.32 ядрах работает после сборки модулей из kernel-source-iscsitarget, 
на 3.x - не собирается. Можно заставить работать, собрав модули и 
userspace с сайта iet.
2) Linux-iSCSI.org. Модули включены в ядрах 3.х, утилит для управления 
(rtslib, targetcli и т.д) нет. Утилиты собираются с сайта 
linux-iscsi.org, работают. Вот только при активной работе с iscsi 
(загрузка 4 виртуалок с дисками на iscsi) ядро падает.


Прошу посоветовать/поделиться опытом, кто, что и с каким успехом 
использует для организации iSCSI target, и по возможности поделиться 
знаниями о настройке используемого решения на максимальную стабильность 
и производительность.


Заранее спасибо.

--
WBR, Alex Moskalenko

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] iSCSI target в ALTLinux

[Alex Moskalenko]

26.06.2012 15:18, Vladimir V. Kamarzin пишет:
AM 2) Linux-iSCSI.org. Модули включены в ядрах 3.х, утилит для 
управления AM (rtslib, targetcli и т.д) нет. Утилиты собираются с 
сайта AM linux-iscsi.org, работают. Вот только при активной работе с 
iscsi AM (загрузка 4 виртуалок с дисками на iscsi) ядро падает. Тоже 
хотел затестить, но ещё не добрался. sbolshakov@ кстати конфигурит это 
напрямую через sysfs. А так, у меня tgt на ubuntu, работает стабильно. 

У меня попытки использования lio.org заканчиваются вот этим:
[  328.731894] BUG: unable to handle kernel paging request at 
88003817e000

[  328.732159] IP: [812634cb] sg_next+0xb/0x30
[  328.732309] PGD 180d067 PUD 1811067 PMD 1e1f067 PTE 0
[  328.732562] Oops:  [#1] SMP
[  328.732744] CPU 0
[  328.732783] Modules linked in: crc32c ib_srpt ib_cm ib_sa ib_mad 
ib_core tcm_loop tcm_fc libfc scsi_transport_fc scsi_tgt 
iscsi_target_mod target_core_pscsi target_core_file target_core_iblock 
target_core_mod configfs xt_physdev iptable_filter ip_tables x_tables 
aksparlnx(PO) ipmi_si bridge ipv6 stp bonding dm_multipath scsi_dh 
dm_mod joydev usbhid hid vfat fat usb_storage usb_libusual rtc sr_mod 
cdrom ata_generic pata_acpi uhci_hcd ehci_hcd i2c_i801 psmouse igb 
i5k_amb ahci usbcore i5000_edac ata_piix libahci tg3 edac_core i2c_core 
ppdev coretemp libata serio_raw hwmon evdev pcspkr parport_pc microcode 
iTCO_wdt iTCO_vendor_support usb_common parport dca sg ses enclosure 
container button processor ipmi_devintf ipmi_msghandler tun xenfs 
xen_privcmd xen_blkback xen_netback xen_pciback xen_gntalloc xen_evtchn 
xen_gntdev ext3 jbd mbcache sd_mod crc_t10dif aacraid scsi_mod [last 
unloaded: iscsi_trgt]

[  328.735674]
[  328.735674] Pid: 9730, comm: iscsi_trx Tainted: PF  O 
3.4.3-std-def-alt1 #1 IBM IBM eServer x3400-[7976L2G]-/M97IP
[  328.735674] RIP: e030:[812634cb]  [812634cb] 
sg_next+0xb/0x30

[  328.735674] RSP: e02b:880025ba9c20  EFLAGS: 00010246
[  328.735674] RAX:  RBX: 88002cd2e800 RCX: 
0004
[  328.735674] RDX: ea730430 RSI: 88002e5e6680 RDI: 
88003817dfe0
[  328.735674] RBP: 880025ba9c20 R08: 0200 R09: 
88003817d800
[  328.735674] R10:  R11: 0040 R12: 
88003817dfe0
[  328.735674] R13: 0040 R14: 1000 R15: 
1000
[  328.735674] FS:  7f26d56db720() GS:88003fc0() 
knlGS:

[  328.735674] CS:  e033 DS:  ES:  CR0: 8005003b
[  328.735674] CR2: 88003817e000 CR3: 2cf2c000 CR4: 
2660
[  328.735674] DR0:  DR1:  DR2: 

[  328.735674] DR3:  DR6: 0ff0 DR7: 
0400
[  328.735674] Process iscsi_trx (pid: 9730, threadinfo 
880025ba8000, task 880025ba6440)

[  328.735674] Stack:
[  328.735674]  880025ba9cc0 a087bc42 8840 
00013fc132c0
[  328.735674]  880020cfe4e8 000239d84080 00020200 
880020cfe2e8
[  328.735674]  02c8 25ba2400 880020cfe434 
0200

[  328.735674] Call Trace:
[  328.735674]  [a087bc42] 
transport_allocate_data_tasks+0x1f2/0x350 [target_core_mod]
[  328.735674]  [a08802e8] 
transport_generic_new_cmd+0x198/0x4e0 [target_core_mod]
[  328.735674]  [a086fc82] ? 
core_scsi3_pr_reservation_check+0x52/0x100 [target_core_mod]
[  328.735674]  [a088067b] 
transport_handle_cdb_direct+0x4b/0xb0 [target_core_mod]
[  328.735674]  [a08cd60f] iscsit_execute_cmd+0x26f/0x2c0 
[iscsi_target_mod]
[  328.735674]  [a08d4412] iscsit_sequence_cmd+0xa2/0x130 
[iscsi_target_mod]
[  328.735674]  [a08d8a0f] iscsi_target_rx_thread+0x9ef/0x2020 
[iscsi_target_mod]

[  328.735674]  [810125c6] ? __switch_to+0x156/0x410
[  328.735674]  [a08d8020] ? 
iscsit_thread_get_cpumask+0x90/0x90 [iscsi_target_mod]
[  328.735674]  [a08d8020] ? 
iscsit_thread_get_cpumask+0x90/0x90 [iscsi_target_mod]

[  328.735674]  [8106e396] kthread+0x96/0xa0
[  328.735674]  [81455be4] kernel_thread_helper+0x4/0x10
[  328.735674]  [8144cc38] ? retint_restore_args+0x5/0x6
[  328.735674]  [81455be0] ? gs_change+0x13/0x13
[  328.735674] Code: 55 48 c7 c2 80 3a 26 81 be 80 00 00 00 48 89 e5 e8 
6b ff ff ff c9 c3 66 0f 1f 84 00 00 00 00 00 31 c0 f6 07 02 55 48 89 e5 
75 0d 48 8b 57 20 48 8d 47 20 f6 c2 01 75 02 c9 c3 48 89 d0 c9 48 83

[  328.735674] RIP  [812634cb] sg_next+0xb/0x30
[  328.735674]  RSP 880025ba9c20
[  328.735674] CR2: 88003817e000
[  328.735674] ---[ end trace c05d0c15786a73b5 ]---

Падение происходит при активном использовании таргета, с нескольких LUN 
которого загружаются виртуалки на другом сервере. После этих сообщений 
ядро в течение 30-60 секунд умирает окончательно.


--
WBR, Alex Moskalenko

Re: [Sysadmins] Вопрос о ethernet bonding

[Alex Moskalenko]

15.06.2012 09:48, Sergey пишет:

On Thursday 14 June 2012, Alex Moskalenko wrote:


bond0 = eth0+eth1, mode 802.3ad - транк на коммутатор 1;
bond1 = eth2+eth3, mode 802.3ad - транк на коммутатор 2;
bond2 = bond0+bond1, mode balance-alb - аггрегированый канал из 2х
вышеупомянутых транков.

А зачем ?
В результате должно получиться нечто отказоустойчивое и с балансировкой 
нагрузки. :)


Я, вообще-то, в Linux таким не занимался, но про 802.3ad
пишут, как про преемника Ether Channel. А у Ether Channel
Уже была балансировка + надёжность при поддержке до 4-х
каналов. Если всё так и осталось, то bond1 и bond2 не
нужны, надо сразу bond0 на eth0/1/2/3 делать и не париться.
802.3ad также поддерживает 4 (и больше) каналов. Проблема только в том, 
что коммутаторов 2 и они друг о друге ничего не знают и узнать не могут 
(не стекируются). Поэтому один 802.3ad канал, включающий в себя 2 
коммутатора, и распределяющий трафик, сделать не получится. Получится 
только отказоустойчивость, без балансировки (активен будет только один 
из 802.3ad аггрегированных линков, второй будет в резерве).


PS Наверное, есть смысл не заморачиваться и вообще выкинуть 802.3ad 
часть схемы, оставив один bond0 с mode=balance-alb на все 4 физических 
интерфейса. Не так красиво, но скорее всего работать будет.

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] Вопрос о ethernet bonding

[Alex Moskalenko]

Здравствуйте!

Возник вопрос о реализации отказоустойчивой конфигурации сети с 
распределением нагрузки. Есть сервер с 4мя портами ethernet. Есть два 
коммутатора (не стекируемых), поддерживающие 802.3ad. Есть linux и 
bonding. Хотелось бы получить что-либо подобное:


bond0 = eth0+eth1, mode 802.3ad - транк на коммутатор 1;
bond1 = eth2+eth3, mode 802.3ad - транк на коммутатор 2;
bond2 = bond0+bond1, mode balance-alb - аггрегированый канал из 2х 
вышеупомянутых транков.


В результате должно получиться нечто отказоустойчивое и с балансировкой 
нагрузки. :)


Вопрос в следующем - можно ли объединять bond-интерфейсы в один 
bond-интерфейс? На ядре 3.3.8 такая конфигурация ядром съедается 
(работоспособность еще не проверял, настораживают значения unknown в 
Speed и Duplex в /proc/net/bonding/bond2). На ядре 3.4.2 ситуация 
интереснее - при добавлении bond'а в bond и последующем поднятии 
ethernet-моста (даже никак не связанного с bond'ами) ядро падает. 
Порядок поднятия интерфейсов - сначала мост, затем bond с bond'ами или 
наоборот - значения не имеет - ядро падает.


В связи с вышесказанным, вопрос - можно ли аггрегировать уже 
аггрегированные линки? Прямого запрета в документации bonding вроде как 
и нет, но как-то пугают падения нового ядра...


___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Ядро ovz-el, software RAID5, его синхронизация и высокий LA

[Alex Moskalenko]

03.06.2012 22:56, Alex Moskalenko пишет:

03.06.2012 18:06, Alex Moskalenko пишет:

Здравствуйте!

Столкнулся с непонятным мне поведением системы на ovz-el при
синхронизации/создании/проверке программного массива RAID5.
Работает все это на 2.6.32-ovz-el-alt63 (аналогичное поведение было на
ovz-el ядрах и до alt63). При создании/ребилде/проверке этого массива
получаю нехарактерно низкую для такой системы скорость синхронизации и
нехарактерно высокий LA. Также высокий LA получается при интенсивной
работе с массивом RAID5. С массивом RAID10, расположенным на тех же
дисках, таких эффектов не наблюдается.
Проблема, похоже, в CONFIG_MULTICORE_RAID456=y. Возможно, нет смысла 
включать по умолчанию эту опцию? Судя по ссылкам, оно работает мягко 
говоря странно. В ближайшее время, если ничего не помешает, попробую 
пересобрать ядро с CONFIG_MULTICORE_RAID456=n, и если проблема 
исчезнет - повешу багу.


Да, это оно. Пересборка с отключенным CONFIG_MULTICORE_RAID456 приводит 
скорость и LA в адекватное состояние. Соответственно, 
https://bugzilla.altlinux.org/show_bug.cgi?id=27399.

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] Ядро ovz-el, software RAID5, его синхронизация и высокий LA

[Alex Moskalenko]

Здравствуйте!

Столкнулся с непонятным мне поведением системы на ovz-el при 
синхронизации/создании/проверке программного массива RAID5.


Исходные данные: Intel(R) Core(TM)2 CPU 6420@2.13GHz, чипсет G31, SATA 
ICH9R в режиме AHCI. 4 SATA жестких диска. На них собран программный 
RAID5 массив

md5 : active raid5 sdc2[0] sdd2[4] sde2[2] sdf2[1]
  1514703360 blocks super 1.2 level 5, 512k chunk, algorithm 2 
[4/4] []

  bitmap: 6/482 pages [24KB], 512KB chunk, file: /_bitmap_md5

Работает все это на 2.6.32-ovz-el-alt63 (аналогичное поведение было на 
ovz-el ядрах и до alt63). При создании/ребилде/проверке этого массива 
получаю нехарактерно низкую для такой системы скорость синхронизации и 
нехарактерно высокий LA. Также высокий LA получается при интенсивной 
работе с массивом RAID5. С массивом RAID10, расположенным на тех же 
дисках, таких эффектов не наблюдается.


Для примера - текущий снимок системы в момент проверки массива:

cat /proc/mdstat
Personalities : [raid1] [raid10] [raid6] [raid5] [raid4]
md5 : active raid5 sdc2[0] sdd2[4] sde2[2] sdf2[1]
  1514703360 blocks super 1.2 level 5, 512k chunk, algorithm 2 
[4/4] []
  []  check =  4.6% (23342252/504901120) 
finish=990.1min speed=8105K/sec

  bitmap: 6/482 pages [24KB], 512KB chunk, file: /_bitmap_md5
uptime
 17:21:52 up 23 days,  4:53,  1 user,  load average: 50.28, 54.18, 49.92

В списке процессов видно ~255 штук [async/XXX] потоков ядра, из них в 
состоянии R находится примерно LA 1min.


По dstat картина следующая:
 total-cpu-usage 
--dsk/sdc-dsk/sdd-dsk/sde-dsk/sdf-- -net/total- ---paging-- 
---system--
usr sys idl wai hiq siq| read  writ: read  writ: read  writ: read  writ| 
recv  send|  in   out | int   csw
  4   2  60  33   0   1| 1082k 1198k: 586k 1196k:1070k 1196k: 574k 
1198k|   0 0 |  23B   38B|1864  4188
  1  69  30   0   0   0|   0 0 :   0 0 :   0 0 :   0 0 
|  22k   27k|   0 0 |  25k  590k
  2  73  24   0   0   0|   0 0 :   0 0 :8192B0 :   0 0 
:   0 0 :   0 0 |  43k   49k|   0 0 |  28k  583k
  2  72  26   0   0   0|   0  9216B:   025k:   025k:   0  
9216B|  44k   49k|   0 0 |  27k  582k
  7  72  21   0   0   0|   0  1024B:   0  1024B:   0  1024B:   0  
1024B|  19k   22k|   0 0 |  41k  605k
  2  72  25   1   0   0|8568k 2048B:7644k 2048B:8116k 2048B:7584k 
2048B|  43k   48k|   0 0 |  31k  526k
  2  78  18   0   0   2|  56M0 :  57M0 :  56M0 :  57M0 
|  41k   46k|   0 0 |  26k  585k
  1  68  31   0   0   0|   0 0 :   0 0 :   0 0 :   0 0 
|5318B 7801B|   0 0 |  25k  589k
  1  70  28   0   0   0|   013k:   0  9216B:   0  9216B:   0
13k|  27k   31k|   0 0 |  30k  585k
  5  71  24   0   0   0|   0  1024B:   0  1024B:   0  1024B:   0  
1024B|  31k   35k|   0 0 |  36k  603k
  2  75  23   0   0   1|   0 0 :   0 0 :   0 0 :   0 0 
|  70k   78k|   0 0 |  30k  577k
  2  70  28   0   0   0|   0 0 :   0 0 :   0 0 :   0 0 
|  25k   28k|   0 0 |  30k  579k
  1  69  29   0   0   0|   0 0 :   0 0 :   0 0 :   0 0 
|  11k   14k|   0 0 |  25k  584k
  2  76  20   0   0   2|7404k  972k:6384k  940k:8524k  940k:9712k  
972k|  74k   82k|   0 0 |  25k  529k
  5  72  21   0   0   1|  57M 1024B:  58M 1024B:  56M 1024B:  55M 
1024B|  21k   24k|   0 0 |  34k  599k
  3  75  22   0   0   0|   0 0 :   0 0 :   0 0 :   0 0 
|  48k   54k|   0 0 |  33k  582k^C


Мне кажется, что на таком железе скорость синхронизации RAID5 в 10 Мб/с 
при LA 50 - это несколько чересчур. При этом, как видно по dstat, ядра 
загружены совсем не на 100%. Также из dstat видно очень больное 
количество context switches и программных прерываний.


Подскажите пожалуйста, куда можно покопать в этом вопросе. Может быть, 
можно что-то передать ядру/какому либо модулю, чтобы они не вели себя 
так  неадекватно?



--
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Ядро ovz-el, software RAID5, его синхронизация и высокий LA

[Alex Moskalenko]

03.06.2012 18:06, Alex Moskalenko пишет:

Здравствуйте!

Столкнулся с непонятным мне поведением системы на ovz-el при
синхронизации/создании/проверке программного массива RAID5.

Исходные данные: Intel(R) Core(TM)2 CPU 6420@2.13GHz, чипсет G31, SATA
ICH9R в режиме AHCI. 4 SATA жестких диска. На них собран программный
RAID5 массив
md5 : active raid5 sdc2[0] sdd2[4] sde2[2] sdf2[1]
  1514703360 blocks super 1.2 level 5, 512k chunk, algorithm 2
[4/4] []
  bitmap: 6/482 pages [24KB], 512KB chunk, file: /_bitmap_md5

Работает все это на 2.6.32-ovz-el-alt63 (аналогичное поведение было на
ovz-el ядрах и до alt63). При создании/ребилде/проверке этого массива
получаю нехарактерно низкую для такой системы скорость синхронизации и
нехарактерно высокий LA. Также высокий LA получается при интенсивной
работе с массивом RAID5. С массивом RAID10, расположенным на тех же
дисках, таких эффектов не наблюдается.

Для примера - текущий снимок системы в момент проверки массива:

cat /proc/mdstat
Personalities : [raid1] [raid10] [raid6] [raid5] [raid4]
md5 : active raid5 sdc2[0] sdd2[4] sde2[2] sdf2[1]
  1514703360 blocks super 1.2 level 5, 512k chunk, algorithm 2
[4/4] []
  []  check =  4.6% (23342252/504901120)
finish=990.1min speed=8105K/sec
  bitmap: 6/482 pages [24KB], 512KB chunk, file: /_bitmap_md5
uptime
 17:21:52 up 23 days,  4:53,  1 user,  load average: 50.28, 54.18, 49.92


Проблема, похоже, в CONFIG_MULTICORE_RAID456=y. Возможно, нет смысла 
включать по умолчанию эту опцию? Судя по ссылкам, оно работает мягко 
говоря странно. В ближайшее время, если ничего не помешает, попробую 
пересобрать ядро с CONFIG_MULTICORE_RAID456=n, и если проблема исчезнет 
- повешу багу.

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] Zabbix + HP iLO IPMI

[Alex Moskalenko]

Здравствуйте!

Подскажите пожалуйста направление поисков в решении проблемы мониторинга 
параметров IPMI на HP iLO нашим заббиксом.


Есть машина с alt linux p6 и zabbix-server-pgsql-1:1.8.5-alt1.rc1. Есть 
сервер HP с iLO, с которого хочется получать данные по IPMI. С машины с 
заббиксом через ipmitool все видно:


[root@zabbix zabbix]# ipmitool -I lanplus -L user -U zabbix -P zabbix -H 
blade2 mc info

Device ID : 19
Device Revision   : 1
Firmware Revision : 1.28
IPMI Version  : 2.0
Manufacturer ID   : 11
Manufacturer Name : Hewlett-Packard
Product ID: 8224 (0x2020)
Product Name  : Unknown (0x2020)
Device Available  : yes
Provides Device SDRs  : yes
Additional Device Support :
Sensor Device
SDR Repository Device
SEL Device
FRU Inventory Device
Aux Firmware Rev Info :
0x00
0x00
0x00
0x30
[root@zabbix zabbix]# ipmitool -I lanplus -L user -U zabbix -P zabbix -H 
blade2 fru

FRU Device Description : Builtin FRU Device (ID 0)
 Chassis Type : Main Server Chassis
 Chassis Serial : CZJ14706XL
 Chassis Extra : d0b5003700fc010101
 Chassis Extra : d4fd015a009001
 Board Mfg Date: Mon Oct 24 00:19:00 2011
 Board Mfg : HP
 Board Product : HP ProLiant BL460c G7
 Board Serial  : YH1AMR4459
 Board Part Number : 605659-001
 Board Extra   : d24135
 Board Extra   : d5588743b001
 Product Manufacturer  : HP
 Product Name  : HP ProLiant BL460c G7
 Product Part Number   : 603588-B21
 Product Version   : X1
 Product Serial: CZJ14706XL

[root@zabbix zabbix]# ipmitool -I lanplus -L user -U zabbix -P zabbix -H 
blade2 sensor
UID Light| 0x0| discrete   | 0x0080| na| 
na| na| na| na| na
Health LED   | 0x0| discrete   | 0x0080| na| 
na| na| na| na| na
VRM 1| 0x0| discrete   | 0x0280| na| 
na| na| na| na| na
VRM 2| 0x0| discrete   | 0x0280| na| 
na| na| na| na| na
01-Inlet Ambient | 18.000 | degrees C  | ok| na| 
na| na| na| 42.000| 46.000
02-CPU 1 | 40.000 | degrees C  | ok| na| 
na| na| na| 82.000| 83.000
03-CPU 2 | 40.000 | degrees C  | ok| na| 
na| na| na| 82.000| 83.000
04-DIMMs 1   | 23.000 | degrees C  | ok| na| 
na| na| na| 87.000| 92.000
05-DIMMs 2   | 27.000 | degrees C  | ok| na| 
na| na| na| 87.000| 92.000
06-HDD Max   | na | degrees C  | na| na| 
na| na| na| 60.000| 65.000
07-Memory 1 1-6  | 27.000 | degrees C  | ok| na| 
na| na| na| 81.000| 86.000
08-Memory 2 1-6  | 33.000 | degrees C  | ok| na| 
na| na| na| 81.000| 86.000
09-IOH   | 53.000 | degrees C  | ok| na| 
na| na| na| 105.000   | 110.000
10-Mezz Zone | 37.000 | degrees C  | ok| na| 
na| na| na| 81.000| 86.000
11-CNA Zone  | 29.000 | degrees C  | ok| na| 
na| na| na| 81.000| 86.000
12-Chassis Exit  | 25.000 | degrees C  | ok| na| 
na| na| na| 70.000| 75.000
13-Chassis Exit  | 14.000 | degrees C  | ok| na| 
na| na| na| 70.000| 75.000
Virtual Fan  | 27.440 | unspecified | nc| na| 
na| na| na| na| na
Enclosure Status | 0x0| discrete   | 0x0080| na| 
na| na| na| na| na
Power Meter  | 74.000 | Watts  | cr| na| 
na| na| na| na| na
Memory Status| 0x0| discrete   | 0x4080| na| 
na| na| na| na| na


А вот zabbix по IPMI ничего получить не может со следующим сообщением 
cannot connect to IPMI host: [16777411] Unknown error 16777411. При 
этом трафик IPMI присуствует и обоих направлениях. Попытки поиграться с 
типом авторизации и уровнем привилегий в настройках хоста в zabbix 
проблемы не решают (хотя номер ошибки меняется).


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

--
WBR, Alex Moskalenko

___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] IBM eServer x3400 + Xen 4.1.0 + kernel-image-xen-dom0 = crash

[Alex Moskalenko]

21.02.2012 18:42, Vitaly Kuznetsov пишет:

On Tue, 21 Feb 2012 07:07:13 +0400, Alex Moskalenko wrote:


Здравствуйте!

Подскажите пожалуйста, пытались ли контактировать с апстримом на
предмет этого патча? Я до сих пор заинтересован в запуске xen на
x3400, а ядра 3.1.х и 3.2.х продолжают падать в dom0. Наше патченое
xen-dom0 при этом работает. Поэтому, если с апстримом не
контактировали, хочу сам попробовать пообщаться в рассылках/повесить
баг на эту тему.

PS Неужели больше никто не пытался запускать pvops ядра в dom0 на
x3400? Я единственный из всех пользователей xen, кто поймал эту
проблему? Или у меня какой-то неправильный сервер?...


Это всё очень похоже на глючный биос одной конкретной железки (там,
насколько я помню, проблемы в районе ACPI). Мы с апстримом по данной
проблеме не общались.


Да, проблемы там в районе ACPI, причем так фатально они проявляются 
только при запуске ядра под Xen. При отсутствии xen ядро грузится и 
работает.


Насколько я понял суть Ваших исправлений в git (

http://git.altlinux.org/people/silicium/packages/?p=kernel-image.git;a=shortlog;h=refs/heads/kernel-image-xen-dom0

), Вы добавили обработку ошибок при доступе ядра к областям памяти через 
функции xen. В исходном варианте ядро не проверяет результат своих 
действий, и никак не ожидает получить отказ от гипервизора, вследствие 
чего падает. Так что, возможно железка и глючная, но мне кажется, что 
ядро должно работать одинаково независимо от наличия/отсутствия 
гипервизора. Вот по поводу отсутствия корректной обработки ошибок и 
хотел пообщаться с апстримом. В праздники постараюсь получить логи с 
этого сервера с последним 3.х ядром в 3х вариантах - bare metal, xen, 
xen/noacpi и как-нибудь донести ситуацию до апстрима.


Не подскажете, откуда лучше начинать? xen-devel@, bugzilla.xen.org, ...?


--
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] IBM eServer x3400 + Xen 4.1.0 + kernel-image-xen-dom0 = crash

[Alex Moskalenko]

15.04.2011 12:15, Michail Yakushin пишет:

14.04.2011 12:16, Alex Moskalenko пишет:

On Wednesday 13 April 2011 20:01:07 you wrote:
В http://git.altlinux.org/tasks/42643/ собирается ядро, которое 
должно у

вас заработать. Как соберётся - можете начинать тестировать.
Спасибо, 2.6.32.2 загрузилось. Устройства вроде бы тоже работают. 
klogd также

запускается в чруте от пользователя.
Есть несколько настораживающих сообщений в протоколах загрузки ядра и
гипервизора, привожу их далее:

гипервизор
(XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 000fec80
(XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 000fec80
(XEN) mm.c:4967:d0 ptwr_emulate: could not get_page_from_l1e()
(XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 000fec80
(XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 000fec80
(XEN) mm.c:4967:d0 ptwr_emulate: could not get_page_from_l1e()

ядро
[0.067405] ACPI: No dock devices found.
[0.067667] HYPERVISOR_update_va_mapping at 0xc9028000 
return -22

(ptep=0x88003fc87140 pteval=0x8000fec80473)
[0.067872] arch/x86/xen/mmu.c:xen_set_pte:Error setting 
88003fc87140

to 8000fec80473
[0.068000] set_pte_at 0x88003fc87140 failed 1
[0.068008] ACPI Error: Could not map memory at FEC8, 
size 100

(20090903/exregion-180)
[0.068269] ACPI Exception: AE_NO_MEMORY, Returned by Handler for
[SystemMemory] (20090903/evregion-424)
[0.068533] ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0._CRS] (Node 88003fc83670), AE_NO_MEMORY
[0.068850] ACPI Error (uteval-0250): Method execution failed
[\_SB_.PCI0._CRS] (Node 88003fc83670), AE_NO_MEMORY
[0.069160] ACPI: PCI Root Bridge [PCI0] (:00)

[0.196719] ACPI: bus type pnp registered
[0.197082] HYPERVISOR_update_va_mapping at 0xc9028000 
return -22

(ptep=0x88003fc87140 pteval=0x8000fec80473)
[0.197299] arch/x86/xen/mmu.c:xen_set_pte:Error setting 
88003fc87140

to 8000fec80473
[0.197491] set_pte_at 0x88003fc87140 failed 1
[0.197616] ACPI Error: Could not map memory at FEC8, 
size 100

(20090903/exregion-180)
[0.197893] ACPI Exception: AE_NO_MEMORY, Returned by Handler for
[SystemMemory] (20090903/evregion-424)
[0.198173] ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0._CRS] (Node 88003fc83670), AE_NO_MEMORY
[0.198523] ACPI Error (uteval-0250): Method execution failed
[\_SB_.PCI0._CRS] (Node 88003fc83670), AE_NO_MEMORY
[0.198845] pnp 00:00: can't evaluate _CRS: 4

[0.215212] PM-Timer failed consistency check  (0x0xff) - 
aborting.


[0.422136] Freeing unused kernel memory: 548k freed
[0.423725] arch/x86/xen/mmu.c:xen_set_pte:Error setting 
88003d6030f0

to 8004c0564145
[0.438260] input: AT Translated Set 2 keyboard
as /devices/platform/i8042/serio0/input/input1

[5.593467] scsi 0:1:0:0: Attached scsi generic sg3 type 0
[5.593548] HYPERVISOR_update_va_mapping at 0xe8f1f000 
return -22

(ptep=0x88003d1d38f8 pteval=0x800432fd7063)
[5.593560] HYPERVISOR_update_va_mapping at 0xe8f3b000 
return -22

(ptep=0x88003d1d39d8 pteval=0x800435c88063)
[5.593570] HYPERVISOR_update_va_mapping at 0xe8f57000 
return -22

(ptep=0x88003d1d3ab8 pteval=0x800435dfa063)
[5.593581] HYPERVISOR_update_va_mapping at 0xe8f73000 
return -22

(ptep=0x88003d1d3b98 pteval=0x800435df9063)
[5.593591] HYPERVISOR_update_va_mapping at 0xe8f8f000 
return -22

(ptep=0x88003d1d3c78 pteval=0x8004356ef063)
[5.593602] HYPERVISOR_update_va_mapping at 0xe8fab000 
return -22

(ptep=0x88003d1d3d58 pteval=0x8004356ea063)
[5.593612] HYPERVISOR_update_va_mapping at 0xe8fc7000 
return -22

(ptep=0x88003d1d3e38 pteval=0x8004356eb063)
[5.593627] HYPERVISOR_update_va_mapping at 0xe8fe3000 
return -22

(ptep=0x88003d1d3f18 pteval=0x8004356ec063)
[5.593725] scsi 0:1:1:0: Attached scsi generic sg4 type 0
Суть этих сообщений warningи из за того что xen и dom0 подрались за 
область памяти, которая нужна ACPI и APIC. Но оно должно работать, да 
ядро не смогло кое-что сделать, но это делаетет сам xen.
Падения были вызваны тем, что ядро не правильно обрабатывало эту 
ошибку и наобум лезло туда куда xen его не пускал. П
Просбсьа понаблюдать, видимо этот пач будем отправлять в апстрим, 
подобная ситуация может быть и на другом железе.

___


Здравствуйте!

Подскажите пожалуйста, пытались ли контактировать с апстримом на предмет 
этого патча? Я до сих пор заинтересован в запуске xen на x3400, а ядра 
3.1.х и 3.2.х продолжают падать в dom0. Наше патченое xen-dom0 при этом 
работает. Поэтому, если с апстримом не контактировали, хочу сам 
попробовать пообщаться в рассылках/повесить баг на эту тему.


PS Неужели больше никто не пытался запускать pvops

[Sysadmins] Dovecot и квоты maildir

[Alex Moskalenko]

Здравствуйте!

Помогите пожалуйста разобраться в сложившейся ситуации с dovecot и квотами.

Есть сервер на p6. Установлены следующие пакеты:
dovecot-2.0.12-alt1
postfix-dovecot-2.5.14-alt1
dovecot-pigeonhole-2.0.12-alt1

Сервер обслуживает виртуальных почтовых пользователей из LDAP-каталога. 
Формат почтовых ящиков - Maildir. Доставка писем в ящики производится с 
помощью LMTP dovecot'а. В dovecot установлены квоты на ящики пользователей:

в файле mail.conf
mail_plugins = quota acl listescape zlib
в файле 90-quota.conf
plugin {
  quota = maildir:Your Mailbox Quota
  quota_rule = *:storage=16G
  quota_rule2 = Trash:storage=+128M
}

Проблема заключается в том, что для одного из пользователей квоты 
считаются неправильно. doveadm quota recalc -u username ситуацию не 
изменяет. Вывод диагностических команд:


Реальный объем ящика на диске:
du -kd 0 username
4968508username

Реальное количество файлов в ящике (сообщения + служебные файлы dovecot):
find username -type f -print | wc -l
267285

Отчет о квотах dovecot:
doveadm quota get -u username
Quota name   Type   ValueLimit  %
Your Mailbox Quota STORAGE 69505 16777216  0
Your Mailbox Quota MESSAGE   338- 0

Мягко говоря, отчет dovecot действительности не соответствует. Ни по 
количеству сообщений, ни по их размеру.


При этом для другого пользователя все очень похоже на правду:
Реальный объем ящика на диске:
du -kd 0 username1
9331292username1

Реальное количество файлов в ящике (сообщения + служебные файлы dovecot):
find username1 -type f -print | wc -l
59974

Отчет о квотах dovecot:
doveadm quota get -u username1
Quota name   Type Value Limit  %
Your Mailbox Quota STORAGE 9153247 16777216 54
Your Mailbox Quota MESSAGE   59744-0

Какие-либо сообщения об ошибках/проблемах в логах отсутствуют. Все 
учетные записи работают без ошибок, только у проблемной квота не считается.


Подскажите пожалуйста, в чем тут может быть проблема.


-- WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Проблема с DHCPD и DDNS

[Alex Moskalenko]

On Wednesday 14 September 2011 13:49:50 Alex Moskalenko wrote:
 Для начала протестирую у себя с пару-тройку дней, если проблем не вылезет -
 оформлю багу типа enh и приложу к ней патч.

#26309

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Проблема с DHCPD и DDNS

[Alex Moskalenko]

On Monday 12 September 2011 16:14:36 Alex Moskalenko wrote:

skip...
 При использовании dhcp-server-3.0.7-alt7 с динамическим обновлением зоны в
 bind-9.3.6-alt6 (p6) наткнулся на следующую проблему. Хотелось бы, чтобы
 dhcpd обновлял A и PTR записи независимо от соответствующим им DHCID или 
 генерировал DHCID не на основе MAC-адреса клиента. Вариант (1) возможен к
 реализации в dhcpd = 3.1 (опция update-conflict-detection), соответственно
 с нашим 3.0.7 не подходит. Возможно ли реализовать вариант (2)?

 В идеале, хотелось бы получить обновление DNS-зон независимо от железа
 клиента, а с привязкой по его UUID или hostame или FQDN.

Отвечу сам себе. :)

Обошел проблему сборкой текущего 3.1-ESV-R3, с адаптацией нашего spec-файла и 
chroot/droppriv-патча от 3.0.7. Проблема с обновлением зон решилась опцией 
update-conflict-detection.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Проблема с DHCPD и DDNS

[Alex Moskalenko]

On Wednesday 14 September 2011 13:43:01 Michael Shigorin wrote:
  Обошел проблему сборкой текущего 3.1-ESV-R3, с адаптацией
  нашего spec-файла и chroot/droppriv-патча от 3.0.7. Проблема
  с обновлением зон решилась опцией update-conflict-detection.

 Так мож в сизиф? :)
Э... Последний раз я ковырялся в сишных программах около 5 лет назад. 
Поэтому не особо уверен в тех правках (особенно исправление несогласованных 
char / unsigned crar), которые сделал. Для начала протестирую у себя с 
пару-тройку дней, если проблем не вылезет - оформлю багу типа enh и приложу к 
ней патч.

PS Хочется еще ldap прикрутить к dhcpd. На этой неделе выполню подход к 
снаряду, и если снаряд выживет, то повешу багу и на dhcpd-ldap тоже. :) 

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] Проблема с DHCPD и DDNS

[Alex Moskalenko]

Здравствуйте!

При использовании dhcp-server-3.0.7-alt7 с динамическим обновлением зоны в 
bind-9.3.6-alt6 (p6) наткнулся на следующую проблему. 

Имеется сеть с Windows-клиентами. Dhcpd исправно создает новые A и TXT записи 
в прямой зоне, и PTR записи в обратной при новой аренде адреса новым 
компьютером. Также dhcpd исправно удаляет A и TXT записи из прямой зоны, и 
PTR запись из обратной при истечении срока аренды адреса (долгой неактивности 
компьютера).

Но если в компьютере поменять сетевую карту с сохранением его имени, то dhcp 
не производит обновления прямой и обратной зон со следующей диагностикой:

Sep 12 15:28:37 main dhcpd: Forward map from host.lan. to 192.168.0.234 
FAILED: Has an A record but no DHCID, not mine.
Sep 12 15:28:37 main dhcpd: DHCPREQUEST for 192.168.0.224 from 
14:da:e9:0c:54:92 (host) via brmain0
Sep 12 15:28:37 main dhcpd: DHCPACK on 192.168.0.234 to 14:da:e9:0c:54:92 
(host) via brmain0

В логах bind при этом появляются следующие записи:

Sep 12 15:28:37 main named[374]: client 127.0.0.1#37250: updating 
zone 'lan/IN': update unsuccessful: host.lan: 'name not in use' prerequisite 
not satisfied (YXDOMAIN)
Sep 12 15:28:37 main named[374]: client 127.0.0.1#50081: updating 
zone 'lan/IN': update unsuccessful: host.lan/TXT: 'RRset exists (value 
dependent)' prerequisite not satisfied (NXRRSET)

Если я правильно понял документацию, то такое поведение является правильным, 
так как dhcpd генерирует DHCID на основе аппаратного адреса клиента, поэтому 
при смене сетевой карты считает клиента новым и отказывается обновлять A и 
PTR записи, которым соответствует старый DHCID. Из-за этого рабочие станции 
при смене сетевых карт оказываются с неправильными записями в DNS.

Прошу подсказать, как можно обойти эту ситуацию. Хотелось бы, чтобы dhcpd 
обновлял A и PTR записи независимо от соответствующим им DHCID или 
генерировал DHCID не на основе MAC-адреса клиента. Вариант (1) возможен к 
реализации в dhcpd = 3.1 (опция update-conflict-detection), соответственно с 
нашим 3.0.7 не подходит. Возможно ли реализовать вариант (2)?

В идеале, хотелось бы получить обновление DNS-зон независимо от железа 
клиента, а с привязкой по его UUID или hostame или FQDN.

Заранее спасибо.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] Samba 3.5.10-alt2 и имена принтеров с кириллицей

[Alex Moskalenko]

Здравствуйте!

Использую samba 3.5.10-alt2 (p6) в качестве сервера печати для машин Windows. 
Обнаружилась следующая проблема - при попытке красиво и понятно (с 
использованием кириллицы) назвать принтеры на сервере подсистема печати в 
самбе умирает. Возвратить сервер в рабочее состояние удается только удалив 
tdb-файлы ntprinters.tdb и tdb-файл с именем неправильного принтера. В 
логах самбы следующая информация:

=== cut ===
[2011/08/26 13:08:42.282189,  1] ../librpc/ndr/ndr.c:421(ndr_push_error)
  ndr_push_error(5): Bad character conversion
[2011/08/26 13:08:42.282356,  1] ../librpc/ndr/ndr.c:421(ndr_push_error)
  ndr_push_error(5): Bad character conversion
[2011/08/26 13:08:42.282378,  0] rpc_server/srv_pipe.c:2439(api_rpcTNP)
  api_rpcTNP: \spoolss: SPOOLSS_GETPRINTER failed.
[2011/08/26 13:08:42.334397,  1] smbd/ipc.c:447(api_fd_reply)
  api_fd_reply: INVALID PIPE HANDLE: 3578
[2011/08/26 13:08:42.354360,  1] ../librpc/ndr/ndr.c:421(ndr_push_error)
  ndr_push_error(5): Bad character conversion
[2011/08/26 13:08:42.354435,  1] ../librpc/ndr/ndr.c:421(ndr_push_error)
  ndr_push_error(5): Bad character conversion
[2011/08/26 13:08:42.354453,  0] rpc_server/srv_pipe.c:2439(api_rpcTNP)
  api_rpcTNP: \spoolss: SPOOLSS_GETPRINTER failed.
[2011/08/26 13:12:23.181281,  1] smbd/service.c:1251(close_cnum)
  management-vm (192.168.4.124) closed connection to service print$
[2011/08/26 13:12:25.742662,  1] ../librpc/ndr/ndr.c:421(ndr_push_error)
  ndr_push_error(5): Bad character conversion
[2011/08/26 13:12:25.742831,  1] ../librpc/ndr/ndr.c:421(ndr_push_error)
  ndr_push_error(4): ndr_push_relative_ptr2_end:relative_end_offset 0  offset 
112
[2011/08/26 13:12:25.742854,  0] rpc_server/srv_pipe.c:2439(api_rpcTNP)
  api_rpcTNP: \spoolss: SPOOLSS_GETPRINTER failed.
=== cut ===
Подсистема печати после api_rpcTNP: \spoolss: SPOOLSS_GETPRINTER failed. уже 
мертва. Часть более подробного лога (loglevel=10) во вложении.

Настройки smb.conf, касающиеся кодировок:
dos charset = CP866
unix charset = UTF8
display charset = UTF8
glibc-locales, glibc-iconv-modules, iconv установлены. В системе проблем с 
кодировкой не замечено.

С самбой 3.0.x из p5 и 5.1 кириллица в именах принтеров работает и проблем не 
создает.

Прошу подсказать, что я мог недонастроить/настроить не так.

Заранее спасибо.

-- 
WBR, Alex Moskalenko


log.spoolss.bz2
Description: BZip2 compressed data
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] p6, bind9.8-sdb и ldap

[Alex Moskalenko]

 17518] stat(/lib64, 0x7fffe2343050) = -1 ENOENT (No such file or 
directory)
[pid 17518] open(/usr/lib64/tls/x86_64/libnss_dns.so.2, O_RDONLY) = -1 
ENOENT (No such file or directory)
[pid 17518] stat(/usr/lib64/tls/x86_64, 0x7fffe2343050) = -1 ENOENT (No such 
file or directory)
[pid 17518] open(/usr/lib64/tls/libnss_dns.so.2, O_RDONLY) = -1 ENOENT (No 
such file or directory)
[pid 17518] stat(/usr/lib64/tls, 0x7fffe2343050) = -1 ENOENT (No such file 
or directory)
[pid 17518] open(/usr/lib64/x86_64/libnss_dns.so.2, O_RDONLY) = -1 ENOENT 
(No such file or directory)
[pid 17518] stat(/usr/lib64/x86_64, 0x7fffe2343050) = -1 ENOENT (No such 
file or directory)
[pid 17518] open(/usr/lib64/libnss_dns.so.2, O_RDONLY) = -1 ENOENT (No such 
file or directory)
[pid 17518] stat(/usr/lib64, 0x7fffe2343050) = -1 ENOENT (No such file or 
directory)
[pid 17518] open(/etc/openldap/ldap.conf, O_RDONLY) = -1 ENOENT (No such 
file or directory)
[pid 17518] geteuid()   = 25
[pid 17518] getuid()= 25
[pid 17518] open(/root/ldaprc, O_RDONLY) = -1 ENOENT (No such file or 
directory)
[pid 17518] open(/root/.ldaprc, O_RDONLY) = -1 ENOENT (No such file or 
directory)
[pid 17518] open(ldaprc, O_RDONLY)= -1 ENOENT (No such file or 
directory)
[pid 17518] socket(PF_NETLINK, SOCK_RAW, 0) = 5
[pid 17518] bind(5, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
[pid 17518] getsockname(5, {sa_family=AF_NETLINK, pid=17518, groups=}, 
[12]) = 0
[pid 17518] sendto(5, \24\0\0\0\26\0\1\3ZTKN\0\0\0\0\0\0\0\0, 20, 0, 
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
[pid 17518] recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, 
groups=}, 
msg_iov(1)=[{0\0\0\0\24\0\2\0ZTKNnD\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1...,
 
4096}], msg_controllen=0, msg_flags=0}, 0) = 104
[pid 17518] recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, 
groups=}, 
msg_iov(1)=[{@\0\0\0\24\0\2\0ZTKNnD\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0...,
 
4096}], msg_controllen=0, msg_flags=0}, 0) = 64
[pid 17518] recvmsg(5, {msg_name(12)={sa_family=AF_NETLINK, pid=0, 
groups=}, 
msg_iov(1)=[{\24\0\0\0\3\0\2\0ZTKNnD\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0..., 
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
[pid 17518] close(5)= 0
[pid 17518] socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
[pid 17518] fcntl(5, F_SETFD, FD_CLOEXEC) = 0
[pid 17518] setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
[pid 17518] setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 17518] connect(5, {sa_family=AF_INET, sin_port=htons(389), 
sin_addr=inet_addr(192.168.244.30)}, 16) = 0
[pid 17518] --- {si_signo=SIGSEGV, si_code=SEGV_MAPERR, 
si_addr=0xd5b32160} (Segmentation fault) ---
Process 17518 detached

Прошу помощи у сообщества - работоспособна ли текущая сборка bind 9.8 в p6 в 
случае использования sdb?

PS Возможно, в chroot bind не хватает нужных библиотек?

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] IBM eServer x3400 + Xen 4.1.0 + kernel-image-xen-dom0-alt38

[Alex Moskalenko]

 сожалению падает при загрузке, как 
2.6.32-xen-dom0-alt  alt36.2.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] IBM eServer x3400 + Xen 4.1.0 + kernel-image-xen-dom0-alt38

[Alex Moskalenko]

On Friday 13 May 2011 15:52:06 Vitaly Kuznetsov wrote:
 Alex Moskalenko m...@elserv.msk.su writes:
  За 20 минут работы - 15 Мб лога. Сообщения появляются не с постоянной
  периодичностью, а при какой-либо активности в dom0, то есть работа в
  domU сообщений не вызывает. С 2.6.32-alt36.2 этих сообщений нет.

 В попавшем сегодня в сизиф -alt39 проблема должна быть исправлена.
Спасибо, с alt39 сообщения не беспокоят. :)

Один раз поймал следующее:

May 15 12:17:05 mainsrv-dom0 kernel: [69672.415333] BUG: soft lockup - CPU#1 
stuck for 65s! [swapper:0]
May 15 12:17:05 mainsrv-dom0 kernel: [69672.415349] Modules linked in: 
xen_gntdev xt_physdev iptable_filter ip_tables x_tables coretemp ipmi_si 
ipmi_msghandler bridge stp dm_mod joydev usbhid hid ide_cd_mod cdrom 
ata_generic ide_pci_generic pata_acpi ata_piix ahci rtc_cmos rtc_core libata 
8250_pnp i2c_i801 i2c_core ehci_hcd uhci_hcd psmouse i5000_edac edac_core 
usbcore serio_raw piix i5k_amb ide_core hwmon pcspkr evdev ppdev parport_pc 
parport 8250 serial_core rtc_lib container sg tg3 nls_base button thermal 
processor ses enclosure ext3 jbd mbcache sd_mod crc_t10dif aacraid scsi_mod
May 15 12:17:05 mainsrv-dom0 kernel: [69672.416113] CPU 1:
May 15 12:17:05 mainsrv-dom0 kernel: [69672.416137] Modules linked in: 
xen_gntdev xt_physdev iptable_filter ip_tables x_tables coretemp ipmi_si 
ipmi_msghandler bridge stp dm_mod joydev usbhid hid ide_cd_mod cdrom 
ata_generic ide_pci_generic pata_acpi ata_piix ahci rtc_cmos rtc_core libata 
8250_pnp i2c_i801 i2c_core ehci_hcd uhci_hcd psmouse i5000_edac edac_core 
usbcore serio_raw piix i5k_amb ide_core hwmon pcspkr evdev ppdev parport_pc 
parport 8250 serial_core rtc_lib container sg tg3 nls_base button thermal 
processor ses enclosure ext3 jbd mbcache sd_mod crc_t10dif aacraid scsi_mod
May 15 12:17:05 mainsrv-dom0 kernel: [69672.416898] Pid: 0, comm: swapper Not 
tainted 2.6.32-xen-dom0-alt39 #1 IBM eServer x3400-[7976L2G]-
May 15 12:17:05 mainsrv-dom0 kernel: [69672.416912] RIP: e030:
[810093aa]  [810093aa] hypercall_page+0x3aa/0x1010
May 15 12:17:05 mainsrv-dom0 kernel: [69672.416944] RSP: e02b:88003fcadee8  
EFLAGS: 0246
May 15 12:17:05 mainsrv-dom0 kernel: [69672.416959] RAX:  RBX: 
88003fcadfd8 RCX: 810093aa
May 15 12:17:05 mainsrv-dom0 kernel: [69672.416975] RDX:  RSI: 
 RDI: 0001
May 15 12:17:05 mainsrv-dom0 kernel: [69672.416989] RBP: 88003fcadf00 R08: 
 R09: 
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417004] R10:  R11: 
0246 R12: 815a1a20
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417017] R13:  R14: 
 R15: 
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417035] FS:  7f676217e700
() GS:880028054000() knlGS:
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417049] CS:  e033 DS: 002b ES: 
002b CR0: 8005003b
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417063] CR2: 7f020ba76008 CR3: 
3eb75000 CR4: 2660
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417079] DR0:  DR1: 
 DR2: 
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417093] DR3:  DR6: 
0ff0 DR7: 0400
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417108] Call Trace:
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417134]  [81010cc0] ? 
xen_safe_halt+0x10/0x30
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417162]  [8101db20] 
default_idle+0x40/0xb0
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417188]  [81014349] 
cpu_idle+0x79/0xc0
May 15 12:17:05 mainsrv-dom0 kernel: [69672.417215]  [8138c65d] 
cpu_bringup_and_idle+0xe/0x10

И то же самое сообщение для каждого из ядер в это же время. Как это отразилось 
на работе сервера (было ни подвисание на 65 сек) - сказать не могу, не 
следил за ним в это время.


-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] IBM eServer x3400 + Xen 4.1.0 + kernel-image-xen-dom0-alt38

[Alex Moskalenko]

Здравствуйте!

Снова подниму тему о x3400 и kernel-image-xen-dom0. Поставил ядро 
kernel-image-xen-dom0-2.6.32-alt38 (последнее на текущий момент). Система 
загрузилась, но весь лог забит следующими сообщениями:

May 10 17:34:59 mainsrv-dom0 kernel: [   24.070322] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003cabcfa0 to 
8004371c0145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070329] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003cabcfa8 to 
8004ff16a145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070343] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003b91d890 to 
800436c80145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070352] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003b91d898 to 
8004369ad145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070360] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003b91d8a0 to 
8004371bf145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070366] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003b91d8a8 to 
800436944145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070680] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003cca7390 to 
8004376eb145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070699] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003cca7398 to 
800436c8f145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070741] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003cca73a0 to 
800436fac145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070749] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003cca73a8 to 
8004379fe145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070756] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003cca73b0 to 
8004ca839145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070773] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003cca73b8 to 
8004cab2b145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070781] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003cca73c0 to 
8004ceb2f145
May 10 17:34:59 mainsrv-dom0 kernel: [   24.070791] 
arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003cca73c8 to 
800436410145

За 20 минут работы - 15 Мб лога. Сообщения появляются не с постоянной 
периодичностью, а при какой-либо активности в dom0, то есть работа в domU 
сообщений не вызывает. С 2.6.32-alt36.2 этих сообщений нет.

Если требуется какая-либо еще информация, готов ее предоставить.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] [полтергейст] изучаю soft =?utf-8?b?IFJBSUQvTFZN?=, или миграция 5 - 10

[Alex Moskalenko]

On Friday 15 April 2011 16:28:27 Sergey wrote:
 On Friday, April 15, 2011, Sergey wrote:
/dev/md0:
Version : 1.2
 Или, при загрузке, в принципе не поднимается ничего, кроме 0.90 ?!
 А какой у меня на RAID5 был, я не помню. :-(

Здравствуйте!

Из man mdadm:
   --auto-detect
  Request that the kernel starts any auto-detected arrays.  This 
can only work if md is compiled into the kernel — not if it  is a  module.   
Arrays  can  be auto-detected by the kernel if all the components are in 
primary MS-DOS partitions with partition type FD, and all use v0.90 metadata.  
In-kernel autodetect is not recommended for new installations.  Using  mdadm  
to  detect and assemble arrays — possibly in an initrd — is substantially 
more flexible and should be preferred.

То есть, Вы правы, ядро может автоопределять только части массивов, 
находящиеся на дисках с таблицей разделов MS-DOS, на разделе с типом FD и 
метаданными версии 0.90. Остальное автоматически не определится и в массив не 
соберется.

Остается подождать, пока в make-initrd будет реализована поддержка mdadm (в 
планах она есть) - тогда можно будет собирать при загрузке любые типы 
массивов, поддерживаемые mdadm.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] IBM eServer x3400 + Xen 4.1.0 + kernel-image-xen-dom0 = crash

[Alex Moskalenko]

On Wednesday 13 April 2011 20:01:07 you wrote:
 В http://git.altlinux.org/tasks/42643/ собирается ядро, которое должно у
 вас заработать. Как соберётся - можете начинать тестировать.
Спасибо, 2.6.32.2 загрузилось. Устройства вроде бы тоже работают. klogd также 
запускается в чруте от пользователя.

Есть несколько настораживающих сообщений в протоколах загрузки ядра и 
гипервизора, привожу их далее:

гипервизор
(XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 000fec80
(XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 000fec80
(XEN) mm.c:4967:d0 ptwr_emulate: could not get_page_from_l1e()
(XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 000fec80
(XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 000fec80
(XEN) mm.c:4967:d0 ptwr_emulate: could not get_page_from_l1e()

ядро
[0.067405] ACPI: No dock devices found.
[0.067667] HYPERVISOR_update_va_mapping at 0xc9028000 return -22
(ptep=0x88003fc87140 pteval=0x8000fec80473)
[0.067872] arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003fc87140 
to 8000fec80473
[0.068000] set_pte_at 0x88003fc87140 failed 1
[0.068008] ACPI Error: Could not map memory at FEC8, size 100 
(20090903/exregion-180)
[0.068269] ACPI Exception: AE_NO_MEMORY, Returned by Handler for 
[SystemMemory] (20090903/evregion-424)
[0.068533] ACPI Error (psparse-0537): Method parse/execution failed 
[\_SB_.PCI0._CRS] (Node 88003fc83670), AE_NO_MEMORY
[0.068850] ACPI Error (uteval-0250): Method execution failed 
[\_SB_.PCI0._CRS] (Node 88003fc83670), AE_NO_MEMORY
[0.069160] ACPI: PCI Root Bridge [PCI0] (:00)

[0.196719] ACPI: bus type pnp registered
[0.197082] HYPERVISOR_update_va_mapping at 0xc9028000 return -22
(ptep=0x88003fc87140 pteval=0x8000fec80473)
[0.197299] arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003fc87140 
to 8000fec80473
[0.197491] set_pte_at 0x88003fc87140 failed 1
[0.197616] ACPI Error: Could not map memory at FEC8, size 100 
(20090903/exregion-180)
[0.197893] ACPI Exception: AE_NO_MEMORY, Returned by Handler for 
[SystemMemory] (20090903/evregion-424)
[0.198173] ACPI Error (psparse-0537): Method parse/execution failed 
[\_SB_.PCI0._CRS] (Node 88003fc83670), AE_NO_MEMORY
[0.198523] ACPI Error (uteval-0250): Method execution failed 
[\_SB_.PCI0._CRS] (Node 88003fc83670), AE_NO_MEMORY
[0.198845] pnp 00:00: can't evaluate _CRS: 4

[0.215212] PM-Timer failed consistency check  (0x0xff) - aborting.

[0.422136] Freeing unused kernel memory: 548k freed
[0.423725] arch/x86/xen/mmu.c:xen_set_pte:Error setting 88003d6030f0 
to 8004c0564145
[0.438260] input: AT Translated Set 2 keyboard 
as /devices/platform/i8042/serio0/input/input1

[5.593467] scsi 0:1:0:0: Attached scsi generic sg3 type 0
[5.593548] HYPERVISOR_update_va_mapping at 0xe8f1f000 return -22
(ptep=0x88003d1d38f8 pteval=0x800432fd7063)
[5.593560] HYPERVISOR_update_va_mapping at 0xe8f3b000 return -22
(ptep=0x88003d1d39d8 pteval=0x800435c88063)
[5.593570] HYPERVISOR_update_va_mapping at 0xe8f57000 return -22
(ptep=0x88003d1d3ab8 pteval=0x800435dfa063)
[5.593581] HYPERVISOR_update_va_mapping at 0xe8f73000 return -22
(ptep=0x88003d1d3b98 pteval=0x800435df9063)
[5.593591] HYPERVISOR_update_va_mapping at 0xe8f8f000 return -22
(ptep=0x88003d1d3c78 pteval=0x8004356ef063)
[5.593602] HYPERVISOR_update_va_mapping at 0xe8fab000 return -22
(ptep=0x88003d1d3d58 pteval=0x8004356ea063)
[5.593612] HYPERVISOR_update_va_mapping at 0xe8fc7000 return -22
(ptep=0x88003d1d3e38 pteval=0x8004356eb063)
[5.593627] HYPERVISOR_update_va_mapping at 0xe8fe3000 return -22
(ptep=0x88003d1d3f18 pteval=0x8004356ec063)
[5.593725] scsi 0:1:1:0: Attached scsi generic sg4 type 0

[   14.289531] XENBUS: Unable to read cpu state
[   14.289688] XENBUS: Unable to read cpu state
[   14.289849] XENBUS: Unable to read cpu state
[   14.290056] XENBUS: Unable to read cpu state
[   14.290218] XENBUS: Unable to read cpu state
[   14.290396] XENBUS: Unable to read cpu state
[   14.290538] XENBUS: Unable to read cpu state
[   14.290692] XENBUS: Unable to read cpu state

С этим можно жить или лучше подождать?

--
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] IBM eServer x3400 + Xen 4.1.0 + kernel-image-xen-dom0 = crash

[Alex Moskalenko]

On Thursday 07 April 2011 20:19:15 Vitaly Kuznetsov wrote:
  Есть в наличии железка - IBM eServer x3400 (2 4ядерных Xeon, 20 гб
  оперативной
  памяти). Пытаюсь запустить на нем текущие версии Xen и ядра xen-dom0
  из сизифа.
 
  В kernel-image-xen-dom0-2.6.32-alt36 вкралась ошибка, дождитесь
  kernel-image-xen-dom0-2.6.32-alt36.1 (будет сегодня) или откатитесь на
  alt33 из архива (например тут:
  ftp://ftp.altlinux.org/pub/distributions/archive/Sisyphus/2011/04/01/x86_
 64/RPMS.classic/)

 К сожалению этого будет недостаточно. Ядро без гипервизора у вас
 загрузится, с гипервизором - нет. Я попробую разобраться в данной
 проблеме, благо такое железо под руками есть.
Здравствуйте!

Извиняюсь за назойливость, не виден ли свет в конце тоннеля? :) Могу помочь с 
тестированием, если требуется.

Также, похоже что в ядрах xen-dom0 не приложен/отвалился патч для работы klogd 
со стандартными ALT-настройками - не работает он от пользователя в чруте 
(Cannot read proc file system: 1 - Operation not permitted.). Стоит багу 
вешать?

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] IBM eServer x3400 + Xen 4.1.0 + kernel-image-xen-dom0 = crash

[Alex Moskalenko]

On Tuesday 12 April 2011 15:11:04 Vitaly Kuznetsov wrote:
  Также, похоже что в ядрах xen-dom0 не приложен/отвалился патч для
  работы klogd со стандартными ALT-настройками - не работает он от
  пользователя в чруте
  (Cannot read proc file system: 1 - Operation not permitted.). Стоит
  багу вешать?

 Повесьте, пожалуйста. Я проверю.
#25434

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] IBM eServer x3400 + Xen 4.1.0 + kernel-image-xen-dom0 = crash

[Alex Moskalenko]

Здравствуйте!

Есть в наличии железка - IBM eServer x3400 (2 4ядерных Xeon, 20 гб оперативной 
памяти). Пытаюсь запустить на нем текущие версии Xen и ядра xen-dom0 из 
сизифа. Без опции acpi=off получаю стабильное падение ядра dom0, при наличии 
опции acpi=off загрузиться удается, но не работают многие устройства (точнее, 
работают только RAID-контроллер и сетевая карта). Во вложениях два протокола 
загрузки - c acpi=off и без нее.

Так как собственных знаний в области отладки ядра в достаточных количествах не 
имею, прошу помочь разобраться - что и куда можно покопать в этом случае. В 
идеале хотелось бы получить обычную загрузку без acpi=off и других подобных 
подпорок.

Заранее спасибо.

PS Ядро std-def грузится и работает без каких-либо видимых проблем.

-- 
WBR, Alex Moskalenko


minicom.cap.acpi.bz2
Description: BZip2 compressed data


minicom.cap.noacpi.bz2
Description: BZip2 compressed data
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] collectd-openvz и сообщения в vzctl.log

[Alex Moskalenko]

Здравствуйте!

Начал использовать collectd для сбора статистики по OVZ-контейнерам. Система 
сизиф, версии пакетов следующие:
collectd-openvz-4.10.3-alt3
collectd-sensors-4.10.3-alt3
collectd-4.10.3-alt3
collectd-nut-4.10.3-alt3
vzquota-3.0.12-alt2
vzctl-3.0.24.2-alt1
kernel-image-ovz-el-2.6.32-alt14

После включения плагина OpenVZ статистика по контейнерам начала собираться, но 
в файле /var/log/vzctl.log появляется большое количество сообщений следующего 
вида:
2011-04-04T11:36:36+0400 vzctl : CT 11000 : Error in waitpid(3): No child 
processes
2011-04-04T11:36:37+0400 vzctl : CT 11000 : Error in waitpid(3): No child 
processes
2011-04-04T11:36:37+0400 vzctl : CT 11000 : Error in waitpid(3): No child 
processes
2011-04-04T11:36:37+0400 vzctl : CT 11000 : Error in waitpid(3): No child 
processes
2011-04-04T11:36:37+0400 vzctl : CT 11000 : Error in waitpid(3): No child 
processes
2011-04-04T11:36:37+0400 vzctl : CT 11000 : Error in waitpid(3): No child 
processes
2011-04-04T11:36:37+0400 vzctl : CT 11000 : Error in waitpid(3): No child 
processes

Сообщений по 7 штук для каждого контейнера в каждые 10 секунд (согласно 
настройкам collectd - собирать данные раз в 10 секунд и коду OpenVZ.pm - в 
коде как раз 7 вызовов vzctl для каждого из контейнеров). При этом ручное 
выполнение аналогичных команд никакими сообщениями об ошибках не 
сопровождается. Все счетчики отказов в user_beancounters нулевые - то есть 
проблем с ресурсами нет.

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

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] Редактор скрипт ов sieve для конечных польз вателей

[Alex Moskalenko]

Здравствуйте!

Настроил самосборный dovecot 1.2.4 из branch 5.1 в качестве imap-сервера для 
небольшой организации. Система - Server 4.0. В качестве MDA используется 
deliver, который должен с помощью скриптов sieve раскладывать почту 
пользователям по папкам как их душе угодно. Возник вопрос - что использовать 
пользователям в качестве редактора собственных sieve-скриптов? Пользователи 
совсем не продвинутые, в качестве клиентов у них аутлук. :) На данный момент 
пробовал smartsieve из дистрибутива и плагин avelsieve для squirrelmail, 
который используется в качестве webmail. Оба имеют проблему - при создании 
правила с перекладыванием почты в папку с русским названием она фигурирует в 
sieve-скрипте в кодировке imap-UTF7, а deliver ожидает получить название 
папки в UTF-8 (если я правильно понял RFC, то прав deliver).

Соответственно вопрос - кто чем пользуется для предоставления обычным 
Windows-пользователям возможности редактировать собственные sieve-скрипты?

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] ALTLinux+Samba+Windows7

[Alex Moskalenko]

Здравствуйте!

Появилась необходимость использовать рабочие станции с Windows 7 в домене 
Samba 3. С помошью http://wiki.samba.org/index.php/Windows7 машины с Win7 
ввести в домен удалось, но входить на них доменными пользователями не удается 
с диагностикой не удалось установить доверительные отношения между этой 
рабочей станцией и основным доменом.

Согласно тому же http://wiki.samba.org/index.php/Windows7, поддержка Windows7 
добавлена в Samba 3.3 и 3.4. В ALTLinux же присутствует только Samba 3.0.

В связи с этим прошу наставить на путь истинный в соответствии с политикой 
партии Пытаться ли самостоятельно собрать Samba 3.4? Ожидать ли скорого 
обновления уже неподдерживаемой 3.0 в дистрибутивах ALT на 3.3 или 3.4? 
Какие-либо другие варианты? Дистрибутив менять очень бы не хотелось...

Заранее спасибо за ответы.

PS Пишу в samba@ и в sysadmins@, так как в samba@ как-то подозрительно тихо в 
последнее время...

--
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Monit и сервисы без PID-файлов

[Alex Moskalenko]

В сообщении от Wed 30 Apr 2008 00:38:23 Alexey I. Froloff написал(а):
 * Alex Moskalenko mav@ [080429 09:32]:
  Наставьте пожалуйста на путь истинный, как мониторить такие сервисы.

 Любым другим сособом, который поддерживает monit.  Например
 проверять локальный порт.

И все-таки, я не могу понять, каким образом это полноценно реализовать. 
Насколько я понял, проверка доступности соединения в monit возможна только в 
секциях check process и check host. В данном конкретном случае, с hasplm 
(слушает UDP:475) и cupsd (слушает TCP:631) мониторинг еще можно реализовать 
через что-то вроде check host local_cups with address 127.0.0.1 if failed 
port 631 with type tcp then restart, то с процессом aksusbd, который тоже 
хочется мониторить, но который не слушает портов, а работает через сокет, 
такой вариант уже не годится, так как в check host unixsocket не 
поддерживается.

Получается, что реализовать мониторинг процессов, которые неотключаемо 
демонизируются при старте (это к вопросу о возможности запуска через 
start-stop-daemon --background --make-pidfile), не создают собственных 
PID-файлов и не слушают TCP/UDP портов, невозможно?..

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] Monit и сервисы без PID-файлов

[Alex Moskalenko]

Здравствуйте!

Посдкажите пожалуйста, как правильным образом мониторить с помощью monit 
сервисы, не создающие PID-файлов? На данный момент (ALT Linux Server 
4.0+updates+branch) это как минимум cupsd и openntpd из состава дистрибутива, 
плюс менеджер лицензий и демон HASP. Директива check process в monitrc не 
подходит, так как требует указания PID-файла, опция --make-pidfile у 
start_daemon тоже не универсальное решение для демонов, которые форкаются в 
background... 

Наставьте пожалуйста на путь истинный, как мониторить такие сервисы.

Заранее спасибо.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] havp Could not create server

[Alex Moskalenko]

В сообщении от Fri 25 Apr 2008 08:31:50 JaMm написал(а):
 Здравствуйте!
 Установил havp-0.88-alt1 что бы настроить антивирусную проверку по схеме
 user - squid - havp -website.
 Подправил конфиг /etc/havp/havp.conf. При запуске - ошибка:
 service havp start
 Making ramdisk for havp:DONE
 Mounting ramdisk in /var/spool/havp for havp:  DONE
 Starting havp service: Starting HAVP Version: 0.88
 Could not create server (already running?)
 Exiting..
FALIED
 Меня удивила строчка Could not create server (already running?) ведь это
 был первый запуск. ps -e |grep havp ничего, конечно, не дал.
 В /usr/share/readme.alt сказано что существует 3 варианта монтирования
 раздела для временных файлов, как я понял основной момент в опции mandatory
 looks... я отработал все три.
 В конфигах ничего особенного, практически стандартная конфигурация, в логах
 тихо всё.
 Система AltLinux server 4.0.1
 uname -a
 Linux myhost.ru 2.6.18-ovz-smp-alt14 #1 SMP Wed May 2 15:41:15 MSD 2007
 i686 GNU/Linux
 Какие мысли?

Проблема тут совсем не в типах монтирования временного раздела, а в том, что 
havp по умолчанию настроен принимать соединения на порту 8080. Так же на порт 
8080 настроен web-интерфейс alterator'а. Alterator стартует первым и занимает 
порт 8080, соответственно havp стартовать уже не может. Решения - изменить 
порт havp, изменить порт веб-интерфейса alterator или не запускать 
web-интерфейс.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] HASP на ALS 4.0

[Alex Moskalenko]

В сообщении от Friday 28 March 2008 21:31:42 Vladimir Istrati написал(а):
 AM 1. Скачиваете с ftp://ftp.aladdin.com/pub/hasp/new_releases/linux
 AM aksparlnx-1.7_ARCH_.tar.gz
 Понятно  только там сейчас aksparlnx-1.7-i386.tar.gz - оно?
Оно, если ядро у вас 32-битное. Если 64-битное - то надо x86_64.

 AM 2. Устанавливаете kernel-headers-modules для нужного вам ядра.
 Не менее ясно. :)

 AM 3. Собираете модуль для ядра (я собирал руками через make
 Цитата (Install):

 ./build.sh --install

 A kernel module will be installed in the following directory:
 /lib/modules/kernel version/misc


 AM KERNSCR=/lib/modules/KERNEL_VERSION/build kernel26)
 ??\
KERNEL_VERSION == версия ядра, под которое модуль собираете (например 
2.6.18-ovz-smp-alt23)

 AM 4. Копируете получившийся aksparlnx.ko в каталог с модулями Вашего
 ядра. /lib/modules/KERNEL_VERSION/ ?

 AM 5. depmod -a KERNEL_VERSION
Когда-то build.sh --install не находил заголовков ядра и не отрабатывал, 
поэтому по старой памяти собираю модуль через make... и кладу его ручками в 
каталог hasp (вместо misc, куда он устанавливается build.sh). Если сейчас 
build.sh работает - можно и им попользоваться.

 AM 6. Udev'ом автоматически /dev/HardLock не создается, поэтому делаем
 AM mknod /etc/udev/devices/HardLock c 42 0
 В Инструкции - то же. (почти mknod /dev/Hardlock c 42 0 )  :)
Так как у нас udev и /dev создается заново при каждой загрузке, нужно создать 
файл устройства именно в /etc/udev/devices. Кстати, ошибся в имени файла 
устройства - l там маленькая, как в инструкции (Hardlock).

 AM 7. модуль aksparlnx автоматически не грузится, поэтому прописываем его
 AM в /etc/modules
 прописываем ?
Добавляем строчку aksparlnx в /etc/modules, чтоб автоматом его при загрузке 
машины загрузить.

 AM 8. Устанавливаете обвязку в виде aksusbd и hasplm (берутся из архивов
 на том AM же ftp, я взял RPM от RedHat, поправил init-скрипты и разложил
 файлы по AM каталогам.
  поправил init-скрипты и разложил файлы по каталогам - как?
Распаковал RPMки и ручками разложил файлы по соответствующим каталогам. На 
предмет чего правил init-скрипты - не помню (по-моему, на предмет переноса 
бинарников из /sbin в /usr/sbin).

 AM 9. chkconfig aksusbd on; chkconfig hasplm on
 AM 10. modprobe akdparlnx  mknod /dev/HardLock c 42 0 
  akdparlnx - ?
akdparlnx - aksparlnx :)

  mknod /dev/HardLock c 42 0 ? Не mknod /etc/udev/devices/HardLock c
  42 0 ?

 AM service aksusbd start  service hasplm start
Вообще пункт 9 - это для того, чтоб все запустилось без перезагрузки. Можно не 
делать.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] samba 3.0.25 и драйверы принте ров

[Alex Moskalenko]

Здравствуйте!

Обнаружилась непонятная проблема при настройке печати на принтеры Samba.

Имеем домен с контроллером на samba 3.0.25 (ALT Linux Server 4 + updates). 
Клиенты Win2000. На контроллере поднят cups, прописаны принтеры. Самба 
принтеры видит, драйверы для них загружены на сервер (драйверы разные - HP 
1200/1300/1320, Oki, Generic/text only, CUPS test driver,...). Клиенты 
успешно используют эти принтеры, устанавливают с сервера драйверы. 
Единственная проблема - очень долго открываются окна свойств и настроек 
принтеров, подключенных с samba-сервера. При этом под пользователями из 
группы Domain Admins в Event Viewer'е на клиентах на каждое действие с 
окошком свойств появляется сообщение от Print с текстом, что драйверы для 
соответствующего принтера были обновлены со списком файлов драйвера. Судя по 
логам самбы, клиент действительно каждый раз скачивает файлы драйвера с 
сервера. Это вызывает очень долгое открытие окон печати.Файлы на сервере и на 
клиентах одинаковые по размеру/дате/содержимому. Время на сервере и клиентах 
синхронизировано.

Собственно вопрос - почему клиенты считают, что на сервере драйверы новее, чем 
локальная копия, и при каждом обращении копируют их с сервера? Как этого 
можно избежать?

Спасибо.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] Samba 3.0.25 - pdbedit и Logon Home, Logon Drive и т.п.

[Alex Moskalenko]

Здравствуйте!

Просьба направить меня на путь истинный.

Дано: контроллер домена на samba 3.0.25, в smb.conf прописаны logon home, 
logon drive, logon script и т.п. Вопрос в том, что когда в User manager for 
Domains создаешь нового пользователя, то все эти поля (скрипт/диск/профиль) 
оказываются пустыми. Как сделать так, чтобы использовались значения по 
умолчанию из smb.conf? В samba 3.0.14a можно было сделать например 
pdbedit -S  username, после чего соответствующее поле заполнялось согласно 
smb.conf. В 3.0.25 выполнение такой же команды ни к чему не приводит - поля 
остаются пустыми.

Вопрос - каким образом указать, что значения полей logon drive/logon 
home/logon script/... должны вычисляться на основе smb.conf?

PS На этом же сервере есть несколько пользователей, полученных через 
pdbedit -i из smbpasswd. У этих пользователей требуемые поля корректно 
генерируются на основе настроек из smb.conf. У вновь созданных 
пользователей - нет.

Заранее спасибо.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] samba 3.0.25 и драйверы принте ров

[Alex Moskalenko]

В сообщении от Friday 17 August 2007 15:59:47 Aleksey Avdeev написал(а):
   Возможно стоит спросить здесь: [EMAIL PROTECTED]
На samba@ подписан, письмо отправил так же и туда. Пришел ответ, что оно будет 
ожидать проверки модератором. Ждем... :)

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] OpenVPN в OVZ-контейнере + мар шрутизация

[Alex Moskalenko]

В сообщении от Friday 29 June 2007 12:40:51 Alex Moskalenko написал(а):

cut
У меня пакеты из сети OpenVPN не
 выходят за пределы VE с OpenVPN... Совсем не выходят На HN полная
 тишина и на venet0, и на физических интерфейсах... И пропадают они именно
 при переходе из VE в HN, так как на venet0 внутри VE пакеты присутствуют.
 Так что, как мне кажется, об ответах машин из реальной сети пока еще рано
 говорить - у меня и запросов-то нет...
cut

Похоже, проблема описана тут 
http://forum.openvz.org/index.php?t=treeth=1511mid=8389rev=reveal=

Видимо, придется экспериментировать с veth. Похоже, через venet и 
маршрутизацию такого не сотворить, а жаль...

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] OpenVPN в OVZ-контейнере + мар шрутизация

[Alex Moskalenko]

В сообщении от Friday 29 June 2007 10:18:46 Nikolay A. Fetisov написал(а):
 OpenVPN раздаёт клиентам маршрут в сеть 192.168.123.0/24 через сервер
 OpenVPN?
Да, маршрут клиентам отдается и устанавливается.

 На машинах в сети 192.168.123.0/24 маршрут на 192.168.234.0/24 через
 192.168.222.50 отдельно прописан?
Для них этот сервер - default gw, так что можно считать, что прописан.

 Iptables на HN ничего лишнего не режет?
Нет, даже policy в accept установил.

 А в целом, есть подозрение, что назначение контейнеру IP из сетки
 192.168.123.0/24 вопрос снимет. Ну или прописывание отдельно маршрутов
 на клиентах для сети 192.168.234.0/24.
Да вот не похоже... При отсутствии правила iptables для SNAT внутри контейнера 
пакеты ОТ клиентов не покидают его пределы (не наблюдаются на HN venet0), при 
наличии этого правила (SNAT на IP контейнера) - покидают (наблюдаются на всем 
пути их прохождения - tun0 в VPS c адресами клиентов - venet0 в VE прошедшие 
через SNAT с адресом контейнера - venet0 на HN тоже с адресом контейнера - 
eth1 HN - машина в сети) и нормально маршрутизируются, доходят до клиентов и 
т.п. - в общем, при NAT все работает. Если SNAT в VE убрать - то пакеты от 
клиентов наблюдаются только на tun0 в VE (с адресами клиентов) и на venet0 в 
VE (тоже с адресами клиентов). Дальше (venet0 на HN, eth1, ) - тишина, 
пакетов нет.

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] OpenVPN в OVZ-контейнере + мар шрутизация

[Alex Moskalenko]

В сообщении от Friday 29 June 2007 12:28:28 Nikolay A. Fetisov написал(а):
 Да, вот только пакеты от клиентов OpenVPN из сети 192.168.234.0/24 к
 ним приходят не с 192.168.123.1, а с 192.168.222.50.

 Рассматривайте VE c OpenVPN как отдельный хост - все станет намного
 понятнее.

 Без SNAT пакет с машины из сети VPN в локальную сеть проходит через
 шлюз 192.168.222.50. Обратно же локальная машина отсылает его через
 default gateway - отнюдь не на 192.168.222.50.
 Пропишите маршрут на машине в локальной сети на 192.168.222.50 - будет
 работать.

 Когда же внутри VE включён SNAT, то пакеты в локальную сеть приходят от
 192.168.222.50 - и обратно отправляются туда же, а не на 192.168.123.1.
Это все хорошо и правильно. И вполне возможно, я смогу дойти и до этого. 
Оставим пока SNAT внутри VE в сторонке. У меня пакеты из сети OpenVPN не 
выходят за пределы VE с OpenVPN... Совсем не выходят На HN полная тишина 
и на venet0, и на физических интерфейсах... И пропадают они именно при 
переходе из VE в HN, так как на venet0 внутри VE пакеты присутствуют. Так 
что, как мне кажется, об ответах машин из реальной сети пока еще рано 
говорить - у меня и запросов-то нет...

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] OpenVPN в OVZ-контейнере + мар шрутизация

[Alex Moskalenko]

Здравствуйте!

Столкнулся с проблемой при попытке настроить удаленный доступ в локальную сеть 
через OpenVPN в OVZ-контейнере. Итак, дано:

1. Сервер 4.0 с ovz-ядром, несколькими сетевыми интерфейсами. Интерфейс 
локальной сети - 192.168.123.1/24.
2. OVZ-контейнер на этом сервере, сеть через venet, IP контейнера 
192.168.222.50.
3. OpenVPN внутри вышеназванного контейнера, принимающий внешние подключения 
(перенаправляю порт через DNAT из HN). OpenVPN раздает клиентам адреса из 
подсети 192.168.234.0/24.

Хочется получить прозрачную маршрутизацию от клиентов в сеть 192.168.123.0/24.

На HN прописал ip r a 192.168.234.0/24 via 192.168.222.50. Из контейнера сеть 
192.168.123.0/24 видна, контейнер из сети тоже. А вот с клиентов попасть в 
сеть 192.168.123.0/24 не получается. При этом tcpdump показывает пакеты от 
клиента в сеть и на tun0 (openvpn), и на venet0 внутри контейнера. А вот на 
venet0 на HN пакетов уже нет...

Если в правила iptables в контейнере добавить SNAT на venet0, то клиенты 
openVPN в сеть 192.168.123.0/24 попадают, естественно, через этот самый NAT. 
tcpdump показывает пакеты от клиентов на tun0 внутри контейнера и отNATенные 
пакеты на venet0 в контейнере и на HN.

Вопрос собственно простой - можно ли сделать так, чтобы оно работало без NAT?

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

[Sysadmins] tc filter show dev ...

[Alex Moskalenko]

Здравствуйте!

Подскажите пожалуйста, что я делаю не так.

Дано ALT Linux Sisyphus последний, ядро 
2.6.16-std26-smp-alt9, iproute2-2.6.16.20060323-alt1. Хочу попользоваться htb. 
Соответственно, добавляю дисциплины, классы, фильтры. Все отрабатывает без 
ошибок, загружаются соответствующие модули, напротив них в lsmod пишется 
корректное число, сколько раз они используются. Проблема проявляется, когда 
хочу посмотреть, что я там навводил. tc qdisc show dev device и tc class show 
dev device выводят мне соответственно дисциплины и классы. А вот tc filter 
show dev device не выводит ничего. Хотя, как я говорил, нужные модули 
загружены и используются нужное число раз.

Соответственно, вопрос: как посмотреть список фильтров, используемых на 
устройстве? Почему tc filter show dev device ничего не выводит?

Заранее спасибо.

--
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Intel SR-2400 и APC Smart UPS.

[Alex Moskalenko]

В сообщении от 30 июня 2006 17:24 Alexey Borovskoy написал(a):
 Шасси Intel SR-2400 с двумя силовыми модулями по 700 ватт.
 Две бесперебойки APC Smart UPS 1400. По одной бесперебойке на модуль.
 
 Смарты начинают мигать индикатором уровня заряда батарей, что в доке
 описывается как невозможность держать такую нагрузку. Но по
 индикатору видно что нагрузка там около 30 процентов.
 
  Индикация миганием столбика заряда батарей показывает, что текущего
  уровня заряда недостаточно для питания текущей нагрузки в течение
  сколько-нибудь значимого времени. Мигать может и при нагрузке 5%, все
  зависит от состояния батарей. Похоже, что батареи в Ваших ИБП просто
  умерли...

 Новые там батареи, на прошлой неделе менял. Есть еще один комплект
 батарей.
 Или электронике которая батареи заряжает хана пришел?
Попробуйте на досуге откалибровать UPS. Иногда помогает. И попробовать дать 
ему пару циклов разряда-заряда.

PS Правда, одному Smart 700RM это не помогло - был выкинут после 3-го 
безрезультатного ремонта. Ремонтировали там что-то именно в электронике. И 
Smart 6000 DP в примерно таком же состоянии где-то валяется, никак не 
выкинем - тяжелый очень. :) Но в основном замена батарей от такого помогала.


-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins

Re: [Sysadmins] Intel SR-2400 и APC Smart UPS.

[Alex Moskalenko]

В сообщении от 30 июня 2006 17:48 Alexey Borovskoy написал(a):
 Alex Moskalenko пишет:
  В сообщении от 30 июня 2006 17:24 Alexey Borovskoy написал(a):
  Шасси Intel SR-2400 с двумя силовыми модулями по 700 ватт.
   Две бесперебойки APC Smart UPS 1400. По одной бесперебойке
   на модуль.
 
  Смарты начинают мигать индикатором уровня заряда батарей,
  что в доке описывается как невозможность держать такую
  нагрузку. Но по индикатору видно что нагрузка там около 30
  процентов.
 
  Индикация миганием столбика заряда батарей показывает, что
  текущего уровня заряда недостаточно для питания текущей
  нагрузки в течение сколько-нибудь значимого времени. Мигать
  может и при нагрузке 5%, все зависит от состояния батарей.
  Похоже, что батареи в Ваших ИБП просто умерли...
 
  Новые там батареи, на прошлой неделе менял. Есть еще один
  комплект батарей. Или электронике которая батареи заряжает хана
   пришел?
 
  Попробуйте на досуге откалибровать UPS. Иногда помогает. И
  попробовать дать ему пару циклов разряда-заряда.

 А как и чем калибровать? battery.calibrate.start ?
Например так, если дает сделать калибровку при таких батареях.


 При заряде в 100% и прицепленном мониторе в качестве полезной
 нагрузки, заряд батарей падает очень быстро.
При таком раскладе вариантов всего два - изначально мертвые батареи или 
умершая электроника, ответственная за заряд. Какой у него по nut 
battery.voltage в состоянии 100% заряда и какой после разряда процентов до 
20-30? Нет ли возможности зарядить батареи на каком-нибудь другом ИБП (ну или 
какой-нибудь зарядкой для автомобильных аккумуляторов, только чтоб автомат с 
регулировкой максимального тока заряда был)?


 Слышал что при замене батарей на упсах начиная с 1000 VA, надо в
 него какой-то специально обученной прогой лазить. Иначе опознает
 новые батареи как старые.
Есть в nut rw-переменная battery.date, но я всегда считал, что это просто для 
того, чтоб запомнить, когда менялись батареи

-- 
WBR, Alex Moskalenko
___
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins