Собсно стал ленивый и надоело мне вручную (пусть и скриптом) подписывать зоны, решил попробовать новомодную фишку в бинде, автоподпись.

dnssec включен:

...
    dnssec-enable yes;
    dnssec-validation yes;
    dnssec-lookaside auto;
...
zone "domain.ru" {
    type master;

    auto-dnssec maintain;
    inline-signing yes;
    update-policy local;
    key-directory "dnssec-keys/domain.ru";
    
    file "master/domain.ru.zone";
};

Ключи в dnssec-keys/domain.ru положены. При запуске оно пишет что всё зашибись, ща полетаем!

25-May-2012 16:40:44.996 zone domain.ru/IN (unsigned): loaded serial 2012052502
25-May-2012 16:40:44.996 zone domain.ru/IN (signed): loaded serial 2012052502
25-May-2012 16:40:44.998 all zones loaded
25-May-2012 16:40:44.998 running
25-May-2012 16:40:44.998 zone domain.ru/IN (signed): receive_secure_serial: unchanged
25-May-2012 16:40:44.998 zone domain.ru/IN (signed): reconfiguring zone keys
25-May-2012 16:40:44.999 zone domain.ru/IN (signed): next key event: 25-May-2012 17:40:44.998
25-May-2012 16:40:44.999 zone domain.ru/IN (signed): sending notifies (serial 2012052502)

Но при попытке энтот днссек проверить:

# dig domain.ru +dnssec @127.0.0.1

Оно мне выдает обычный, не подписаный, днс ответ. Хотя с боевого сервера, где крутится куча зон, подписанных по-дедовски, выдает всё как надо, с RRSIG-ами и танцовщицами.

В логах при этом ничего вразумительного не пишет, просто запрос:

25-May-2012 16:41:50.914 client 127.0.0.1#37193 (domain.ru): query: domain.ru IN A +ED (127.0.0.1)

Бинд 9.9.1

Куда копать. товарисчи?

Всякие файлы типа domain.ru.singed, domain.ru.jbd и т.п. оно создает.

Есть девайс ALIX на GeodeLX, на нём дебиан тестинг обычный i386 на компакт-флеш карточке.

Ядро самопальное.

Так вот, иногда после того как я соберу новоя ядро, положу его в /boot и перезагружусь, то GRUB выдаёт сабж.

Помогает «cp /boot/vmlinuz-x.x.x / && rm /boot/vmlinuz-x.x.x && mv /vmlinuz-x.x.x /boot», т.е. у граба какие-то проблемы с определением геометрии ФС и положения ядра на ней, ФС ext4. А после того как погоняешь его туда-сюда, всё встает на место. Может оно фрагментируется, хз, места там дофига (13гб)

Гугль про эту ошибку говорит мало, документирована она слабо. Может сталкивался кто?

В общем, появилась необходимость подключить проблемное место одно к общей сети. Связь есть только через йоту.

Вся сеть построена на сабже, поэтому хотелось однообразно подключить и этот объект. Нарыл проект OpenNHRP, который как раз и реализует недостающую часть стека протоколов DMVPN (IPSEC + NHRP + mGRE), плюс Racoon.

Всё вроде как завелось, хотя ракун IPSEC фазу 2 с цыской устанавливает как-то тяжело, не с первого раза, и периодическ ругается «ERROR: invalid flag 0x08».

Ну это ладно, я просто в скрипте долблю его до победного конца, с 2-3 попытки встает. Дальше вступает в дело OpenNHRP, регистрируется на цыске, всё хорошо. Траффик начинает ходить по туннелю:

Apr  5 15:10:03 kadashi opennhrp[1641]: Interface lo: new or configured up, mtu=16436
Apr  5 15:10:03 kadashi opennhrp[1641]: Interface eth0: new or configured up, mtu=1500
Apr  5 15:10:03 kadashi opennhrp[1641]: Interface eth1: new or configured up, mtu=1500
Apr  5 15:10:03 kadashi opennhrp[1641]: Interface gre0: new or configured up, mtu=1476
Apr  5 15:10:03 kadashi opennhrp[1641]: Interface gre1: new or configured up, mtu=1472
Apr  5 15:10:03 kadashi opennhrp[1641]: Interface gre1: GRE configuration changed. Purged 1 peers.
Apr  5 15:10:03 kadashi opennhrp[1641]: Adding local 10.254.254.18/32 dev gre1
Apr  5 15:10:03 kadashi opennhrp[1641]: Adding local 10.254.254.255/32 alias 10.254.254.18 dev gre1
Apr  5 15:10:03 kadashi opennhrp[1641]: Filter code installed (19 opcodes)
Apr  5 15:10:10 kadashi racoon: WARNING: attribute has been modified.
Apr  5 15:10:11 kadashi opennhrp[1641]: [10.254.254.1] Peer up script: success
Apr  5 15:10:11 kadashi opennhrp[1641]: NL-ARP(gre1) 10.254.254.1 is-at x.x.x.x
Apr  5 15:10:11 kadashi opennhrp[1641]: Sending Registration Request to 10.254.254.1 (my mtu=0)
Apr  5 15:10:11 kadashi opennhrp[1641]: Sending packet 3, from: 10.254.254.18 (nbma 10.0.0.10), to: 10.254.254.1 (nbma x.x.x.x)
Apr  5 15:10:11 kadashi opennhrp[1641]: Received Registration Reply from 10.254.254.1: success
Apr  5 15:10:11 kadashi opennhrp[1641]: NAT detected: our real NBMA address is 94.25.147.132
Apr  5 15:10:11 kadashi opennhrp[1641]: Sending Purge Request (of local routes) to 10.254.254.1

Но через какое-то небольшое время всё умирает. Спасает убийство туннеля и установка заново. Сначала грешил на связь, но потери пакетов нет, пинги 100-200 и OpenVPN по этому же каналу работает на ура, так что приходится пока сидеть на нём.

Есть у кого опыт борьбы с этой штукой? :)

ЗЫ: Пробовал и без НАТа между хостами, разницы никакой.

В продаже в основном идут на базе чипов реалтек или ралинк, с которыми я бы хотел связываться только в крайнем случае. Может есть что-то на Atheros? (CARL_9170, ATH9k_HTC)?

Собсно есть bond0, состоящий из 4 интерфейсов. На этот bond0 навешано, допустим, 4 айпишника.

Я хочу чтобы, к примеру, отправка пакетов с первого айпишника шла только через eth0, со второго - через eth1 и так далее.

Скурив bonding.txt я так и не понял как такое реализовать.

Есть идеи?

Как вариант - привязывать не айпишники к интерфейсам, а вланы, тоже было бы окей. bond0.0 -> eth0, bond0.1 -> eth1...

ЗЫ: Нужно это для корректной балансировки iSCSI

День добрый.

Вопрос не только и не столько по линуксу, но надеюсь мне кто-нибудь поможет.

Дано: Linux сервер в качестве iSCSI таргета (SCST), свищЪ цыско 3750X, VMWare ESXi 5.0 в качестве инициатора iSCSI:

Схема простая (на деле инициаторов больше, но для простоты один):

[ LINUX ] <--- 4 x 1G bonding ---> [ Catalyst 3750-X ] <--- 4 x 1G bonding ---> [ ESXi ]

Со стороны инициатора iSCSI-таргет видится как раз через эти 4 адреса и настроен Multipath I/O для аггрегации каналов.

Проблема: ускорение работы iSCSI получаю только при записи на таргет, а при чтении выше 110MB/s никак получить не могу:

root@debian-service:/# dd of=/dev/sdb if=/dev/zero bs=16M count=1024
1024+0 records in
1024+0 records out
17179869184 bytes (17 GB) copied, 68.1552 s, 252 MB/s

root@debian-service:/# echo 3 > /proc/sys/vm/drop_caches

root@debian-service:/# dd if=/dev/sdb of=/dev/null bs=16M count=1024
1024+0 records in
1024+0 records out
17179869184 bytes (17 GB) copied, 156.66 s, 110 MB/s

При этом траффик равномерно распределяется между интерфейсами как на линуховом таргете, так и на цыске, которая разбрасывает пакеты в порты, к которым подключен ESXi:

stack.3750x#sh int gi1/0/16 | i packets output
     3999028 packets output, 6024197158 bytes, 0 underruns
stack.3750x#sh int gi2/0/16 | i packets output
     3999193 packets output, 6024212765 bytes, 0 underruns
stack.3750x#sh int gi1/0/10 | i packets output
     4017750 packets output, 6038267108 bytes, 0 underruns
stack.3750x#sh int gi2/0/10 | i packets output
     3999012 packets output, 6024197456 bytes, 0 underruns

Т.е. алгоритм балансировки вроде как работает, но почему-то в одном направлении всё-таки появляется затык в 1Гбит/cек.

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

Товарисчи!

Имеются два сервера, один железный, второй виртуальный. На обоих стабильный дебиан с самопальными ядрами, на виртуальнике 2.6.32.55, на реальном 3.0.24.

Pacemaker из бэкпортов последний (1.1.6).

Проблема - на железном сервере сабж работает *хреново*.

Кластер вроде как собирается, ноды друг друга видят, но на железном сервере, к примеру, не удается создать ресурс, crm тупо зависает.

И даже если ничего не делать, то попытка остановить pacemaker вызывает у него ступор, какой-то из субпроцессов (crmd, lrmd, ...) получает 15 сигнал от пейсмейкера, но не выходит и висит вечно, пока его по -9 не убьешь.

На виртуальнике с древнючим ядром таких проблем нет. Всё стартует-останавливается и ресурсы лепятся как надо.

Конфиги идентичные.

Что я делаю не так? Это какая-то несовместимость сабжа с 3 ядром? Или я какую-то хитрую фичу забыл в ядре врубить?

Откатываться назад очень не хотелось бы, т.к. железо в сервере новое (Xeon E3).

Завтра, если не будет свежих мыслей, попробую 2.6.39.4...

Дано - два embedded девайса, между которыми нужно поднять простенький ip-in-ip туннель безо всяких излишество вроде шифрования и компрессии.

По логике выбрал ядерный ipip модуль, сделал туннель, всё окей. Только вот скорость по туннелю уменьшилась более чем в два раза (250mbit -> 110mbit), по сравнению с прямой связью между хостами. Понятно что эмбеддед, но я не думал что простая инкапсуляция настолько его напряжёт. Может есть что-то более эффективное? (хотя я сомневаюсь)

Дано - распределенная сеть из нескольких *, соединены по OpenVPN + OSPF. Надо - звонить клиентам одного * другому * через сип-транки. IAX не предлагать :) Причем, RTP в идеале гонять напрямую (вроде directmedia=yes это дает в * и сейчас оно дефолтное).

Загвоздка: Допустим на сервере *1 есть внутренний интерфейс 192.168.22.1/24, на который вешаются клиенты. И есть несколько туннелей, один из которых, 192.168.254.34, ведёт в сторону нужного нам пира (сип-транк).

В sip.conf помимо прочего:

nat=no
directmedia=yes

bindport=5060
bindaddr=192.168.22.1

При попытке с телефона позвонить через сип-транк на дальнем конце имеем:

chan_sip.c:20195 handle_request_invite: Failed to authenticate device "IP Phone 1" <sip:200@192.168.254.34:5060>;tag=as0f4bb382

ЧЯДНТ?

С какого-то момента, после обновления скорее всего, бакула стал странные ошибки выдавать при проверке бэкап-джоба. Сам бэкап проходит нормально, в нем вроде как есть все нужные файлы (34 файла + сама директория в которой они лежат, итого 35).

Клиент, который бэкапится, виндовый. Версия директора и клиента совпадает.

Но проверка выдает:

09-Feb 15:18 backup-dir JobId 9352: Error: Bacula backup-dir 5.2.5 (26Jan12):
  Build OS:               x86_64-pc-linux-gnu gentoo 
  JobId:                  9352
  Job:                    sql-verify.2012-02-09_15.01.02_27
  FileSet:                sql
  Verify Level:           VolumeToCatalog
  Client:                 sql
  Verify JobId:           9351
  Verify Job:             
  Start time:             09-Feb-2012 15:01:04
  End time:               09-Feb-2012 15:18:18
  Files Expected:         36
  Files Examined:         35
  Non-fatal FD errors:    0
  FD termination status:  OK
  SD termination status:  OK
  Termination:            *** Verify Error ***

list files jobid=9351 выдает список из 35 файлов, но в таблице столбец JobFiles = 36 И после выполнения бэкап-джоба выдает:

...
  FD Files Written:       36
  SD Files Written:       36
...

А то * у меня на роутере в OpenWRT жрёт половину оперативки (13Мбайт) с почти минимумом модулей. OpenWRT искаропки умеет Freeswitch, Kamailo, OpenSER, OpenSIPS, Yate. Кого выбрать? Фичей мне особо не надо, сип транки разве что, кодеки стандартные.

Задача такая - синхронизировать OpenLDAP с Active Directory в одностороннем порядке, т.е. иметь что-то вроде локального кеша AD. Причем т.к. схема AD отличается от нормальной, хотелось бы иметь возможность преобразовывать имена аттрибутов (TelephoneNumber -> Phone и т.п.).

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

Может есть какие-то более красивые решения?

Есть два хоста, один за NATом. Соеденины тупым OpenVPN со статическими ключами.

Сервер:

dev tap0
proto udp
port 1194
topology subnet

mlock
nice -19
fast-io

ifconfig 192.168.254.17 255.255.255.252

mtu-disc maybe
tun-mtu 1500
fragment 1400
mssfix 1400

keepalive 10 120

secret auth.key

auth RSA-SHA1
cipher AES-256-CBC
comp-lzo

user root
group root

Связь работает, вроде бы даже без лагов, но сервер в логи срёт сабж постоянно и много. ЧЯДНТ?

Причем туннелей есть еще несколько с сервера на другие хосты с аналогичным конфигом, там таких проблем нет.

Собственно есть некая зона, домен 3 уровня, которая обновляется динамически. Она делегирована из домена 2 уровня, который подписан DNSSECом со всеми плюшками. Задача - резолвить динамическую зону снаружи с днссеком. Сейчас, когда она не подписана, резолверы с DNSSECом ругаются на insecurity proof и не выдает ничего.

Как мне организовать переподпись зоны при динамических апдейтах через dhcpd? Я так и не нашел ни одного внятного хау-ту на эту тему.

Собсно у меня named резолвит tp.internet.beeline.ru напрямую через ДНСы билайна так:

zone "beeline.ru" IN {
    type forward;

    forwarders {
        213.234.192.8;
        85.21.192.3;
    };

    forward only;
};

Есть клиент-серверная сеть OpenVPN на tun-интерфейсах. Хочется поднять на ней ospf.

Поднял ospfd на сервере и на клиенте:

hostname host1/2
password zebra
enable password zebra

router ospf
    network 192.168.111.0/24 area 0

log file /var/log/quagga/ospfd.log

# sh ip ospf neighbor

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
192.168.111.1      1 Init/DROther      38.248s 192.168.111.1   tun0:192.168.111.6       0     0     0

# tcpdump -i tun0 'proto ospf'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
00:17:39.094734 IP 192.168.111.1 > ospf-all.mcast.net: OSPFv2, Hello, length 44
00:17:44.298262 IP 192.168.111.6 > ospf-all.mcast.net: OSPFv2, Hello, length 48
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

В системе есть несколько разных массивов, первый - md0 - зеркало для системы с метаданными 0.9, чтобы ведро его определяло до монтирования корня. Остальные 4 штуки (в т.ч. свап) - с нормальными метаданными 1.2, которые ядром не детектируются. Эти массивы прописаны в /etc/mdadm.conf:

DEVICE partitions

AUTO 1.x

ARRAY /dev/md/SWAP metadata=1.2 UUID=3d1a7f26:75aa4576:1bcaeb48:6361c7bd name=artek:SWAP
ARRAY /dev/md/RAID1_380GB metadata=1.2 UUID=7292b16b:0637aa38:e4d06c1b:68643d97 name=artek:RAID1_380GB
ARRAY /dev/md/RAID6_1800GB metadata=1.2 UUID=85324e50:f0256980:b40635d3:c4cbba36 name=artek:RAID6_1800GB bitmap=/var/lib/md3_bitmap
ARRAY /dev/md/RAID6_9TB metadata=1.2 UUID=501fff10:41bbc61d:0f2234c0:1e43292f name=artek:RAID6_9TB bitmap=/var/lib/md4_bitmap

Хз в какой раздел писать, спрошу тут.

Юзерам в компании часто нужно передать какому-то контрагенту большой объем информации (какие-либо макеты, к примеру), объемом в гигабайт и более.

Сейчас проблема решается через FTP для страждующих, но палить аккаунты, пусть и временные, наружу не хочется, да и вообще неудобно, тем более некоторые деятели не могут даже ссылку вида ftp://user:pass@server.ru осилить.

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

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

Напишу сам, но мало ли есть такое готовое?

Вопрос скорее теоретический, т.к. параноей не страдаю. Есть работающий сабж, кейтаб сгенерирован с шифрованием RC4-HMAC-NT.

Сейчас планируется переход на новый домен на Win2K8R2, клиенты все будут Win7. Решил попробовать отключить в домене неправославный RC4 и оставить для кербероса только AES256-SHA1. Всё что связано с взаимодействиями винды с АД работает хорошо, тикеты генерируются с AES.

Сгенерировал кейтаб для сквида с AES, через kinit -kt keytab HTTP/squid.domain.lan@DOMAIN.LAN авторизация проходит, по klist -e вижу что всё как надо:

# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/squid.domain.lan@DOMAIN.LAN

Valid starting     Expires            Service principal
12/02/11 11:06:59  12/02/11 21:07:04  krbtgt/DOMAIN.LAN@DOMAIN.LAN
        renew until 12/03/11 11:06:59, Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC

# cat /etc/krb5.conf
...
    default_tgs_enctypes = aes256-cts-hmac-sha1-96
    default_tkt_enctypes = aes256-cts-hmac-sha1-96
    permitted_enctypes = aes256-cts-hmac-sha1-96
...

Куда копать? Винда виновата? IE? Сквид? mit-krb5?

ЗЫ: Вот тут вроде как подразумевается работа AES: http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos

Есть сквид для виндовых клиентов с прозрачной авторизацией через керберос. Всё в общем-то работает, но вот сейчас, к примеру, один пользователь (из ~150) по какой-то причине не авторизуется:

2011/11/30 16:01:07| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. '
2011/11/30 16:01:07| squid_kerb_auth: INFO: User not authenticated
2011/11/30 16:01:07| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. '
2011/11/30 16:01:07| squid_kerb_auth: INFO: User not authenticated
2011/11/30 16:01:07| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. '
2011/11/30 16:01:07| squid_kerb_auth: INFO: User not authenticated
2011/11/30 16:01:07| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. '
2011/11/30 16:01:07| squid_kerb_auth: INFO: User not authenticated
2011/11/30 16:01:07| squid_kerb_auth: INFO: User not authenticated
2011/11/30 16:01:07| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. '
2011/11/30 16:01:07| authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information. '
2011/11/30 16:01:07| squid_kerb_auth: INFO: User not authenticated

Да, еще иногда выдает:

authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH received type 1 NTLM token'