Всем привет! Есть необходимость бездисковой загрузки ОС Linux с использованием multipath устройства, на котором расположен root системы. В свою очередь multipath устройство должно формироваться из iSCSI target доступного по двум различным IP.

Реализовать загрузку просто с iSCSI устройства удалось, для этого используются параметры передаваемые GRUB (например root=/dev/mapper/centos_node1-root iscsi_initiator=iqn.2001-01.ru.domain:node1 ifname=enp4s0:f4:6d:04:e6:78:80 ip=enp4s0:dhcp netroot=iscsi:@10.0.0.2::3260::iqn.2001-01.ru.domain:iscsitest.lv_node1_ovirt_iscsi).

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

Всем привет! Появилась задача ограничить доступ к портам, обслуживающим сервисы imap/pop3/smtp. Сейчас клиенты локальной сети получают доступ к сторонним серверам imap/pop3/smtp через NAT. С целью безопасности (как минимум исключения возможности создания туннеля для своих нужд через данные порты) необходимо ограничить данный трафик по следующим критериям: 1. Обращения могут проходить только к определённым DNS именам - smtp.yandex.ru, imap.gmail.com и прочим, заданным администратором. 2. Должен ходить только трафик принадлежащий протоколу, никаких возможностей создания туннеля в собственных целях. 3. Желательно обеспечить «прозрачный» доступ, чтобы пользователи с ноутбуками не перенастраивали почтовые клиенты дома и в офисе.

Как Вы решаете такие или похожие задачи в своём окружении? Как правильно обеспечить доступ клиентов к данным сервисам?

Лично воспользовался nginx для проксирования imap/pop3/smtp, но есть проблемы с авторизацией на SMTP сервере yandex и передаче пароля в открытом виде (опции все перепробовал).

Потребовалось настроить FTPS сервер за фаерволом, и тут возникло непредвиденное обстоятельство, nf_conntrack_ftp не работает с FTP поверх SSL, соответственно для пассивного режима требуется диапазон (в рамках 49152-65534) портов открытых наружу.

Собственно вопросы: 1. Сколько свободных портов нужно на одного клиента в пассивном режиме? (в доках не нашел, может кто измерял); 2. На сколько опасно открывать большой диапазон (в рамках 49152-65534) портов наружу?

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

Здравствуйте! Имеется компьютер под управлением Ubuntu Linux 12.04 LTS (3.2.0-67-generic), выполняющий роль шлюза. В его распоряжении две сетевых карты Intel Corporation 82574L Gigabit Network Connection, с драйвером e1000e версии 3.1.0.2-NAPI (самый свежий), одна карта смотрит в локальную сеть (соединена с неуправляемым коммутатором), другая в интернет (с белым IP адресом). Forwarding включен, трафик фильтрует iptables. Два года работы не приносили никаких неприятностей, но неделю назад начались глюки (к серверу никто не прикасался месяц), выражались они низкой скоростью передачи данных (~800 кбайт/с) от шлюза к клиентам (наблюдалось как при обращении к локальным ресурсам шлюза, так и к forwarding интернет трафику). То есть проблемы наблюдались только при участии адаптера смотрящего в локальную сеть, в то время, как при input\output Интернет трафике на самом шлюзе всё было замечательно. Для нахождения причин глюков на шлюзе был запущен tcpdump -e -ni eth0, который показал множество сообщений MPCP, Opcode Pause, length 46. В итоге был найден ВЫКЛЮЧЕННЫЙ компьютер, который «гадил» в сеть, то есть при отключении от него LAN кабеля сообщения на шлюзе пропадали и всё начинало отлично работать. Но рано я обрадовался, на следующий день продолжились проблемы, проходящий трафик через шлюз сильно «застревает» - пакеты теряются, соединения на клиентах (например) с почтовыми/VPN серверами рвутся, работают нестабильно, при чём проблемы только в одну сторону - RX шлюза, c TX проблем нет. tcpdump уже ничего аномального не показывает. Менял сетевые карты, откатывал ядро, обновлял драйвер e1000e, отключал разгрузки и аппаратное управление потоком, менял свич, ничего не помогает. Заметил, что сильно растёт счётчик dropped в ifconfig у адаптера, смотрящего в локальную сеть, за сутки получилось вот такое значение - «dropped:31728883», и оно дальше растёт в тот момент, когда наблюдаются проблемы с соединениями у клиентов. После долгих мыторств начал эксперименты с MTU и txqueuelen на данном интерфейсе, в итоге с параметрами MTU:9000 и txqueuelen:500 пакеты стали теряться значительно реже, но всё равно счётчик dropped растёт и иногда возникают жалобы у клиентов при работе с почтовыми серверами (письма не отправляются, так как происходит Timeout при передаче тела письма). Подскажите, пожалуйста, что диагностировать, как решить возникшую проблему? Заранее спасибо!

Вот вырезка ifconfig для адаптера, смотрящего в локальную сеть eth0: UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:128558579 errors:24 dropped:31728883 overruns:0 frame:24 TX packets:195386217 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:16937813554 (16.9 GB) TX bytes:168058180665 (168.0 GB)

Для адаптера, смотрящего в интернет eth1: UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25854765 errors:0 dropped:0 overruns:0 frame:0 TX packets:18219723 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:23325670902 (23.3 GB) TX bytes:3364102002 (3.3 GB)