Здравствуйте.
На постмастера приходит куча всякого мусора, но не всё из этого — спам. Хочется утилиту, которая может подключиться по IMAP, просканировать выделенный подкаталог с сообщениями об ошибках, собрать статистику и выдать результат для, скажем, тех заданных сообщений, которые повторяются 2-3 раза и более, чтобы на них уже обратил внимание администратор.
Возможно, такая тулза уже есть и я про неё не знаю.
Здравствуйте, уважаемые специалисты по всему!
Я хочу себе с одной стороны — планшетку, на которой можно в дороге читать книжки, лазить по Сети и прочее. С другой стороны, к этой планшетке нужна клавиатура, чтобы также, в дороге, можно было подключиться к какому-нибудь серверу по SSH и поработать над исправлением проблем или, просто, чтобы чатиться с кем-нибудь.
Таковым требованиям удовлетворяют ноутбуки/нетбуки с поворотным сенсорным экраном. Поскольку мне ноутбук не нужен из-за излишний мощности и стоимости, будет достаточно нетбуков.
Хотелось бы иметь у такой железки помимо всяких встроенных Wi-Fi, BT ещё и 3G модем, чтобы не подключать внешний.
Выбор моделей, как показал гугль, не самый большой: есть Lenovo IdeaPad S10-3t с ёмкостным экраном, почти идеальный, если верить обзорам, но без 3G модема, хотя некоторые модели имеют встроенный Wimax.
Есть ещё Asus Eee PC T101MT. Ничего, кажется особенного, отличающегося от Lenovo, разве что процессор Atom n450, а не Atom n470, как у первого.
Lenovo продают за цену от 20 т.р. за версию n450, с n470 не нашёл в price.ru; Asus — от 15 т.р.
Итак, вопросы: где можно купить Lenovo n470? Имеет ли смысл брать его, а не Asus? Какие ещё нетбуки с похожими характеристиками, но с тем, что отсутствует у Lenovo посоветуете? Есть ли проблемы с работой Lenovo под Linux?
Linux тут при том, что я поставлю его на купленный нетбук, скорее всего в качестве DE попробую Gnome 3 — посмотрим, как оно будет на планшете себя вести.
Заранее спасибо за ответы.
Здравствуйте.
Существует необходимость удалённого доступа к консолям и мониторам 6 серверов, а также, для локальных администраторов доступ ко всем этим серверам без подключения 6 комплектов клавиатур, мышей, мониторов. Предложениями завален весь гугль.
Подскажите, пожалуйста, с какими IP-KVM вы посоветовали бы связываться, а с какими — нет, с какими меньше всего проблем при запуске панели управления под линуксом.
Нужен только свитч: монитор, клавиатура и мышь имеются отдельные.
Весь вечер ковыряюсь и никак не могу увидеть, в чём затык.
Есть хост A. На нём настроен мост
# brctl show br3
bridge name bridge id STP enabled interfaces
br3 8000.00259005540c yes bond1.3
vnet0в котором bond1.3 — интерфейс хоста, vnet0 — интерфейс виртуальной машины V.
V пингуется с любого внешнего хоста и пингует любой внешний хост. Если же пытаешься подключиться к V на любой из прослушиваемых портов:
# netstat -lnap
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 3697/slapd
tcp 0 0 0.0.0.0:56575 0.0.0.0:* LISTEN 3639/rpc.mountd
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 3697/slapd
tcp 0 0 0.0.0.0:35654 0.0.0.0:* LISTEN 3583/rpc.statd
tcp 0 0 0.0.0.0:33863 0.0.0.0:* LISTEN 3639/rpc.mountd
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 3569/rpcbind
tcp 0 0 0.0.0.0:57936 0.0.0.0:* LISTEN 3639/rpc.mountd
tcp 0 0 0.0.0.0:37109 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3715/sshdто получаем облом, за исключением случая, когда соединяться пытаются с хоста A.
Вот так выглядит облом на V:
# tcpdump -i eth0 -n 'host 192.168.1.210'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
04:04:01.980335 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 64614 0,nop,wscale 8>
04:04:04.990534 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 64915 0,nop,wscale 8>
04:04:11.000494 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 65516 0,nop,wscale 8>А вот так на том хосте, с которого пытаются соединиться, B:
# tcpdump -i br3 -n 'host 192.168.1.122 '
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br3, link-type EN10MB (Ethernet), capture size 96 bytes
04:04:03.852997 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 64614 0,nop,wscale 8>
04:04:06.862985 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 64915 0,nop,wscale 8>
04:04:12.872983 IP 192.168.1.210.40741 > 192.168.1.122.636: S 1326115610:1326115610(0) win 18236 <mss 9118,sackOK,timestamp 65516 0,nop,wscale 8>Вот так выглядит соединение с хоста A:
tcpdump -i br3 -n 'host 192.168.1.122 and tcp port 636'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br3, link-type EN10MB (Ethernet), capture size 96 bytes
04:07:42.502219 IP 192.168.1.209.60449 > 192.168.1.122.636: S 3713155501:3713155501(0) win 18236 <mss 9118,sackOK,timestamp 122580 0,nop,wscale 8>
04:07:42.502454 IP 192.168.1.122.636 > 192.168.1.209.60449: S 3882010051:3882010051(0) ack 3713155502 win 14480 <mss 1460,sackOK,timestamp 1089495 122580,nop,wscale 4>
04:07:42.502500 IP 192.168.1.209.60449 > 192.168.1.122.636: . ack 1 win 72 <nop,nop,timestamp 122580 1089495>
04:07:44.911105 IP 192.168.1.209.60449 > 192.168.1.122.636: F 1:1(0) ack 1 win 72 <nop,nop,timestamp 122821 1089495>
04:07:44.911807 IP 192.168.1.122.636 > 192.168.1.209.60449: F 1:1(0) ack 2 win 905 <nop,nop,timestamp 1091904 122821>
04:07:44.911841 IP 192.168.1.209.60449 > 192.168.1.122.636: . ack 2 win 72 <nop,nop,timestamp 122821 1091904>
На мост br3 хоста A отлично соединяется любой внешний хост. Проблема появляется именно тогда, когда пытаешься соединиться с той частью, которая относится к V. Пересмотрел всё: ядро
CONFIG_BRIDGE=y
CONFIG_BRIDGE_IGMP_SNOOPING=yiptables -L -nv
Chain INPUT (policy ACCEPT 54417 packets, 87M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 10654 packets, 798K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 42428 packets, 10M bytes)
pkts bytes target prot opt in out source destinationebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPTПроблема, кажется, с tcp, т.к. udp (например, dns) работает с того же хоста, с которого не проходят tcp. Очень странно. Можно было бы грешить на управляемый свитч между хостами, но соединения с хостов за пределами этого свитча на хост A проходят, как писал уже.
В каком направлении ещё можно посмотреть?
Сегодня, во время работы, резко пропала возможность соединиться по SSH как со шлюзом, так и с компьютерами внутри сети через openvpn.
При попытке подключиться к шлюзу я получаю вот это:
ssh connuser@host.ru -i .ssh/work_id_dsa -Cvvv
OpenSSH_5.8p1-hpn13v10, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to host.ru [ww.xx.yy.zz] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load ".ssh/work_id_dsa" as a RSA1 public key
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file .ssh/work_id_dsa type 2
debug1: identity file .ssh/work_id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13v10lpk
debug1: match: OpenSSH_5.8p1-hpn13v10lpk pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1-hpn13v10
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "host.ru" from file "/home/me/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/me/.ssh/known_hosts:21
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
debug2: kex_parse_kexinit: zlib@openssh.com,zlib,none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com
debug2: mac_setup: found hmac-md5
debug1: REQUESTED ENC.NAME is 'aes128-ctr'
debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: se:rv:er:ke:y
debug3: load_hostkeys: loading entries for host "host.ru" from file "/home/me/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/me/.ssh/known_hosts:21
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "ww.xx.yy.zz" from file "/home/me/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/me/.ssh/known_hosts:21
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'host.ru' is known and matches the ECDSA host key.
debug1: Found key in /home/me/.ssh/known_hosts:21
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: .ssh/work_id_dsa (0xb788d7c0)
debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering DSA public key: .ssh/work_id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
Connection closed by ww.xx.yy.zzКак видно, соединение устанавливается, но после посылки публичного ключа сервер не отвечает. Поскольку для ssh стоит автобан по количеству соединений в единицу времени, а зайти на него иначе, чем с использованием ключа нельзя, версию с идущей атакой на ssh, пожалуй, можно отклонить.
И ладно бы, такое наблюдалось только со шлюзом, можно было бы списать на какие-то проблемы, которые разрешатся после появления в серверной тех, кто живёт в том городе.
Проблема ещё и в том, что несмотря на работающее впн-соединение, пингующиеся внутренние хосты, работающее соединение на ssh через telnet как к внутренним хостам, так и к шлюзу снаружи и внутри, в итоге получается то, что выше, когда пытаешься соединиться с этими внутренними хостами.
Какие могут быть диагнозы на данный момент? Мне, скажем, приходит в голову разве что проблема с активным оборудованием, потому что слишком резко пропали все эти соединения и некоторые хосты, которые висят на этом оборудовании, недоступны и через пинг.
Но тогда почему и шлюз ведёт себя абсолютно также? Ничего не понимаю.
Здравствуйте.
Для организации могу поднять сеть с нуля, с учётом возможного расширения, поднять необходимые сервисы, типа email,proxy,firewall,file server,web,etc. Всё это возможно связать там, где необходимо, через единую базу пользователей в LDAP, а если понадобится связать филиалы и основной офис, то и это возможно через openvpn.
Также, могу администрировать веб-сервера, поддерживать безопасность, настраивать их и т.п. Очень хочется поработать в команде, занимающейся высоконагруженными проектами, получить опыт.
Стоимость зависит от объёмов работ и их характера (удалёнка, постоянная, разовая, etc).
Контакт можно наладить через JID: farataa@jabber.ru или электропочту somebody.trust@yandex.ru
Добрый день.
Часто возникает нужда в выводе текста в две колонки таким образом, чтобы первая прижималась к левому краю, вторая — к правому и при этом промежуток между ними заполнялся пробелами автоматически.
Такое можно получить с помощью следующей записи:
Text1 \hfill Text2На первый взгляд всё прекрасно, однако, если Text1 и/или Text2 слишком длинные, то они начинают смешиваться, промежуток между ними пропадает и всё становится некрасиво. Более того, если таких строк много и они идут друг за другом, то гораздо правильнее и удобнее использовать таблицы:
\begin{table}[ht]
\centering
\begin{tabular}{|p{3cm}|c|p{3cm}|}
text1 & \hfill & text2
\end{tabular}
\end{table}По идее, такой код (выделение границ колонок сделано временно, для определения их местоположения) должен давать то, что надо: первая и последняя колонки фиксированной ширины. Если в них текст шире, чем следует, то TeX автоматически его переносит в пределах колонки. Средняя колонка должна при этом расширяться до максимума, давая тот же эффект, что и код выше, однако, этого не происходит.
Можно ли добиться от табличного окружения требуемого вывода и как это сделать? Или существуют иные способы получить нужный результат?
Здравствуйте.
Я могу делать следующее:
За вышеописанное полагаю разумной оплату от 60 тыс. руб. ежемесячно. Интересна работа в области распределения нагрузки, серьёзные задачи.
Связаться со мной можно так:
Здравствуйте.
Помню, мне уже говорили, что DRBD — отстой. Что же, пришлось в этом самому убедиться.
# drbdadm -V
DRBDADM_BUILDTAG=GIT-hash:\ 5c0b0469666682443d4785d90a2c603378f9017b\ build\ by\ @nd1\,\ 2011-07-27\ 21:00:20
DRBDADM_API_VERSION=88
DRBD_KERNEL_VERSION_CODE=0x08030a
DRBDADM_VERSION_CODE=0x08030a
DRBDADM_VERSION=8.3.10на нодах.
В какой-то, совершенно случайный момент, напрочь зависает вторичная нода, независимо от того, на каком из двух идентичных хостов она будет находиться.
Зависает внезапно, никакого(!) выхлопа в логах нет, я пытался оставлять хост работающим так, чтобы было видно возможный лог на экране перед его смертью, не говоря уж о записи на диск. Зависает напрочь, даже Magic Keys не работают.
Я пытался менять тип агрегированного соединения между хостами: с balance-rr на 802.3ad. Менял скорости соединения: снижал до невысокого значения. Однако, ничто не помогает. Если бы хоть в логи что-нибудь писалось, то, возможно, что-то и решилось бы.
Ядро используется 2.6.39-gentoo-r3.
Вопросы следующие: какое из новейших ядер сможет работать стабильно? Какие у вас используются?
Есть ли альтернативы DRBD, могущие в работать в режиме Primary/Secondary и синхронизирующие блочные(!) устройства?
Здравствуйте.
Тестировал реализацию сабжа в виде iscsitarget. В кластере хотя бы раз в сутки случается вот такая кака (на самом деле, с любым LUN, этот для примера):
iSCSI-VM-LUN6: migration-threshold=1000000 fail-count=1lrmd: [22931]: info: RA output: (iSCSI-VM-LUN6:monitor:stderr) grep: /proc/net/iet/volume: No such file or directory
crmd: [22934]: info: process_lrm_event: LRM operation iSCSI-VM-LUN6_monitor_10000 (call=139, rc=7, cib-update=158, confirmed=false) not running
…Забавно, что другие LUN на том же target работают без проблем. Более того, проблемный LUN может быть даже не нагружен, в смысле, на нём вообще ничего не работает, он просто в сеть светит. Но может и с рабочим такое произойти, да.
Ещё, неприятных эмоций добавляет то, что версия iscsitarget-1.4.20.2 из официального репозитория не собирается с новыми ядрами. Приходится ставить версию из свн. Патченный 1.4.20.2 собирается, но ВМ не определяют нормально диски, которые тогда отдаются.
Мой взор обращается на tgt.
Вопрос: как у вас с этим решением, народ? Стабильно? Нет? Какие-то проблемы?
Имеется два хоста с четырёхъядерным Intel(R) Xeon(R) CPU X3430 @ 2.40GHz на борту у каждого. 16 Гб RAM. Быстрый SAS-контроллер. Между собой соединены сетевыми картами Intel 82576 GN через четыре агрегированных в один канал интерфейса. Алгоритм balance-rr.
Тесты на скорость проводится так:
1. Создаём на tmpfs-разделе файл:
dd if=/dev/urandom of=/var/tmp/test.raw bs=128k count=80002. Готовый файл пишется в указанное место, изменяется только устройство, монтируемое к /mnt/drbd/ :
dd if=/var/tmp/test.raw of=/mnt/drbd/test.raw bs=128k count=8000 'oflag=direct'Скорость сетевого соединения, померенная iperf: 453000 КБ/сек (здесь и далее все цифры в килобайтах и мегабайтах)
Сперва, создаём LVM-раздел на диске, пишем на него, как сказано в 2. Скорость получается в 400 МБ/сек.
Создаём DRBD-устройство с global_common.conf
global {
usage-count no;
minor-count 64;
dialog-refresh 5;
}
common {
protocol C;
handlers {
pri-on-incon-degr "/usr/lib64/drbd/notify-pri-on-incon-degr.sh; /usr/lib64/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
pri-lost-after-sb "/usr/lib64/drbd/notify-pri-lost-after-sb.sh; /usr/lib64/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
local-io-error "/usr/lib64/drbd/notify-io-error.sh; /usr/lib64/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
fence-peer "/usr/lib64/drbd/crm-fence-peer.sh";
after-resync-target /usr/lib64/drbd/crm-unfence-peer.sh;
}
startup {
wfc-timeout 60;
degr-wfc-timeout 120;
}
disk {
on-io-error detach;
fencing resource-only;
no-disk-flushes;
no-md-flushes;
no-disk-barrier;
}
net {
max-buffers 20000;
max-epoch-size 20000;
unplug-watermark 512;
sndbuf-size 0;
}
syncer {
rate 410000K;
}
}
resource r13 {
device /dev/drbd13;
disk /dev/vg/testdrbd;
meta-disk internal;
startup {
become-primary-on nd1;
}
on nd1 {
address 172.16.0.1:7802;
}
on nd2 {
address 172.16.0.2:7803;
}
}Созданный диск /dev/drbd13 монтируется, как показано в шаге 2 и скорость в результате оказывается… 57 МБ/сек. Я всё понимаю, но падение скорости почти в 7 раз…
Стал смотреть: похоже, что узкое место — I/O, т.к. процессор ожидает долго.
В ядре DMA имеется:
zgrep -i dma /proc/config.gz | grep -v "#"
CONFIG_ZONE_DMA=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_ZONE_DMA32=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_ISA_DMA_API=y
CONFIG_SCSI_DMA=y
CONFIG_ATA_BMDMA=y
CONFIG_DMADEVICES=y
CONFIG_INTEL_MID_DMAC=y
CONFIG_INTEL_IOATDMA=y
CONFIG_TIMB_DMA=y
CONFIG_PCH_DMA=y
CONFIG_DMA_ENGINE=y
CONFIG_NET_DMA=y
CONFIG_ASYNC_TX_DMA=y
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
CONFIG_ASYNC_TX_DISABLE_PQ_VAL_DMA=y
CONFIG_ASYNC_TX_DISABLE_XOR_VAL_DMA=y
CONFIG_HAS_DMA=yНикто не сталкивался? Куда следует рыть, хотя бы направление подскажете? МП, вроде, может через себя достаточно широкий поток пропихнуть.
Здравствуйте.
Можно ли воткнуть две-три поделки http://www.safenet-inc.com/?aldn=true на один хост и заставить их раздавать лицензии параллельно?
Здравствуйте.
Пытаюсь настроить сабж для конфигурации ХОСТ - СВИТЧ - ХОСТ.
На каждом хосте по 2 сетевые карты. Свитч поддерживает addressed-based algorithms:
L2 — Based on layer 2 MAC (default);
L3_L4 — Based on layer 3 IP and layer 4 port;
lacp — link aggregation group handled by LACP
Из документации по режимам bonding: balance-rr — не подходит, работает только при прямом соединении сетевых карт; active-backup — не подходит по условиям; balance-xor — может быть и подошло бы… если бы свитч поддерживал; broadcast — не подходит по условиям задачи; 802.3ad — синхронизируется, подключается, но при работе почему-то используется только один канал (даже если нагружаю iperf с ключом -P 2), соответственно, скорость выше 115 MBytes/sec не поднимается; balance-tlb и balance-alb не пробовал пока что, но указано, что они для свитчей без поддержки агрегации каналов, так что, думаю, что заработает оно. Однако, хочется пока понять, можно ли поднять скорость, используя в т.ч. и возможности свитча.
Итак, в моём случае, похоже, единственным вариантом остаётся 802.3ad. Умеет ли этот протокол load balancing и если да, то что виновато в отсутствии этой балансировки: настройки
Ethernet Channel Bonding Driver: v3.7.0 (June 2, 2010)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
802.3ad info
LACP rate: slow
Aggregator selection policy (ad_select): stable
Active Aggregator Info:
Aggregator ID: 2
Number of ports: 2
Actor Key: 17
Partner Key: 1001
Partner Mac Address: AAAAAA
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: BBBBBB
Aggregator ID: 2
Slave queue ID: 0
Slave Interface: eth2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: BBBBBBB
Aggregator ID: 2
Slave queue ID: 0Здравствуйте.
Пытаюсь найти, как отключить нахрен starttls и заставить samba подключаться к openldap, используя указанные сертификаты и только их.
Сперва цитатка с сайта самбы http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html#LDAPSSL :
This option is used to define whether or not Samba should use SSL when connecting to the ldap server This is NOT related to Samba's previous SSL support which was enabled by specifying the --with-ssl option to the configure script.
LDAP connections should be secured where possible. This may be done setting either this parameter to Start_tls or by specifying ldaps:// in the URL argument of passdb backend.
The ldap ssl can be set to one of two values:
Off = Never use SSL when querying the directory.
start tls = Use the LDAPv3 StartTLS extended operation (RFC2830) for communicating with the directory server.
Please note that this parameter does only affect rpc methods. To enable the LDAPv3 StartTLS extended operation (RFC2830) for ads, set ldap ssl = yes and ldap ssl ads = yes. See smb.conf(5) for more information on ldap ssl ads.
Default: ldap ssl = start tls
Как написано здесь, самба не умеет работать ни с чем, кроме starttls.
Ок, не вопрос. Указываем.
# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[printers]"
Processing section "[print$]"
Loaded services file OK.
Server role: ROLE_DOMAIN_BDC
Press enter to see a dump of your service definitionsСам openldap-сервер находится на другой машине. На машине с самбой — только клиентская часть.
Где-то проскакивала информация, что samba использует /etc/openldap/ldap.conf:
BASE dc=test,dc=local
URI ldaps://ldaps.test.local ldaps://ldapm.test.local
DEREF never
TLS_CACERT /etc/openldap/ssl/test-cacert.pem
TLS_CERT /etc/openldap/ssl/sampdc-cl.test.local-cert.pem
TLS_KEY /etc/openldap/ssl/sampdc-cl.test.local-key.pem
TLS_REQCERT hardВ качестве теста, указанные сертификаты с ключом доступны на чтение всем. На сервере, соответственно, обязательно требуются сертификаты.
Шифрование, разумеется, работает прекрасно, pam_ldap и nss_ldap в соответствующем конфиге настроенные аналогично, соединяются с любым из указанных серверов, используя указанные сертификаты, если подложить левый, не подписанный нужным CA, то соединение отбивается.
Так вот, пробуем самбу, получаем отлуп, в логах:
2011-06-18T01:32:00+04:00 ldaps slapd[3589] conn=1279 fd=27 ACCEPT from IP=192.168.1.216:57716 (IP=0.0.0.0:636)
2011-06-18T01:32:00+04:00 ldaps slapd[3589] conn=1279 fd=27 closed (TLS negotiation failure) 2011-06-18T01:32:25+04:00 sampdc smbd[5537] [2011/06/18 01:32:25.640160, 0] lib/smbldap.c:731(smb_ldap_start_tls)
2011-06-18T01:32:25+04:00 sampdc smbd[5537] Failed to issue the StartTLS instruction: Can't contact LDAP serverЕсли же на сервере openldap смягчить требования в параметре olcTLSVerifyClient с hard на allow, то сервер перестаёт ругаться, а вот самба — продолжает. Если поставить параметру ldap ssl значение yes, то оно игнорируется как неверное.
Итак, вопрос: умеет ли самба, как прочие нормальные программы, соединяться с openldap по шифрованному каналу на 636 порт, с использованием только тех сертификатов и ключа, которые указывает администратор?
Доброе утро.
Настройки одной из ВМ в кластере:
primitive Linux-amd64-syslog ocf:heartbeat:VirtualDomain \
params config="/etc/libvirt/qemu/gentoo-amd64-syslog.xml" migration_transport="ssh" \
meta target-role="Started" allow-migrate="true" \
op monitor interval="10"После тестирования онлайн-миграции ВМ программным путём (т.е. через консоль resource migrate и node standby), было проведено испытание жёстче: нода, на которой работала ВМ, была внезапно выключена через кнопку питания, имитируя kernel panic.
Вот что наблюдалось при этом на живой ноде:
Node fs_1: online
Linux-amd64-ldapm (ocf::heartbeat:VirtualDomain) Started
Win2003 (ocf::heartbeat:VirtualDomain) Started
ssh-fencing:0 (stonith:ssh) Started
Node fs_2: UNCLEAN (offline)
ssh-fencing:1 (stonith:ssh) Started
Linux-amd64-ldaps (ocf::heartbeat:VirtualDomain) Started
Linux-amd64-syslog (ocf::heartbeat:VirtualDomain) Started
Inactive resources:
Clone Set: Fencing [ssh-fencing]
Started: [ fs_1 ]
Stopped: [ ssh-fencing:1 ]
Resource Group: ClusterIP
InternalIP (ocf::heartbeat:IPaddr2): Stopped
ExternalIP (ocf::heartbeat:IPaddr2): Stopped
Linux-amd64-syslog (ocf::heartbeat:VirtualDomain): Started fs_2
Linux-amd64-ldaps (ocf::heartbeat:VirtualDomain): Started fs_2
Migration summary:
* Node fs_1:т.е. миграция двух виртуалок не прошла. Я понимаю, почему: данные, которые они занимали в памяти, неоткуда было брать. Дисковые устройства раздаются по сети с другого хоста, так что, с этим всё ок. Проблема только с процессом ВМ.
Итак, существует ли решение подобной проблемы? Или же kernel panic, отвалившаяся внезапно сетевая карта и т.п. штуки означают невозможность миграции всех ВМ с такой ноды?
Если же миграция невозможна, то можно ли упавшую виртуалку запустить на живой ноде автоматически? Как это указать pacemaker'у?
Я посмотрел: вроде как железячные решения, обеспечивающие failover существуют, могут ли их заменить программные?
Здравствуйте.
На хост-системах стоит ntpd, синхронизирующийся с единым сервером времени. В гостевые — проброшено через
/usr/bin/qemu-system-x86_64 --enable-kvm… -rtc base=utc…Вопрос: требуется ли при такой настройке дополнительно настраивать внутри гостевых систем ntpd?
Лично я думаю, что нет, т.к. это было бы нелогично, однако, может быть существуют нюансы.
Понадобился LDAP-браузер, с поддержкой SSL/TLS, с GUI и тд.
Попробовал jxplorer: если плюнуть на постоянные глюки этого жабоподелия при незащищённом соединении, то можно сказать, что оно ближе всего к идеалу. Для отдельных секций конфига показываются все допустимые атрибуты и тд и тп. Однако, учитывая, что для работы с SSL/TLS ему надо создать локальное хранилище ключей, а оно это делать не хочет (пытался создавать директории и файлы вручную, пытался пароль менять со стандартных changeit и passphrase, впрочем, оно и стандартные не кушает), то, к сожалению, для работы по защищённому каналу оно непригодно.
От безвыходности испробовал lat, смирился с жирнющим mono и прочими зависимостями. У этой поделки интерфейс работал более стабильно и не рвал глаза, зато возможности не соответствовали его объёму. Оно даже половину из того, что мне предоставил jxplorer не вытянуло. С отвращением выкинул.
phpldapadmin возможно и вариант, но мне нужен именно локальный клиент, чтобы не только работать, но и тестировать различные варианты подключений, причём, делать, не задумываясь о нюансах настроек.
Итак, уважаемые ЛОРовцы, что вы посоветуете?
PS Риторический вопрос: почему вместо очередного 100500 велосипеда, вроде плеера или файлового менеджера, программисты не нарисуют нормальный работоспособный LDAP-браузер на GTK в качестве frontend? Вон, в оффтопике их несколько и большая часть работает прилично.
Поскольку, ничего кроме dd не приходит в голову для такой задачи, встаёт вопрос: как это сделать правильно?
Меня смущает вот что: предположим, я создал копию LVM-раздела:
dd if=/dev/vg/image of=/mnt/images/backup.rawЭто тривиально.
Теперь, на целевой VG надо развернуть сделанную копию:
# ls --block-size=K -l
-rw-r--r-- 1 root root 126792K Май 20 14:56 backup.raw
# lvcreate -L 126792K -n test vg
# dd if=/mnt/images/backup.raw of=/dev/vg/test
Соответственно, не вылезет ли при таком алгоритме копируемый образ за границы раздела? А если раздел вдруг будет меньше, чем образ, не затрётся ли что-то важное на диске случайно?
Здравствуйте.
Захотелось странного: возможности через virsh склонировать раздел из любого пула в любой.
Если читать справку, то vol-clone клонирует только в пределах пула, а если хочется, к примеру, из LVM-пула создать файл или, наоборот, из файла создать LVM-раздел, то тут уже непонятно, что делать надо.
ИМЯ vol-create-from - создать том на основе другого тома
ОБЗОР vol-create-from <pool> <file> <vol> [--inputpool <строка>]
ОПИСАНИЕ Создать том на основе существующего тома.
ПАРАМЕТРЫ [--pool] <string> имя пула [--file] <string> файл с XML-описанием тома [--vol] <string> имя исходного тома или ключ --inputpool <строка> имя пула или UUID пула исходного тома
вроде годится, но где же взять этот XML? Делать vol-dumpxml, править руками и указывать, в качестве параметра?
Или же надо с помощью vol-download сгрузить том в файл, а потом, загрузить его обратно, командой vol-upload? При этом, если том назначения будет меньше, чем файл, он корректно изменит свои размеры?
Хотелось бы, чтобы указав команду, типа «vol-fullcopy исходный_пул исходный_том пул_назначения том_назначения --формат etc» virsh, по возможности, создал полную копию тома, в указанном формате, пуле. Разумеется, меняя размеры результата, по необходимости.
Здравствуйте.
Имеется следующая конфигурация pacemaker:
node fs_1
node fs_2
primitive ClusterIP ocf:heartbeat:IPaddr2 \
params ip="192.168.1.211" cidr_netmask="24" \
op monitor interval="10s"
primitive drbd ocf:linbit:drbd \
params drbd_resource="r0" \
op monitor interval="15s"
primitive ssh-fencing stonith:ssh \
params hostlist="fs_1 fs_2" \
op monitor interval="60s"
group NetDisk ClusterIP
ms ms_drbd drbd \
meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true" target-role="Master"
clone Fencing ssh-fencing
location cli-prefer-ClusterIP ClusterIP \
rule $id="cli-prefer-rule-ClusterIP" inf: #uname eq fs_1
location cli-prefer-NetDisk NetDisk \
rule $id="cli-prefer-rule-NetDisk" inf: #uname eq fs_1
colocation iscsi_on_drbd inf: NetDisk ms_drbd:Master
property $id="cib-bootstrap-options" \
dc-version="1.1.4-ac608e3491c7dfc3b3e3c36d966ae9b016f77065" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
stonith-enabled="true" \
no-quorum-policy="ignore"
rsc_defaults $id="rsc-options" \
resource-stickiness="100"Монитор показывает:
Node fs_1: online
ssh-fencing:0 (stonith:ssh) Started
drbd:0 (ocf::linbit:drbd) Slave
Node fs_2: online
ssh-fencing:1 (stonith:ssh) Started
ClusterIP (ocf::heartbeat:IPaddr2) Started
drbd:1 (ocf::linbit:drbd) Master
Когда ноды выключаются, то NetDisk, а значит, ClusterIP и тот ресурс, который я ещё введу потом в эту группу, переходит на рабочий хост и там же включается Master для drbd. В этой части всё ок.
Когда я хочу вручную перенести ресурсы с одной ноды на другую, почему-то это не удаётся, пробовал как «resource migrate NetDisk fs_1», так и «resource migrate ClusterIP fs_1». При этом, ресурсы остаются на fs_2.
Что сделано неверно?
| ← предыдущие | следующие → |