Записки IT специалиста

Подписка на Лента Записки IT специалиста Записки IT специалиста
Технический блог специалистов ООО"Интерфейс"
Обновлено: 1 день 12 часов назад

Расширенная настройка DNS и DHCP в роутерах Mikrotik

пн, 05/20/2019 - 00:55

Со службами DHCP и DNS знакомы, пожалуй все, ведь это базовые службы для сетей любого размера. Но их настройка обычно сводится к установке базовых параметров и затем о них забывают. Действительно, ну что может быть в них интересного, особенно если это неполноценные сервера, а службы роутера. Это так, если говорить о бытовых роутерах, где пользователю стараются не давать в руки лишних инструментов, но RouterOS рассчитана на иную аудиторию и предоставляет широкий спектр возможностей, которыми глупо не воспользоваться.

DNS (Domain Name System)

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

Как работает система DNS мы рассказывали в одной из наших статей, рекомендуем ее к прочтению, особенно если вы не до конца разбираетесь в вопросе. Основное, на что нужно обратить внимание - это иерархичность системы. Данные зон хранятся на собственных серверах и для получения информации из них следует прибегать к рекурсии. Это достаточно затратный процесс, поэтому многие сервера кешируют запросы и отвечают на повторные обращения самостоятельно.

Скорость ответа на DNS-запрос очень важна для комфортного использования интернета. Внешне это может проявляться как "задумчивость" браузера, который некоторое время "думает", а только потом начинает грузить страницу. При этом сама скорость канала может быть высокой, а пинг к требуемому серверу небольшим. Неопытного админа такая ситуация может сильно озадачить, но все просто - это долго отвечает используемый DNS-сервер. Ведь прежде, чем начать взаимодействие с сервером, браузер должен получить от DNS-клиента его адрес, передав последнему доменное имя.

Mikrotik дает нам возможность использовать кеширующий DNS-сервер прямо на роутере и если вы настроили использование роутера в качестве DNS - то вы его уже используете. Еще раз перейдем в IP - DNS и внимательно посмотрим на настройки:

В самом низу расположены настройки кеша: его размер (Cache Size) и максимальное время хранения записей (Cache Max TTL). Еще ниже располагается показатель использования кеша - Cache Used - который показывает его текущий размер. Если он начинает приближаться к размеру кеша, то последний следует увеличить. Просмотреть кеш можно нажав на кнопку Cache.

Глядя на значение TTL, можно подумать, что это очень много, целая неделя. Но это - максимальное время хранения записи, реальное время хранения определяется временем TTL в SOA-записи домена, причем Mikrotik использует минимальное значение - Minimum TTL. В этом несложно убедиться, мы очистили кеш и посетили один из своих сайтов, минимальный TTL которого равен 4 часам:

Как видим, Mikrotik использовал значение TTL из SOA-записей, ни о каких 7 днях речи не идет. Тогда для чего нужна эта настройка? Вы можете обновлять кеш чаще, чем это указано в TTL-домена. Если значение максимального TTL Mikrotik будет меньше, чем указанное в SOA-домена, то будет использоваться именно оно.

Это может быть полезным, если вы внесли какие-либо изменения во внешнюю зону и желаете быстрее обновить кеш. Как показывает практика, публичные сервера, такие как Google, OpenDNS или Яндекс тоже часто игнорируют TTL из SOA и обновляют свой кеш чаще.

Очистить кеш можно кнопкой Flush Cache в окне Cache или командой в терминале:

ip dns cache flush

Но это еще не всё, изучение кеша может быть полезным для изучения сетевой активности пользователей, если они используют в качестве DNS ваш роутер - то вся их сетевая активность отразится в кеше. Говорите, никто не сидит в соцсетях?

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

На этом закончим с кешем и перейдем к другому разделу - Static. Он позволяет создавать нам собственные записи типа A (и больше ничего кроме них). Не густо, но основную часть потребностей это перекрывает. Перенесли сайт на новый сервер? Не нужно ждать пока обновятся DNS-записи, заходим в раздел Static и создаем собственную запись:

Проверим, как это работает. Выполним разрешение имени на клиенте:

Как видим - все работает отлично.

Отдельный разговор - плоские имена. В одноранговой сети часто бывает нужно указать имя узла, который не поддерживает NetBIOS, скажем ноду Hyper-V Server или машину с Linuх. Аналогично создаем запись:

Но имейте ввиду, работать такое разрешение имен будет только на Windows машинах, на Linux вы получите ошибку:

Но так как большинство сетей имеет преимущественно Windows ПК, то особых проблем плоские имена не доставят, и вы можете смело добавлять их записи на DNS Mikrotik вместо того, чтобы прописывать в hosts на каждой машине.

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

Проверим?

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

Чтобы этого избежать следует использовать регулярные выражения. К сожалению, в большинстве инструкций в интернете приводятся неправильные выражения, с которыми фильтр работать не будет, поэтому мы советуем использовать для создания и проверки регулярных выражений ресурс regex101.com. Это избавит вас от ошибок и вопросов в стиле "я сделал все как написано в статье, но ничего не работает".

Скажем, чтобы заблокировать домен vk.com со всеми поддоменами, но при этом не затронуть иные домены, которые могут заканчиваться на vk.com нам потребуется выражение:

\.?vk\.com

Внесем его в соответствующее поле Mikrotik:

И проверим, теперь любое, даже заведомо не существующее имя в домене vk.com будет разрешаться в 127.0.0.1, что нам и требовалось.

Но в небольших сетях, где пользователи имеют достаточно прав, всю эту идиллию можно быстро перечеркнуть, вручную прописав собственные DNS. Как с этим бороться? Решение в лоб - заблокировать прохождение DNS-запросов в цепочке FORWARD, но тогда у "продвинутого" пользователя вообще перестанет работать интернет, поэтому мы поступим по-другому.

Откроем IP - Firewall - NAT и добавим правило: Chain: dstnat, protocol: udp, Dst. Port: 53 и на закладке Action выберем действие redirect.

Потом создаем точно такое же правило для протокола tcp. Эти же самые действия можно быстро выполнить в терминале:

ip firewall nat
add chain=dstnat protocol=udp dst-port=53 action=redirect
add chain=dstnat protocol=tcp dst-port=53 action=redirect

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

Как видим, DNS-сервер роутера Mikrotik, несмотря на кажущуюся простоту, в общем не так уж и прост и дает в руки администратора достаточно широкие возможности.

DHCP (Dynamic Host Configuration Protocol)

Когда речь заходит о DHCP, то обычно имеют ввиду автоматическое присвоение сетевых параметров, таких как IP-адрес, маска, шлюз и DNS-сервера. Но на самом деле возможности протокола намного шире и позволяют настроить очень многие сетевые параметры. Все возможности протокола описаны в RFC 2132, но мы не будем забираться столь глубоко, а рассмотрим в качестве примера только несколько наиболее популярных опций.

Прежде всего это Option 15 (DNS Domain Name) - которая позволяет автоматически настроить DNS-суффикс подключения, что позволяет снять определенный ряд проблем, связанный с использованием плоских имен.

Чтобы создать любую DHCP опцию потребуется перейти в IP - DHCP Server - Options и добавить там новую запись:

Поле Name содержит имя опции, можем задать его произвольно, так чтобы нам потом было понятно, что это такое и для чего нужно. Code - код опции, в нашем случае 15, Value - значение, в нашем случае это строка, поэтому обрамляем ее одиночной кавычкой. Тоже самое можно быстро сделать в терминале:

ip dhcp-server option
add name="DNS Suffix" code=15 value="'interface31.lab'"

Обратите внимание, что значение value берется в кавычки два раза, в двойные и одинарные.

Опции можно (и нужно) объединять в наборы - Option Set, даже несмотря на то, что во многих сценариях их можно указывать непосредственно. Если в будущем вы надумаете что-то поменять, то достаточно будет просто изменить состав набора, в противном случае вам нужно будет вспомнить все места, где вы использовали некую опцию и заменить ее на новую (или удалить / добавить). Перейдем на одноименную закладку и создадим новый набор. Пока в него будет входить только одна опция:

Наборам желательно давать осмысленные названия, чтобы впоследствии вы легко могли понять для чего он предназначен. Теперь назначим его для применения на всю область DHCP-сервера. Перейдем на закладку DHCP и откроем запись нашего сервера, в поле DHCP Option Set укажем имя созданного нами набора.

Теперь обновим параметры DHCP и сразу увидим полученный DNS-суффикс:

После этого все плоские имена, которые вы добавили на DNS-сервер следует дополнить до FQDN, т.е. вместо HV-CORE-01 написать hv-core-01.interface31.lab (регистр записи значение не имеет).

Проверим:

Как видим, одной проблемой стало меньше, плоские имена нормально дополняются до FQDN и нормально разрешаются на нашем DNS вне зависимости от используемой ОС.

Также довольно часто используются опции: 42 (NTP Servers), 60, 66 (TFTP Server Name), 67 (Bootfile-Name). Имейте ввиду, что ОС Windows не запрашивает у DHCP-сервера опцию 42 и для нее установить таким образом сервер времени не удастся.

Отдельно коснемся того, как указывать IP-адреса. Протокол предусматривает передачу значений в шестнадцатеричном (Hex) формате, но RouterOS позволяет использовать и строковые значение, для этого значение Value должно содержать привычное написание адреса, взятое в одинарные кавычки:

'192.168.186.1'

или его шестнадцатеричное значение, которое должно начинаться с префикса 0х:

0xc0a8ba01

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

'192.168.186.1''192.168.186.2'

В шестнадцатеричном виде мы добавляем второе значение в конец строки, также без пробелов:

0xc0a8ba01c0a8ba02

В терминале это будет выглядеть так:

ip dhcp-server option
add name="NTP1" code=42 value="'192.168.186.1'"

или

add name="NTP1" code=42 value="0xc0a8ba01"

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

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

Суть ее состоит в следующем: мы выборочно изменяем DNS-сервера детских сетевых устройств на безопасные DNS, например, Яндекс Семейный, SkyDNS, AdGuard и т.д. Тем, кто захочет реализовать этот сценарий в сети предприятия следует иметь ввиду, что в этом случае таким клиентам будут недоступны возможности собственного DNS-сервера, т.е. все то, о чем мы говорили в первой части статьи.

Итак, сначала создадим новую DHCP опцию с кодом 6 и укажем в значении сервера Яндекс Семейного:

ip dhcp-server option
add name="YandexDNS" code=6 value="'77.88.8.7''77.88.8.3'"

или

add name="YandexDNS" code=6 value="0x4d5808034d580807"

Теперь создадим новый набор опций и добавим туда опцию YandexDNS.

Теперь перейдем на закладку Leases, где находится список выданных в аренду адресов и найдем там детское устройство, после чего откроем запись и выполним резервирование адреса, нажав Make Static:

Закроем и заново откроем эту запись и в поле DHCP Option Set укажем созданный нами набор с безопасными серверами:

Теперь проверим на клиенте, какие DNS-сервера он получил:

Все верно, это семейные сервера Яндекса. Попробуем посетить какой-нибудь сайт "для взрослых":

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

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

Поэтому заменим в правилах действие redirect на действие dst-nat, в поле To Addresses указываем один из серверов семейного Яндекса, а в поле To Ports - порт 53.

Также можно быстро добавить нужные правила командой:

ip firewall nat
add chain=dstnat protocol=udp dst-port=53 action=dst-nat to-addresses=77.88.8.7 to-ports=53
add chain=dstnat protocol=tcp dst-port=53 action=dst-nat to-addresses=77.88.8.7 to-ports=53

Напоследок рассмотрим опции 121 (Classless Static Routes) и 249 (MS Routes), которые предназначены для передачи статических маршрутов. Первая опция предусмотрена RFC 2132, вторая является "художественной самодеятельностью" Microsoft, поэтому следует указывать обе из них с одинаковым содержимым.

Во избежание ошибок мы советуем задавать маршруты в HEX-формате, синтаксис предусмотрен следующий:

[маска сети назначения][сеть назначения][шлюз]

Если маршрутов несколько - добавляем значения к конец строки, без пробелов. Допустим, мы хотим добавить маршрут в сеть 192.168.4.0/22 через 192.168.186.92 и в сеть 10.8.0.0/24 через 192.168.186.94. Чтобы правильно получить шестнадцатеричное значение маски следует использовать такое представление: 0.0.0.22 или 0.0.0.24, забьем все значения в онлайн калькулятор и получим:

А вот теперь начнется небольшая магия, прежде всего обратим внимание на то, что количество символов в шестнадцатеричном числе всегда должно быть четным, но в строке, соответствующей 10.8.0.0 - нечетное количество символов, так как калькулятор отбросил ведущий ноль, поэтому вместо a080000 мы должны использовать 0a08000. Имеем это ввиду, так как разные калькуляторы могут по-разному обрабатывать ведущий ноль.

Затем от адреса сети, мы должны отбросить столько нулевых октетов, сколько нулей содержится в маске, в HEX-значении это по два нуля. Проще говоря для сетей /24 - /17 мы должны убрать в HEX-значении сзади два нуля, для сетей /16 - /9 - четыре нуля, для сетей /8 - /1 - шесть нулей. Таким образом 0a08000 должно превратиться в 0a0800, а c0a80400 в c0a804.

Таким образом первый маршрут должен выглядеть так:

16c0a804c0a8ba5c

а второй так:

180a0800c0a8ba5e

Итоговое значение будет (не забываем про 0x вначале):

0x16c0a804c0a8ba5c180a0800c0a8ba5e

Добавим опции командами:

ip dhcp-server option
add name="my route" code=121 value="0x16c0a804c0a8ba5c180a0800c0a8ba5e"
add name="my win route" code=249 value="0x16c0a804c0a8ba5c180a0800c0a8ba5e"

или через графический интерфейс:

Обновим параметры DHCP и проверим таблицы маршрутизации на клиентах. Windows-клиент:

Linux-клиент:

Как видим - все работает, маршруты добавились и еще одной заботой у администратора стало меньше.

В заключение хочется добавить, что данная статья не должна рассматриваться вами как догма, все пункты которой требуется обязательно применить. Данный материал имеет цель показать те скрытые возможности привычных сервисов, которые обычно не затрагиваются в руководствах по базовой настройке. После чего уже сам администратор должен решать, что он будет применять в своей сети и зачем. К сожалению, объем статьи не позволяет нам охватить все возможности DHCP, что-то из них мы отразим в будущих статьях, а что-то вам придется изучать самостоятельно. Но надеемся, что данный материал окажется вам полезен и даст дополнительный стимул к изучению всех возможностей используемых протоколов.

Microsoft: будущее Windows в Linux

сб, 05/18/2019 - 00:48

Представляем вашему вниманию очередной перевод зарубежной прессы сделанный нашим немецким коллегой. На этот раз затронута достаточно интересная тема: взаимодействие компании Microsoft с Linux и открытым ПО. Несмотря на то, что многие утверждения автора носят полемический характер, мы считаем, что статья будет представлять интерес для русскоязычной аудитории. К тому же хороший технический специалист должен иметь широкий кругозор, представление о тенденциях развития отрасли и перспективах. А в этих вопросах обычно нет общего мнения, но это и к лучшему, ведь в споре рождается истина.

Собственная ОС не так и важна -- фирма делает ставку на open source (ПО с открытым исходным кодом)

Перемены в компании Microsoft в последние годы весьма впечатляют. Вместо ненависти к Linux, фирма перешла к активной разработке программного обеспечения с открытым кодом. Уже позабыты те боевые времена, когда руководитель Microsoft Стив Баллмер обзывал свободную ОС то «раковой опухолью», то «коммунистической системой». С тех пор, как у руля предприятия стал Сатья Наделла, здесь стали ценить преимущества свободного ПО.

Теперь Microsoft Linux?

Интересная идея. Станет ли компания Microsoft сама предлагать линукс в качестве ОС для персональных компьютеров? Вроде дурацкий вопрос, но если посмотреть тенденции последних лет, то такие мысли вполне могут прийти в голову.

Уже заметна уменьшающаяся роль Windows в стратегии Microsoft. Сейчас фирма растёт за счёт предоставления сервисов Office 365 и облачных служб Azure. И там и тут вполне можно обойтись без Windows. Где пользователи будут применять программы из пакета Office: на компьютерах с Windows или планшетах с Android - Microsoft как-то безразлично. А уж в облаках Azure и вовсе доминируют Linux-системы.

Стив Баллмер такого не ожидал

Утрата бизнес-модели

Ко всему прочему стоимость, которую сегодня можно взять за ОС с частных клиентов уверенно стремится к нулю. Google и Apple позаботились об этом, и получают деньги на разработку софта из других источников. Это дошло и до Microsoft, вот уже и новая «десятка» фактически раздавалась даром. Ну а попытка заработать немного денег на рекламе прямо в Windows -- это говорит, скорее, о внутренних метаниях, потому этот способ годится только чтобы разогнать своих клиентов в то время, когда значение ОС для пользователя постоянно снижается.

Бизнес не пропадёт

Не стоит заблуждаться, бизнес Microsoft по продаже лицензий ещё годами будет приносить компании прибыль. Хотя-бы на том основании, что позиции Windows достаточно сильны в компаниях и госучреждениях. Однако уже достаточно хорошо проглядывается будущее, где ОС перестает играть ту значительную роль, которую ей уделяли ранее.

Куда ни глянь -- везде Linux

Чтобы увидеть куда идёт Microsoft, тому достаточно обратить внимание на самую растущее подразделение фирмы: облачные службы. Именно там Microsoft давно приспособилась к реальности. Вместо бессмысленной борьбы с Linux, принята стратегия поддержки этой ОС. Мало того, весной 2019 года вышла собственная система на Linux-ядре - Azure Sphere и уже вполне можно представить направление дальнейших разработок в этой отрасли.

Примечание переводчика: немного ранее Microsoft впервые выпустил Linux-версию одного из ключевых корпоративных продуктов - SQL Server 2017.

Следующий логичный шаг - серверная ОС на основе Linux. Это проверенное временем серверное решение сечас становится стандартной основой для облачных служб. В тоже время Linux для персональных компьютеров вряд ли будет входить в список приоритетов Microsoft, по причине снижающейся значимости ОС в этой области.

Растут шансы, что Microsoft озадачится покупкой какого-нибудь крупного разработчика ОС на основе Linux. IBM только что купил Red Hat, что мешает Microsoft заинтересоваться Ubuntu или SUSE?

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

Всё больше открытого ПО

Даже если в Редмонде и не создадут свой Linux, то нет никаких сомнений в том, что открытый исходный код будет играть решающую роль в будущем Microsoft. К чему идёт дело стало ясно после покупки Microsoft самой важной в мире платформы для разработчиков свободного программного обеспечения Github. Но и на настольном компьютере свободное ПО начинает выходить на центральные позиции: браузер Edge переходит на основу свободного движка Chromium.

Становится очевидно: Microsoft будет применять открытое ПО везде, где это будет иметь стратегическое или коммерческое значение. Урок от Google был хорошо усвоен. Свободное ПО служит транспортом для передачи коммерческих программ, за счет которых и образуется прибыль.

С этой точки зрения закрывать платформу ОС будет нерационально. Именно там, где нет прямого финансового интереса, сотрудничество с другими разработчиками приносит больше выгоды, чем владение собственной операционной системой. Вполне вероятно, что Microsoft понемногу сделает открытым код своей Windows, если, конечно, приведёт накопившийся за десятилетия код в презентабельный вид.

Linux выигрывает

Проще говоря: Microsoft все больше живет в мире Linux. То, что раньше выглядело для производителя Windows как явная угроза, сегодня стало реальностью, в которой фирма может чувствовать себя вполне хорошо.

Автор: Andreas Proschofsky

Источник: Microsoft: Linux ist die Zukunft des Windows-Herstellers

Перевод: Виктор Хартманн, Берлин.

Перенос данных между различными версиями Zimbra безопасно и без простоя

пт, 05/17/2019 - 02:31

Представляем вашему вниманию перевод статьи зарубежного автора, в которой он подробно рассказывает о процессе переноса данных между двумя серверами Zimbra OSE разных версий, работающих под управлением разных операционных систем. На наш взгляд данный материал будет полезен широкому кругу администраторов почтовых серверов, тем более что аналогичного по полноте и проработанности русскоязычного материала нам не попадалось. В процессе перевода мы немного адаптировали материал для читателей нашего блога, не затрагивая при этом основной смысл исходной статьи.

Немного предыстории

После четырех лет работы почтового сервера Zimbra в виртуальной машине объемом в 500 ГБ сервер начал испытывать недостаток свободного места и когда вывод df -h показал, что осталось всего 50 ГБ пришло время перейти на более емкую виртуальную машину.

Бесплатная версия, с которой я работал (и продолжаю работать) не имеет в своем составе инструментов для миграции, хотя в интернете можно найти массу инструкций о переносе данных между старым и новым серверами при помощи rsync. Но этот способ меня не устраивал. Во-первых, требовался простой системы, а во-вторых, синхронизацию требуется проводить между одинаковыми серверами, т.е. мой новый сервер должен был оставаться Zimbra 8.6 под управлением CentOS 6.

Также некоторое время назад был случай аварийного завершения работы сервера (из-за сбоя питания) и база данных оказалась повреждена, что время от времени приводило к ошибкам в логах. То, что с базой не все в порядке стало очевидно после попытки обновления до 8.7.1, которая с треском провалилась и единственное что меня спасло - это сделанная прошлой ночью резервная копия. Поэтому я опасался, что при переносе с помощью rsync я перемещу на новый сервер проблемные данные, которые будут доставлять мне проблемы в будущем.

Так как мне все равно предстояло преодолеть множество сложностей, я хотел получить не только больше свободного места, но и перейти на новую операционную систему CentOS 7 и новую (на тот момент) версию Zimbra 8.7.1, поэтому об rsync не могло быть и речи.

Zmmailbox и bash спешат на помощь

Если вы хоть немного занимались администрированием Zimbra, то вам должна быть знакома такая команда как zmprov. Вы могли использовать ее для сброса забытого пароля администратора, получения списка учетных записей, использующих пересылку почты или делать многие другие вещи, не заходя в веб-интерфейс. Также вы можете быть немного знакомы с zmmailbox.

Zmmailbox, также как и zmprov, очень мощная команда, ее можно использовать для таких тривиальных вещей, как создание почтовой папки, а можно с ее помощью экспортировать в формат tgz целые почтовые ящики с любой структурой пользовательских папок.

Единственным недостатком является то, что вы должны экспортировать каждый ящик отдельно, не допускается использовать * или иные подстановочные символы. Но мы же работаем в Linux, поэтому всегда можно написать bash-скрипты, которые сделают всю тяжелую работу за нас.

Подготовка нового сервера

Вам потребуется установить новый сервер с теми же настройками, что и у старого, но с иным IP-адресом. Не забудьте правильно настроить записи на внутреннем DNS-сервере (dnsmasq) и проверить /etc/hosts. При этом не следует заводить все обслуживаемые сервером домены, укажите только основной, остальные мы перенесем со старого сервера автоматически.

План перехода на новый сервер

Чтобы обеспечить минимальное время простоя мы будем действовать следующим образом:

  1. Установите значение TTL для DNS-записей относящихся к почтовому серверу на минимально короткое время, лучше сделать это не менее чем за сутки до переноса.
  2. Подготовьте полностью рабочий новый сервер
  3. Импортируйте все обслуживаемые домены со старого сервера
  4. Перенесите все учетные записи, пароли, списки рассылки и псевдонимы
  5. Измените все записи DNS и перенаправьте на брандмауэре 25 порт на новый сервер (или не меняя DNS поменяйте местами IP-адреса серверов)
  6. Убедитесь, что новая почта приходит на новый сервер
  7. Убедитесь, что пользователи могут подключаться и работать с новым сервером
  8. Экспортируйте почтовые ящики на старом сервере и загрузите их на новый
Прежде чем продолжить

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

Важно! Прерывание работы любого из описанных ниже сценариев во время импорта может привести к повреждению базы данных, поэтому запускайте их из только из консоли сервера или используя команду screen! Мы вас предупредили.

Подготовка к переносу

Прежде чем начать экспорт нужно убедиться, что у нас достаточно места для хранения, которое доступно как со старого, так и с нового сервера. На старом сервере у меня совсем не было свободного места, тогда как на новом свободен был почти целый 1 ТБ, поэтому в моем случае было сделано удаленное монтирование NFS-ресурса с нового сервера и использование его в качестве промежуточного хранилища.

Вы можете использовать иные способы: USB-диски, сетевые ресурсы, iSCSI и т.д. В общем - на ваше усмотрение.

Следующие шаги предполагают, что промежуточное хранилище находится в /migration/zimbra, если ваш путь отличается, то вам нужно соответствующим образом изменить сценарии. Чтобы везде был порядок, мы будем использовать разные папки для разных файлов миграции, также убедитесь, что пользователь zimbra имеет полный доступ к папкам. Я бы порекомендовал:

chmod -R 777 /migration/zimbra
chown -R zimbra:zimbra /migration/zimbra Шаг 1. Экспорт доменов su - zimbra
cd /migration/zimbra
mkdir domains
cd domains
zmprov gad | tee -a domains.txt

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

cat domains.txt Шаг 2. Экспорт аккаунтов

Вернитесь в /migration/zimbra и создайте новый каталог accounts. Затем экспортируем туда учетные записи администраторов:

cd /migration/zimbra
mkdir accounts
cd accounts
zmprov gaaa | tee -a admins.txt

Посмотреть список экспортированных аккаунтов вы также можете командой cat, затем экспортируем пользовательские аккаунты:

zmprov -l gaa | tee -a users.txt Шаг 3. Экспорт данных учетных записей

Снова вернемся в /migration/zimbra и создадим новый каталог account_details, в него экспортируем данные учетных записей:

cd /migration/zimbra
mkdir account_details
cd account_details
for user in `cat ../accounts/users.txt`; do zmprov ga $user | grep -i Name: | tee -a $user.txt ; done Шаг 4. Экспорт паролей учетных записей

Также возвращаемся в /migration/zimbra, где создаем каталог passwords в который экспортируем пароли:

cd /migration/zimbra
mkdir passwords
cd passwords
for user in `cat ../accounts/users.txt`; do zmprov -l ga $user userPassword | grep userPassword: | awk '{ print $2}' | tee -a $user.shadow; done Шаг 5. Экспорт списков рассылок

Вернемся в /migration/zimbra и создадим каталог distribution_lists, в который выгрузим списки рассылок:

cd /migration/zimbra
mkdir distribution_lists
cd distribution_lists
zmprov gadl | tee -a distribution_lists.txt
for list in `cat distributinlist.txt`; do zmprov gdlm $list > $list.txt ;echo "$list"; done Шаг 6. Экспорт псевдонимов

Также создадим в каталоге /migration/zimbra директорию aliases и экспортируем туда псевдонимы:

cd /migration/zimbra
mkdir aliases
cd aliases
for user in `cat ../accounts/users.txt`; do zmprov ga $user | grep zimbraMailAlias | awk '{print $2}' | tee -a $user.txt ;echo $i ;done

Этот процесс займет некоторое время, в зависимости от количества учетных записей, а так как многие аккаунты не имеют псевдонимов, то мы получим много пустых файлов. Удалим их командой:

find . -type f -empty | xargs -n1 rm -v

Таким образом мы экспортировали со старого сервера все данные, кроме самих ящиков пользователей и любых созданных ими фильтров.

Шаг 7. Импорт доменов на новом сервере

Первый шаг в процессе восстановления на новом сервере заключается в восстановлении доменов, если вы уже создали основной домен, то можете удалить его из файла /migration/zimbra/domains/domains.txt.

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

chown -R zimbra:zimbra /migration/zimbra

для того, чтобы пользователь zimbra имел полный доступ к файлам и каталогам.

Давайте начнем, войдите в систему под пользователем zimbra и выполните следующие команды:

su - zimbra
cd /migration/zimbra/domains
for domain in `cat domains.txt `; do zmprov cd $domain zimbraAuthMech zimbra ;echo $domain ;done

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

Шаг 8. Импорт учетных записей и паролей

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

Перейдем в /migration/zimbra, где следует создать каталог scripts. В нем при помощи любимого редактора создадим и откроем файл restore_accounts.sh:

cd /migration/zimbra
mkdir scripts
cd scripts
nano restore_accounts.sh

Внесем в него следующие строки и сохраним:

#!/bin/bash
PASSWDS="../passwords"
ACCOUNT_DETAILS="../account_details"
USERS="../accounts/users.txt"
for i in `cat $USERS`
do
givenName=$(grep givenName: $ACCOUNT_DETAILS/$i.txt | cut -d ":" -f2)
displayName=$(grep displayName: $ACCOUNT_DETAILS/$i.txt | cut -d ":" -f2)
shadowpass=$(cat $PASSWDS/$i.shadow)
zmprov ca $i "TeMpPa55^()" cn "$givenName" displayName "$displayName" givenName "$givenName"
zmprov ma $i userPassword "$shadowpass"
done

Сделаем его исполняемым и запустим:

chmod +x restore_accounts.sh
./restore_accounts.sh

В процессе импорта вы можете время от времени получать сообщение об ошибке:

ERROR: account.ACCOUNT_EXISTS (email address already exists: admin@domain.com, at DN: uid=admin,ou=people,dc=domain,dc=com)

Это означает, что данные учетные записи уже существуют. Это справедливо для учетной записи администратора и служебных учетных записей, перед импортом вы можете удалить их из файла /migration/zimbra/accounts/users.txt.

Также имейте ввиду, что после выполнения сценария пароль администратора нового сервера будет заменен паролем со старого, если вы конечно не удалите запись admin@domain.com из users.txt

Шаг 9. Импорт списков рассылки

Перейдите в /migration/zimbra и выполните следующую команду, чтобы заново создать списки рассылки:

for lists in `cat distribution_lists/distribution_lists.txt`; do zmprov cdl distribution_lists/$lists ; echo "$lists -- done " ; done

Теперь заполним их, используя короткий bash-скрипт. Перейдем в /migration/zimbra/distribution_lists и откроем на редактирование скрипт restore_dist_lists.sh:

cd /migration/zimbra/distribution_lists
nano restore_dist_lists.sh

Внесем в него следующий текст:

#!/bin/bash
for list in `cat distribution_lists.txt`
do
for mbmr in `grep -v '#' ./$list.txt | grep '@'`
do
zmprov adlm $list $mbmr
echo " $mbmr has been added to $list"
done
done

Сделаем исполняемым и выполним:

chmod +x restore_dist_lists.sh
./restore_dist_lists.sh

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

Шаг 10. Импорт псевдонимов

Как вы уже догадались, перейдем в /migration/zimbra и создадим новый скрипт restore_aliases.sh:

cd /igration / zimbra / aliases
nano restore_aliases.sh

Внесем в него следующий текст:

#!/bin/bash
echo "Processing User accounts"
for user in `cat ../accounts/users.txt`
do
echo $user
if [ -f "./$user.txt" ]; then
for alias in `grep '@' ./$user.txt`
do
zmprov aaa $user $alias
echo "$user ALIAS $alias - Restored"
done
fi
doneecho "Processing Admin accounts"
for user in `cat ../accounts/admins.txt`
do
echo $user
if [ -f "./$user.txt" ]; then
for alias in `grep '@' ./$user.txt`
do
zmprov aaa $user $alias
echo "$user ALIAS $alias - Restored"
done
fi
done

Сделаем исполняемым и выполним:

chmod +x restore_aliases.sh
./restore_aliases.sh Шаг 11. Подключаем новый сервер к сети и переводим старый в автономный режим

На данный момент мы перенесли все учетные записи, псевдонимы и списки рассылки, фактически у нас есть полностью рабочий новый сервер. На всякий случай перезапустим службы zimbra и проверим их состояние:

zmcontrol restart
zmcontrol status

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

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

Также проверьте /var/log/zimbra.log на наличие ошибок.

Если все хорошо, то самое время переключить сервера. Есть два способа сделать это:

  • Измените все DNS-записи и переадресацию портов на брандмауэре на новый IP-адрес сервера
  • Дождитесь распространения DNS-записей, прежде чем продолжить миграцию

или же

  • Отключите новый сервер от сети
  • Измените его IP-адрес на адрес старого сервера
  • Измените /etc/hosts и настройки /etc/dnsmasq.conf соответственно
  • Перезапустите службы Zimbra
  • Убедитесь, что сервер может отправлять / получать электронную почту на адреса собственного домена
  • Отключите старый сервер от сети
  • Подключите новый сервер к сети
  • Измените IP-адрес старого сервера на неиспользуемый IP-адрес
  • Измените его /etc/hosts и настройки /etc/dnsmasq.conf соответственно
  • Перезапустите службы Zimbra
  • Подключите его снова к сети, чтобы продолжить миграцию данных

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

После переключения все пользователи, использующие IMAP или веб-клиент, обнаружат пустой почтовый ящик, но вся новая почта будет доставляться на новый сервер.

В последних шагах мы экспортируем содержимое почтовых ящиков со старого сервера и перенесем их на новый.

Шаг 12. Перенос данных почтовых ящиков

Это шаг будет наиболее продолжительным, в зависимости от объема ящиков он может занять сутки и более, импорт данных потребует столько же времени.

Теперь, когда пользователи могут отправлять и получать почту, мы не так ограничены по времени, на крайний случай можно обеспечить доступ к важным ящикам через веб-интерфейс по IP-адресу старого сервера.

Войдите на старый сервер через консоль или используя команду screen. Предполагается что промежуточное хранилище снова смонтировано на старом сервере по прежнему пути.

Сменим учетную запись на zimbra и перейдем в /migration/zimbra, затем начнем экспорт содержимого ящиков:

su - zimbra
cd /migration/zimbra
mkdir mailbox_data
cd mailbox_data
for user in `cat ../accounts/users.txt`; do echo "Exporting mailbox $user" ; zmmailbox -z -m $user getRestURL '/?fmt=tgz' > ./$user.tgz ; done

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

Если какие-либо ящики выдают ошибки во время экспорта, то запишите эти учетные записи, чтобы попробовать экспортировать их еще раз позже. Список таких аккаунтов разместите в /migration/zimbra/accounts/problematic_accounts.txt, затем можете повторить экспорт командой:

for user in `cat ../accounts/problematic_accounts.txt`; do echo "Exporting mailbox $user" ; zmmailbox -z -m $user getRestURL '/?fmt=tgz' > ./$user.tgz ; done

После того, как завершится экспорт содержимого ящиков, следует экспортировать пользовательские фильтры, для этого понадобится еще один скрипт, создадим новый каталог filters с файлом export_filters.sh в нем.

mkdir /migration/zimbra/filters
cd /migration/zimbra/filters
nano export_filters.sh

Внесем в него следующий текст:

#!/bin/bash
mkdir tmp
set -x
clear
for user in `cat ../accounts/users.txt`;
do
filter=`zmprov ga $user zimbraMailSieveScript > ./tmp/$user`
sed -i -e "1d" ./tmp/$user
sed 's/zimbraMailSieveScript: //g' ./tmp/$user > ./$user;
rm ./tmp/$user
echo "Export filter for $user"
done
\rm -rf tmp

Сделаем исполняемым и запустим:

chmod +x export_filters.sh
./export_filters.sh

Смонтируем, скопируем или иным образом перенесем промежуточное хранилище на новый сервер. Затем перейдем в /migration/zimbra/mailbox_data и выполним:

cd /migration/zimbra/mailbox_data
for mailbox in `cat ../accounts/users.txt`; do zmmailbox -z -m $mailbox postRestURL "/?fmt=tgz&resolve=skip" ./$mailbox.tgz ; echo "$mailbox - done "; done

Этот процесс также займет много времени, при этом пользователи могут продолжать использовать сервер, когда подойдет их очередь - они увидят, как их ящик начал заполняться письмами со старого сервера.

Если во время импорта вы получили ошибки, можно повторно выгрузить и загрузить проблемные учетные записи, соответственно изменив /migration/zimbra/accounts/users.txt и повторно выполнив команду экспорта. Если вы получаете ошибки типа broken pipe, это означает, что архив tgz был поврежден во время передачи по тем или иным причинам и не может быть распакован.

Давайте теперь импортируем пользовательские фильтры. Перейдем в /migration/zimbra/filters и создадим скрипт import_filters.sh:

cd /migration/zimbra/filters
nano import_filters.sh

Внесем в него следующие строки:

#!/bin/bash
for filter in ./*
do
if [ "$filter" == "./import_filters.sh" ] ; then
continue;
fi
if [ "$filter" == "./export_filters.sh" ] ; then
continue;
fiif [ "$filter" == "./tmp" ] ; then
continue;
fiFilter_String=`cat "$filter"`
Account=$filter
zmprov ma $(echo $filter | grep -E -o "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,6}\b") zimbraMailSieveScript '$Filter_String'
echo "Process filter $Account"
done
echo "All filter has been import successfully"

Сделаем исполняемым и выполним:

chmod +x import_filters.sh
./import_filters.sh Заключение

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

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

Источник: Migrating opensource Zimbra 8.6.0 on Centos 6.8 to Zimbra 8.7.1 on Centos 7 safely and with no downtime!

Перевод: Уваров А.С.

Сборка Squid 3.5 с поддержкой SSL из исходных кодов для Debian / Ubuntu

ср, 05/15/2019 - 23:58

Прокси-сервер Squid давно пользуется заслуженной популярностью, как открытое и эффективное средство контроля интернет трафика, но тенденции последних лет по массовому использованию защищенных соединений доставляют администраторам массу хлопот. Дело в том, что пакеты Squid в репозиториях дистрибутивов основанных на Debian или Ubuntu собраны без поддержки SSL, что делает невозможной фильтрацию шифрованного трафика. Что же делать? Собрать пакет с поддержкой SSL самостоятельно и сегодня мы расскажем, как это сделать.

Многих современных пользователей Linux пугает процесс сборки из исходных кодов и, надо сказать, не зря - это достаточно сложный процесс, требующий от собирающего определенных объемов знаний и навыков, особенно если что-то пойдет не так. Поэтому мы взяли на себя всю работу по нахождению правильного алгоритма, строго следуя котрому вы должны будете собрать пакет без каких-либо затруднений. Для тех, кто не хочет сам возиться со сборкой, мы также выложим уже собранные пакеты.

По этому поводу хотим еще раз напомнить: никогда не скачивайте пакеты из неизвестных источников, помните, что в такой пакет злоумышленники могут поместить вредоносное ПО. Также после скачивания всегда проверяйте контрольные суммы, чтобы удостовериться, что вы скачали именно то, что выложил автор.

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

В данной статье мы будем считать, что читатель знаком с базовыми навыками работы в среде Debian / Ubuntu и не будем подробно останавливаться на этих вопросах. Все описанные действия следует выполнять с правами суперпользователя.

Debian 9 / Ubuntu 18.04

Прежде всего откроем список источников пакетов /etc/apt/sources.list и убедимся, что репозитории с исходными кодами подключены, от обычных они отличаются адресом, имея в начале deb-src, а не просто deb. Обычно в Debian они по умолчанию подключены, а в Ubuntu отключены, для включения следует просто раскомментировать строки начинающиеся на deb-src. После чего следует обновить список пакетов:

apt update

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

apt install fakeroot build-essential devscripts

Добавим все необходимые пакеты для сборки Squid:

apt build-dep squid3

Установим библиотеку для поддержки SSL:

apt install libssl1.0-dev

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

Перейдем в домашнюю папку и создадим директорию для сборки, сразу установив на нее нужные права:

cd ~
mkdir build
chown _apt:root build

Перейдем в созданную директорию и скачаем исходные коды Squid:

cd build
apt source squid3

При этом сразу будут наложены все необходимые патчи и создана среда для сборки.

В директории build появится папка с именем squid3 и номером релиза, в нашем случае squid3-3.5.23, для осуществления сборки вы должны будете находится в ней.

Но перед тем, как собирать пакет укажем свои параметры сборки, а именно включим поддержку ssl, для этого во вложенной папке debain найдем файл rules и откроем его.

Найдем перечисление опций компиляции и добавим после них:

--enable-ssl \
--enable-ssl-crtd \
--with-openssl

Обратите внимание, что все строки, кроме последней, должны заканчиваться символом "\". Если вы все сделали правильно, у вас должно получиться так:

Сохраним этот файл, теперь можно собирать. Как мы уже писали выше, при сборке важно удостовериться, что вы находитесь в правильной директории, поэтому, на всякий случай, сменим ее принудительно:

cd ~/build/squid3-3.5.23

Совет: при наборе длинных путей используйте автодополнение по клавише Tab.

Для сборки пакетов выполните команду:

debuild -d

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

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

Вернемся в директорию build в которой обнаружим достаточно много deb-пакетов, но нам нужны не все, будет достаточно squid-common (архитектура all), squid и squidclient (архитектура amd64 или i386).

Готовые пакеты для Debian 9:

squid-common_3.5.23-5+deb9u1_all.deb (md5: C0FAF3CBF4B5C6F1A2073F70AB44A28E)
squidclient_3.5.23-5+deb9u1_amd64.deb (md5: F2CD156298E3FCC63643BB4BF8E9867E)
squid_3.5.23-5+deb9u1_amd64.deb (md5: 034916E02E7B7AE7DB96D5FDC72EA241)

Готовые пакеты для Ubuntu 18.04:

squid-common_3.5.27-1ubuntu1.1_all.deb (md5: BAD808B1C0EBC43468AF443356FD4625)
squidclient_3.5.27-1ubuntu1.1_amd64.deb (md5: 4C2F2CEE6C4FEBCA904D6FC775C16CBB)
squid_3.5.27-1ubuntu1.1_amd64.deb (md5: F934542502AC74FF23C8B213CD2CCDCB)

Кстати, для проверки контрольной суммы MD5 в Linux можете воспользоваться командой:

md5sum filename Ubuntu 16.04

Процесс сборки Squid для Ubuntu 16.04 ничем не отличается от сборки для Debian9 / Ubuntu 18.04 за одним небольшим исключением, вместо пакета libssl1.0-dev следует установить libssl-dev:

apt install libssl-dev Готовые пакеты для Ubuntu 16.04:

squid-common_3.5.12-1ubuntu7.6_all.deb (md5: 7D7CA3EECADEDD7572C4418D84574DBD)
squidclient_3.5.12-1ubuntu7.6_amd64.deb (md5: 65E261CCE66742D57FE8371F3B67D905)
squid_3.5.12-1ubuntu7.6_amd64.deb (md5: CFCEAF456AE456446A31A06E66668620)

RAID массивы - краткий ликбез

пн, 05/13/2019 - 01:00

RAID-массивы давно и прочно вошли в повседневную деятельность администраторов даже небольших предприятий. Трудно найти того, кто никогда не использовал хотя бы "зеркало", но тем не менее очень и очень многие с завидной периодичностью теряют данные или испытывают иные сложности при эксплуатации массивов. Не говоря уже о распространенных мифах, которые продолжают витать вокруг вроде бы давно избитой темы. Кроме того, современные условия вносят свои коррективы и то, чтобы было оптимальным еще несколько лет назад сегодня утратило свою актуальность или стало нежелательным к применению.

Чем является и чем не является RAID-массив

Наиболее популярен миф, что RAID предназначен для защиты данных, многие настолько верят в это, что забывают про резервное копирование. Но это не так. RAID-массив никоим образом не защищает пользовательские данные, если вы захотите их удалить, зашифровать, отформатировать - наличие или отсутствие RAID вам абсолютно не помешает. Две основных задачи RIAD-массивов - это защита дисковой подсистемы от выхода из строя одного или нескольких дисков и / или улучшение ее параметров по сравнению с одиночным диском (получение более высокой скорости обмена с дисками, большего количества IOPS и т.д.).

Здесь может возникнуть некоторая путаница, ведь сначала мы сказали, что RAID не защищает, а потом выяснилось, что все-таки защищает, но никакой путаницы нет. Основную ценность для пользователя представляют данные, причем не некоторые абстрактные нули-единицы, кластеры и блоки, а вполне "осязаемые" файлы, которые содержат необходимую нам информацию, иногда очень дорогостоящую. Мы будем в последствии называть это пользовательскими данными или просто данными.

RAID-контроллер о данных ничего не знает, он оперирует с блочными устройствами ввода-вывода. И все что поступает к нему от драйвера - это просто поток байтов, который нужно определенным образом разместить на устройствах хранения. Сам набор блочных устройств объединенных некоторым образом отдается системе в виде некоторой виртуальной сущности, которую принято называть массивом, а в терминологии контроллера - LUN, для системы это выглядит как самый обычный диск, с которым мы можем делать все что угодно: размечать, форматировать, записывать данные.

Как видим, работа RAID-контроллера закончилась на формировании LUN и предоставлении его системе, поэтому защита контроллера распространяется только на этот самый LUN - т.е. логическая структура массива, которую система видит как жесткий диск, должна уцелеть при отказе одного или нескольких дисков составляющих этот массив. Ни более, ни менее. Все что находится выше уровнем: файловая система, пользовательские данные - на это "защита" контроллера не распространяется.

Простой пример. Из "зеркала" вылетает один из дисков, со второго система отказывается грузиться, так как часть данных оказалась повреждена (скажем BAD-блок). Сразу возникает масса "претензий" к RAID, он все они беспочвенны. Главную задачу контроллер выполнил - сохранил работоспособность массива. А в том, что размещенная на нем файловая система оказалась повреждена - это вина администратора, не уделившего должного внимания системе.

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

BAD-блоки и неисправимые ошибки чтения

Раз мы коснулись содержимого, то самое время разобраться, что же с ним может быть "не так". Начнем с привычного зла, BAD-блоков. Есть мнение, что если на диске появился сбойный сектор - то диск "посыпался" и его надо менять. Но это не так. Сбойные сектора могут появляться на абсолютно исправных дисках, просто в силу технологии, и ничего страшного в этом нет, обнаружив такой сектор контроллер просто заменит его в LBA-таблице блоком из резервной области и продолжит нормально работать дальше.

Дальше простая статистика, чем выше объем диска - тем больше физических секторов он содержит, тем меньше их физический размер и тем выше вероятность появления сбойных секторов. Грубо говоря, если взять произведенные по одной технологии диски объемом в 1ТБ и 4 ТБ, то у последнего вероятность появления BAD-блока в четыре раза выше.

К чему это может привести? Про ситуацию, когда администратор не контролирует SMART и у диска давно закончилась резервная область мы всерьез говорить не будем, тут и так все понятно. Это как раз тот случай, когда диск реально посыпался и его нужно менять. Большую опасность представляет иная ситуация. Согласно исследованиям, достаточно большие объемы данных составляют т.н. cold data - холодные или замороженные данные - это массивы данных доступ к которым крайне редок. Этом могут быть какие-нибудь архивы, домашние фото и видеоколлекции и т.д. и т.п., они могут месяцами и годами лежать не тронутыми никем, даже антивирусом.

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

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

Ну и наконец самое интересное: неисправимые ошибки чтения - URE (Unrecoverable Read Error) или BER (Bit Error Ratio) - величина, показывающая вероятность сбоя на количество прочитанных головками диска бит. На первый взляд это очень большая величина, скажем для бытовых дисков типичное значение 10^14 (10 в 14 степени), но если перевести ее в привычные нам единицы измерения, то получим примерно следующее:

  • HDD массовых серий - 10^14 - 12,5 ТБ
  • HDD корпоративных серий - 10^15 - 125 ТБ
  • SSD массовых серий - 10^16 - 1,25 ПБ
  • SSD корпоративных серий - 10^17 - 12,5 ПБ

В данном случае в качестве единицы измерения мы использовали десятичные единицы измерения объема, т.е. те, что написаны на этикетке диска, исходя из того, что 1 КБ = 1000 Б.

Что это значит? Это значит, что для массовых дисков вероятность появления ошибки чтения стремится к единице на каждые прочитанные 12,5 ТБ, что по сегодняшним меркам не так уж и много. Если такая ошибка будет получена во время ребилда - это, как и в случае со сбойным сектором, эквивалентно отказу еще одного диска и может привести к самым печальным последствиям.

MTBF - наработка на отказ

Еще один важный параметр, который очень многими трактуется неправильно. Если мы возьмем значение наработки на отказ для современного массового диска, скажем Seagate Barracuda 2 Тб ST2000DM008, то это будет 1 млн. часов, для диска корпоративной серии Seagate Enterprise Capacity 3.5 2 Тб ST2000NM0008 - 2 млн. часов. На первый взгляд какие-то запредельные цифры и судя по ним диски никогда не должны ломаться. Однако этот показатель определяет не срок службы устройства, а среднее вермя между отказами - MTBF ( Mean time between failures ) - а в качестве времени подразумевается время работы устройства.

Если у вас есть 1000 дисков, то при MTBF в 1 млн. часов вы будете получать в среднем один отказ на 1000 часов. Т.е. большие значения оказываются не такими уж и большими. Для оценки вероятности отказа применяется иной показатель - AFR (Annual failure rate) - годовая частота отказов. Ее несложно рассчитать по формуле, где n - количество дисков:

AFR = 1 - exp(-8750*n/MTBF)

Так для одиночного диска массовой серии годовая частота отказов составит 0,87%, а для корпоративных дисков 0,44%, вроде бы немного, но если сделать расчет для массива из 5 дисков, то мы получим уже 4,28% / 2,16%. Согласитесь, что вероятность отказа в 5% достаточно велика, чтобы сбрасывать ее со счетов. В тоже время такое знание позволяет обоснованно подходить к закупке комплектующих, теперь вы можете не просто апеллировать к тому, что вам нужны корпоративные диски, потому что они "энтерпрайз и все такое...", а грамотно обосновать свое мнение с цифрами в руках.

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

Как можно видеть, в самом начале эксплуатации вероятность отказов наиболее велика, постепенно снижаясь. Этот период, обозначенный на графике t0 - t1, называется периодом приработки. В этот момент вскрывается производственный брак, ошибки в планировании системы, неверные режимы и условия эксплуатации. Повышенная нагрузка увеличивает вероятность отказов, так как позволяет быстрее выявить брак и ошибки эксплуатации.

За ним следует период нормальной эксплуатации t1-t2, вероятность отказов в котором невелика и соответствует расчетным значениям (т.е. тем показателям, которые мы вычислили выше).

Правее отметки t2 на графике начинается период износовых отказов, когда оборудование начинает выходить из строя выработав свой ресурс, повышенная нагрузка будет только усугублять этот показатель. Также обратите внимание, что функция износа изменяется не линейно, по отношении ко времени, а по логарифмической функции. Т.е. в периоде износа отказы будут увеличиваться не постепенно, а не сразу, но, с какого-то момента стремительно.

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

Для жестких дисков и SSD, согласно имеющейся статистики, период приработки где-то равен 3-6 месяцам. А период износовых отказов следует начинать отсчитывать с момента окончания срока гарантии производителя. Для большинства дисков это два года. Это хорошо укладывается в ту же статистику, которая фиксирует увеличение количества отказов на 3-4 году эксплуатации.

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

Немного терминологии

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

Весь входящий поток данных разбивается контроллером на блоки определенного размера, которые последовательно записываются на диски массива. Каждый такой блок является минимальной единицей данных, с которой оперирует RAID-контроллер. На схеме ниже мы схематично представили массив из трех дисков (RAID 5).

Каждая шайба на схеме представляет один такой блок, для обозначения которого используют термины: Strip, Stripe Unit, Stripe Size или Chunk, Сhunk Size. В русскоязычной терминологии это может быть блок, "страйп", "чанк". Мы, во избежание путаницы с другой сущностью, предпочитаем использовать для его обозначения термин Chunk (чанк, блок), в тоже время встроенный во многие материнские платы Intel RAID использует термин Stripe Size.

Группа блоков (чанков) расположенная по одинаковым адресам на всех дисках массива обозначается в русскоязычных терминах как лента или полоса. В англоязычной снова используется Stripe, а также "страйп" в переводах, что в ряде случаев способно внести путаницу, поэтому при трактовании термина всегда следует учитывать контекст его употребления.

Каждая полоса содержит либо набор данных, либо данные и их контрольные суммы, которые вычисляются на основе данных каждой такой полосы. Глубиной или шириной полосы (Stripe width/depth) называется объем данных, содержащийся в каждой полосе.

Так если размер чанка равен 64 КБ (типовое значение для многих контроллеров), то вычислить ширину полосы мы можем, умножив это значение на количество дисков с данными в массиве. Для RAID 5 из трех дисков - это два, поэтому ширина полосы будет 128 КБ, для RAID 10 из четырех дисков - это четыре и ширина полосы будет 256 КБ.

RAID 0

Перейдем, наконец от теории, к разбору конкретных реализаций RAID. Из всех вариантов RAID 0 - единственный тип массива, который не содержит избыточности, также его еще называют чередующимся массивом или страйпом (Stripe).

Принцип работы чередующегося массива прост - поток данных делится на блоки (чанки), которые по очереди записываются на все диски массива. При этом ни один диск массива не содержит полной копии данных, зато за счет одновременных операций чтения / записи достигается практически кратный количеству дисков прирост скорости. Объем массива равен сумме объема всех дисков.

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

RAID 1

Один из самых популярных видов массивов, знакомый, пожалуй, каждому. RAID 1, он же зеркало (Mirror), состоит обычно из двух дисков, данные на которых дублируют друг друга.

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

Но за это приходится платить большими потерями емкости - емкость массива равна емкости одного диска, поэтому зеркала с более чем двумя дисками на практике не используют. Также это негативно сказывается на быстродействии. Вспомним, что еще одной причиной объединения дисков в массивы является увеличение быстродействия, при этом важна не линейная скорость записи / чтения, а количество операций ввода вывода в секунду - IOPS - которые может предоставить диск.

В первом приближении общее количество IOPS массива - это суммарное количество IOPS его дисков, но на практике оно будет меньше за счет накладных расходов в самом массиве. В RAID 1 для выполнения одной операции записи массив производит две записи данных, по одной на каждый диск. Этот параметр называется RAID-пенальти и показывает сколько операций ввода вывода делает массив для обеспечения одной операции записи. Операции чтения не подвержены пенальти.

Для RAID 1 пенальти равно двум. Поэтому его производительность на запись не отличается от производительности одиночного жесткого диска. На чтение, теоретически, можно достичь двойной производительности за счет одновременного чтения с разных дисков, но на практике такая функция в контроллерах не реализуется. Поэтому чтение с зеркала также не отличается по производительности от одиночного диска.

Как видим, RAID 0 предоставляет нам высокую производительность при отсутствии надежности, а RAID 1 - высокую надежность без увеличения производительности. Поэтому существуют комбинированные уровни RAID, сочетающие достоинства нескольких типов массивов.

RAID 01 (0+1)

Этот тип массива часто путают с RAID 10, но это неверно, первым числом в наименовании массива всегда указывается вложенный массив, а вторым - внешний. Таким образом RAID 01 - зеркало из страйпов, а RAID 10 - страйп из зеркал. Какая разница? А вот сейчас и посмотрим.

Так как внешним массивом является RAID 1 - зеркало, то на оба вложенных чередующихся массива подается одинаковый набор данных, который распределяется без избыточности по дискам массива. В итоге получаем два одинаковых RAID 0 массива, которые собраны в зеркало.

Что случится при отказе одного диска? Ничего страшного, массив выдерживает такой отказ. А если выйдут из строя два? В этом случае возможны варианты:

Для массива из четырех дисков (а это минимальное количество для этого уровня RAID) у нас есть шесть вариантов отказа двух дисков. Исходя из того, что отказ из любого диска RAID 0 является для него фатальным, то получаем 4 отказа из 6 или 66,67%. Т.е. при потере двух дисков вы потеряете свои данные с вероятностью 66,67%, что довольно-таки много.

RAID 10

"Десятка" также собирается минимум из 4 дисков, но внутренняя структуре ее зеркально отличается от 0+1:

Массив верхнего уровня RAID 0 - делит входящие данные и распределяет их между низлежащими массивами RAID 1. В итоге получаем чередующийся массив из нескольких зеркал. В чем тут принципиальная разница с предыдущим массивом? А вот в чем, снова рассмотрим ситуацию отказа сразу двух дисков:

В отличие от страйпа, для отказа зеркала нужен выход из строя обоих диском массива и только эта ситуация приведет к полному отказу RAID 10, из 6 вариантов это произойдет только в двух случаях, т.е. вероятность потери данных при отказе двух дисков в RAID 10 равна 33,33%. А теперь сравните это с 66,77% у RAID 0+1, поэтому в настоящее время применяется исключительно RAID 10, так как при одинаковых показателях производительности обеспечивает гораздо более высокую надежность.

Пенальти RAID 10, также, как и RAID 1 равно двум, но за счет наличия четырех дисков он обеспечивает скоростные показатели аналогичные RAID 0 при надежности сопоставимой с RAID 1, емкость массива равна емкости половины его дисков.

На сегодня RAID 10 - наиболее производительный RAID-массив с высокой надежностью, его единственный и довольно существенный недостаток - высокие накладные расходы - 50% (половина дисков используется для создания избыточности).

RAID 5

Существует распространенное заблуждение, что RAID 5 (и RAID 6) - это более "крутые" уровни RAID, правда редко кто при этом может пояснить чем они "круче", но миф продолжает жить и очень часто администраторы выбирают уровень RAID исходя из таких вот заблуждений, а не реальных показателей.

Устройство RAID 5 более сложно, чем у "младших" уровней RAID и здесь появляется понятие контрольной суммы, на же Рarity, четность. В основу алгоритма положена логическая функция XOR (исключающее ИЛИ), так для трех переменных будет справедливо равенство:

a XOR b XOR c = p

Где p - контрольная сумма или четность. При этом мы всегда можем вычислить любую из переменных зная четность и остальные значения, т.е.:

a = p XOR b XOR c
b = a XOR p XOR c
c = a XOR b XOR p

Данные формулы остаются справедливы для любого количества переменных, позволяя обходится единственным значением четности. Таким образом минимальное количество дисков в RAID 5 будет равно трем: два диска для данных и один диск для четности. Раньше существовали реализации RAID 3 и 4, которые использовали для хранения блоков четности отдельный диск, что приводило к высокой нагрузке на него, в RAID 5 поступили иначе.

Здесь данные точно также разбиваются на блоки и распределяются по дискам, как в RAID 0, но появляется еще и понятие полосы, для каждой полосы данных вычисляется контрольная сумма и записывается в той же полосе на отдельном диске, т.е. один из дисков полосы выполняет роль диска для хранения четности. В следующей полосе происходит чередование дисков, теперь два других диска будут хранить данные, а третий четность. Таким образом достигается равномерное использование всех дисков, что снижает нагрузку на диски и повышает производительность массива в целом.

Основным стимулом создания RAID 5 было более оптимальное использование дисков в массиве, так в массиве из 3 дисков накладные расходы RAID 5 составят 33%, из 4 дисков - 25 %, из 6 дисков - 16%. Но при этом вырастает пенальти, в RAID 5 на одну операцию записи приходятся операции: чтение данных, чтение четности, запись новых данных, запись четности. Таким образом пенальти для RAID 5 составляет четыре.

Это означает, что производительность на запись массивов из небольшого числа дисков (менее 5) будет ниже, чем у одиночного диска, но производительность чтения будет сравнима с RAID 0. При этом массив допускает отказ любого одного диска.

В этом месте мы подходим к развенчанию одного из мифов, что RAID 5 "круче", нет, он не "круче", а по производительности даже уступает тому же RAID 10 (а иногда даже и зеркалу). Но по соотношению производительности, накладных расходов и надежности данный уровень RAID представлял наиболее разумный компромисс, что и обеспечило его популярность.

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

В отличие от RAID 1 / 10 при отказе диска RAID 5 не будет содержать полной копии данных, только их часть плюс контрольные суммы. Это означает что у нас появится пенальти на чтение - для чтения недостающего фрагмента данных нам потребуется полностью считать полосу и провести ряд вычислений для восстановления отсутствующих значений. Это резко снижает производительность массива и увеличивает нагрузку на него, что может привести к выходу из строя оставшихся дисков.

При отказе одного диска массив переходит в режим деградации, при этом по его надежность начинает соответствовать RAID 0, т.е. отказ еще одного диска, BAD-блок или ошибка URE могут стать для него фатальными. При замене неисправного диска массив переходит в режим реконструкции (ребилда), который сопряжен с высокой нагрузкой на оборудование, так как для восстановления контроллер должен прочитать весь объем данных массива. Любой сбой в процессе ребилда также может привести к полному разрушению массива.

А теперь вспомним значение URE для современных массовых дисков - 10^14, что это значит в нашем случае? А то, что собрав RAID 5 из четырех дисков на 4 ТБ (с объемом данных 12 ТБ) вы с вероятностью очень близкой к 100% получите невосстановимую ошибку чтения при ребилде и потеряете массив полностью.

Но это не значит, что RAID 5 изначально имел столь критические недостатки. Вернемся на 10 лет назад, основной объем ходовых моделей дисков тогда составлял 250-500 ГБ, URE для популярной тогда серии Barracuda 7200.10 был теми же 10^14, а MTBF был немного ниже - 700 тыс. часов.

Допустим мы собрали тогда массив из 4 дисков по 750 ГБ (топовые диски на тот момент), объем данных такого массива составит 2,25 ТБ, вероятность получить URE будет в районе 18%. В общем и целом - немного, большинство успешно реконструировало массив, а голоса тех, кому не повезло, тонули в общем хоре тех, у кого все было хорошо.

Но сегодня RAID 5 в принципе неприменим с массовыми сериями дисков, и с определенными оглядками применим на корпоративных сериях. Не смотря на более высокое значение URE последних, не будем забывать о возможных сбойных областях в зоне холодных данных, а чем больше объем дисков, тем больше секторов, тем больше вероятность сбоя в одном из них.

Также это хорошая иллюстрация пагубности мифов, так как собрав сегодня "крутой" массив RAID 5 вы с очень большой вероятностью просто угробите все свои данные при отказе одного из дисков.

RAID 5E

Как мы уже успели выяснить, ситуация с отказом одного из дисков является для RAID 5 критической - массив переходит в режим деградации с серьезным падением производительности и существенным ростом нагрузки на диски, а его надежность падает до уровня RAID 0 и любая ошибка способна полностью разрушить массив с полной потерей данных. Поэтому чем быстрее мы заменим сбойный диск - тем скорее выведем массив из зоны риска.

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

RAID 5E предлагает иной подход, пространство резервного диска разделяется между остальными дисками и остается неразмеченным в конце каждого диска массива.

Такой подход связан с некоторыми ограничениями, а именно - один раздел на один массив. Из плюсов - более высокая производительность за счет использования дополнительного диска. Что происходит при отказе? Массив автоматически начинает реконструкцию размещая данные в неразмеченной области (производит сжатие), после чего массив фактически превращается в простой RAID 5 и способен выдержать отказ еще одного диска (но не во время перестроения).

При замене неисправного диска массив переносит данные из резервной области на новый диск и снова начинает работать как RAID 5E (производит развертывание), при этом операция развертывания не сопряжена с дополнительными рисками, отказ диска или ошибка в данной ситуации не будут фатальными.

RAID 5EE

Дальнейшее развитие RAID 5E, в котором отказались из за размещения резервной области в конце диска (самая медленная его часть), а разбили ее на блоки и также как и блоки четности начали чередовать между дисками. Основное преимущество такого подхода - это более быстрый процесс реконструкции, а так как в этом состоянии массив особо уязвим, то уменьшение времени ребилда - это повышение надежности всего массива.

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

Также ни RAID 5E, ни RAID 5EE не лишились недостатка простого RAID 5 - на современных объемах массивов вероятность успешного ребилда такого массива очень невелика.

RAID 6

В отличие от RAID 5 этот массив использует две контрольные суммы и два диска четности, поэтому для него понадобятся 4 диска, при этом допускается выход из строя двух из них. Также, как и у RAID 5 алгоритм позволяет использовать всего две контрольные суммы вне зависимости от ширины полосы и общий объем массива всегда будет равен объему всех дисков за вычетом двух. При отказе одного диска RAID 6 выдерживает отказ еще одного, либо ошибку чтения без фатальных последствий.

Казалось бы, вот он - новый компромисс, замена RAID 5 в современных условиях и т.д. и т.п., но за все надо платить. Одна операция записи на такой массив требует большего количества операций внутри массива: чтение данных, чтение четности 1, чтение четности 2, запись данных, запись четности 1, запись четности 2 - итого 6 операций, таким образом пенальти RAID 6 равен шести.

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

И снова вернемся к мифам: RAID 6 это "круто"? Может быть, во всяком случае за свои данные можно не беспокоиться. А почему так медленно? Так это плата за надежность...

RAID 6E

По сути, тоже самое, что и RAID 5E. Резервный диск точно также распределяется в виде неразмеченного пространства в конце дисков, с теми же самыми ограничениями - один раздел на один массив. Ну и добавьте еще один диск в минимальное количество для массива, для RAID 5E это было 4, для RAID 6E - 5.

RAID 50 и RAID 60

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

Заключение

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

RAID 10 остается наиболее производительным массивом, но имеет большие накладные расходы - 50%.

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

При этом мы оставили за кадром многие технологии, скажем RAID DP - реализацию RAID 6 от производителя систем хранения NetApp, которая предлагает все достоинства RAID 6 вкупе в высокой производительностью, на уровне RAID 0. Или RAID-Z - систем на основе ZFS, которые являются программными реализациями и для обзора которых потребуется отдельная статья.

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

Установка и настройка Hyper-V Server 2016

пт, 05/10/2019 - 00:34

Продолжая тему виртуализации на основе Hyper-V в данном материале мы рассмотрим установку и настройку бесплатного гипервизора Hyper-V Server 2016. Основным отличием этой версии от Hyper-V как роли Windows Server является его полная бесплатность - вам не требуются лицензии на серверную версию ОС и благодаря минимальному числу служб повышается стабильность, уменьшается возможный периметр атаки и сокращаются затраты на обслуживание. За это приходится платить более сложным процессом установки и настройки о которых мы расскажем в данной статье.

На момент написания данной статьи Hyper-V Server 2016 является предпоследней версией гипервизора, однако в Hyper-V Server 2019 были обнаружены ошибки и релиз был отозван, в настоящий момент он недоступен для скачивания. А с учетом здоровой консервативности, версию 2016 можно смело рассматривать как основной гипервизор для современных внедрений, актуальность которого будет сохраняться еще как минимум в течении года - полутора, пока в новой версии найдут и исправят все ошибки, а также отшлифуют огрехи.

Получить Hyper-V Server 2016 можно на официальном сайте, для скачивания вам потребуется учетная запись Microsoft, либо будет необходимо заполнить небольшую анкету. При этом мы настоятельно не рекомендуем скачивать установочный образ из иных, непроверенных источников.

Установка и первоначальная настройка Hyper-V Server

Мы не будем подробно останавливаться на процессе установки - он ничем не отличается от установки других продуктов Microsoft и не должен вызвать каких-либо сложностей.

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

После чего нас встретит уже знакомый с версии Hyper-V Server 2012 текстовый интерфейс конфигурации сервера.

Если вы случайно закрыли это окно, то повторно его можно вызвать командой:

sconfig

Если же вы закрыли все окна и оказались перед пустым экраном, то нажмите Ctrl+Shift+Esc, данное сочетание клавиш работает в том числе и в RDP-сессии и вызывает диспетчер задач, с помощью которого вы можете запустить командную строку или утилиту конфигурации.

Далее идем практически по порядку. Но первым шагом следует изменить имя сервера на что-нибудь более информативное и удобное, в нашем случае это будет HV-CORE-2016. Затем, при необходимости, изменяем рабочую группу или присоединяем сервер к домену. Также рекомендуется добавить локального администратора, чтобы не использовать встроенную учетную запись.

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

Следующий пункт - Параметры центра обновления Windows имеют по умолчанию настройку Только скачивание, это означает, что установку обновлений вам надо будет запускать вручную. Если ваши виртуальные машины не предполагают режима работы 24/7 есть смысл рассмотреть вариант настройки Автоматически, тем более новая система обновлений предусматривает получение накопительного пакета один раз в месяц.

Затем включаем удаленный рабочий стол (пункт 7) и настраиваем сетевые параметры (пункт 8). Отдельным пунктом нас ожидает телеметрия (куда же без нее), полностью отключить ее невозможно, поэтому устанавливаем минимальный уровень - Безопасность.

После того, как вы настроили сеть дальнейшую работу с сервером удобнее производить по RDP, как минимум это позволить вам просто скопировать некоторые длинные команды. Но перед тем, как двигаться дальше следует скачать и установить доступные обновления (пункт 6).

В этом выпуске разработчики учли свои ошибки (в версии 2012 требовалось указывать совсем иные буквы, нежели было написано) и все параметры соответствуют указанным на экране, также, во избежание разночтений, используются только буквы латинского алфавита. Обновлений немного, всего три пакета, однако накопительный пакет старый - май 2018. Поэтому после установки обновлений их поиск следует повторить.

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

Для полноценного удаленного управления данным сервером нужно включить соответствующие правила брандмауэра, для этого выйдем в командную строку и запустим оболочку PowerShell:

powershell

Цвет окна при этом останется черным, но в начале приглашения командной строки появятся буквы PS. Затем последовательно выполним следующие команды:

Enable-NetFireWallRule -DisplayName "Инструментарий управления Windows (DCOM - входящий трафик)"
Enable-NetFireWallRule -DisplayGroup "Удаленное управление журналом событий"
Enable-NetFireWallRule -DisplayGroup "Удаленное управление Windows"
Enable-NetFireWallRule -DisplayGroup "Удаленное управление томами"
Enable-NetFireWallRule -DisplayGroup "Удаленное управление брандмауэром Windows"
Enable-NetFireWallRule -DisplayGroup "Удаленное управление назначенными задачами"

для англоязычного выпуска Hyper-V эти команды будут выглядеть следующим образом:

Enable-NetFireWallRule -DisplayName "Windows Management Instrumentation (DCOM-In)"
Enable-NetFireWallRule -DisplayGroup "Remote Event Log Management"
Enable-NetFireWallRule -DisplayGroup "Remote Service Management"
Enable-NetFireWallRule -DisplayGroup "Remote Volume Management"
Enable-NetFireWallRule -DisplayGroup "Windows Firewall Remote Management"
Enable-NetFireWallRule -DisplayGroup "Remote Scheduled Tasks Management"

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

Настройка клиента для работы с Hyper-V Server

Для работы с Hyper-V Server 2016 вам потребуется ПК с операционной системой Windows 10 версий Pro или Enteprise х64, иные редакции или 32-х разрядные версии не подойдут, так как в них нет возможности установить диспетчер Hyper-V.

Прежде всего проверим, что сервер доступен по своему сетевому имени, в доменной сети ему должна соответствовать A-запись на DNS-сервере, в одноранговой сети такую запись потребуется создать вручную на локальном DNS, либо добавить нужную запись в файл hosts клиентской машины, в нашем случае она выглядит следующим образом:

192.168.16.146 HV-CORE-2016

Если учетная запись под которой вы работаете на клиентском ПК отличается от учетных данных администратора Hyper-V, а это практически всегда так, даже если вы работаете в доменной сети (мы надеемся, что вы не используете в повседневной деятельности учетку Администратора домена), то следует явно указать учетные данные для соединений с сервером:

cmdkey /add:HV-CORE-2016 /user:Администратор /pass:MyPa$$word

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

Теперь запустим консоль PowerShell от имени Администратора и выполним следующую команду:

winrm quickconfig

Утвердительно отвечаем на все вопросы, при этом будет настроен автоматический запуск службы WinRM и созданы разрешающие правила в брандмауэре.

После чего добавим наш сервер в доверенные узлы:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "HV-CORE-2016"

Если серверов несколько - добавляем в доверенные каждый из них.

Теперь через командную строку или команду Выполнить (Win + R) запустим оснастку dcomcnfg, в ней разверните дерево Службы компонентов - Компьютеры - Мой компьютер. После чего по щелчку правой кнопки мыши выберите Свойства и перейдите на закладку Безопасность COM - Права доступа - Изменить ограничения и в открывшемся окне установите для пользователя АНОНИМНЫЙ ВХОД права Удаленный доступ.

Теперь попробуем подключиться к удаленному серверу. Запустите оснастку Управление компьютером и щелкнув правой кнопкой на верхнем уровне выберите Подключиться к другому компьютеру.

После чего вы сможете управлять удаленным сервером используя привычные инструменты. Можно просмотреть журнал событий:

Управлять заданиями планировщика, дисками, службами:

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

Теперь установим Диспетчер Hyper-V, для этого откроем оснастку Программы и компоненты и перейдем во Включение или отключение компонентов Windows. В открывшемся окне найдем пункт Hyper-V и отметим для установки Средства управления Hyper-V.

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

Для того, чтобы установить ОС на виртуальную машину нам потребуется передать на сервер Hyper-V установочный образ, это можно легко сделать через подключение к стандартным общим ресурсам, например, набрав в адресной строке проводника:

\\HV-CORE-2016\C$

мы попадем на диск C сервера.

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

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

Для примера мы создали новую виртуалку и без каких-либо проблем установили туда свежую Ubuntu 19.04.

Как видим, работа с Hyper-V Server 2016 не доставляет никаких сложностей, достаточно лишь один раз выполнить ряд действий по настройке сервера и клиента, в чем вам поможет данная статья.

Microsoft "разрешила" вынимать флешку без безопасного извлечения

чт, 04/25/2019 - 00:14

Вообще-то этой заметке самое место в отсутствующем на нашем блоге разделе "Юмор", но после того, как эту тему подняли практически все серьезные издания, стало как-то не смешно. Компания Microsoft широкой огласке придала факт того, что начиная с нового релиза 1809 была изменена политика по умолчанию в отношении внешних накопителей. Теперь вместо режима высокой производительности будет использоваться режим быстрого извлечения, что позволит просто отключать устройства без каких-либо подготовительных действий. Должно быть это "серьезное" нововведение, особенно с учетом получившейся огласки, но на самом деле все гораздо интереснее.

Да, мы понимаем, что в современном мире новостные издания иногда вынуждены буквально высасывать "новости" из пальца. Но когда о неком нововведении начинают писать далекие от IT издания, то возникают закономерные вопросы. Прежде всего о том, что освещаемое событие должно иметь определенную значимость далеко за пределами "узкого круга" IT специалистов. Скажем, когда об этом пишет Коммерсантъ:

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

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

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

Всю эту красоту нам обещают начиная с Windows 10 October 2018 Update она же версия 1809 build 17763.379.

Хорошо, но как быть с этим:

Windows 10 1803 build 17143.345

Политика по умолчанию - быстрое извлечение, т.е. анонсированная новость оказалась вовсе не новостью.

Windows 8.1 build 9600

Оказывается, спокойно выдергивать флешки можно было еще раньше, Windows 8.1 также имеет политику Быстрое удаление по умолчанию.

Windows 7 build 7601

Выдернуть флешку? В Семерке? Да выдергивайте на здоровье...

Windows Vista build 6002

Да, в наших закромах есть и Windows Vista, в ней тоже можно "небезопасно" извлекать флешки.

Windows XP build 2600

Вы, наверное, уже будете смеяться, но и в Windows XP политика по умолчанию - быстрое удаление (та самая, которую "включили" в 1809).

Windows 2000 build 2195

Ну наконец-то! Windows 2000 просто ничего не знает про эти ваши политики, хотя значок безопасного извлечения в трее у нее был.

И в чем тогда заключается "новость"? Которая "прокисла" где-то на 18 лет, если считать от даты выхода Windows XP. Хотя есть мнение, что причастные к ней в те далекие и светлые времена еще пешком под стол ходили и подробностей могут не знать...

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

Как увеличить размер программного RAID-массива в Linux

ср, 04/24/2019 - 03:07

Объемы данных в современных системах растут с каждым днем и тот объем, который еще вчера считался достаточным, сегодня уже не способен удовлетворить текущие требования. Также дешевеют носители данных, особенно это касается твердотельных накопителей, что рано или поздно поставит администратора перед необходимостью апгрейда дисковой подсистемы. Но как быть, если вы используете программный RAID в Linux? В этой статье мы рассмотрим наиболее часто встречающийся сценарий с заменой дисков на более емкие и расширением объема массива.

Несмотря на то, что в качестве примера мы использовали Debian 9 все нижеизложенное будет справедливо для любого базирующегося на Debian дистрибутиве, а с небольшими поправками (там, где касается установки загрузчика) для любой Linux-системы.

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

Итак, у нас в системе используются два виртуальных жестких диска объемом 20 ГБ которые мы хотим заменить на новые виртуальные диски объемом в 30 ГБ желательно без существенного простоя системы.

Прежде всего ознакомимся с текущей конфигурацией дисковой подсистемы. Будет очень полезно выполнить перезагрузку и войдя в BIOS уточнить с какого именно физического диска мы загружаемся.

В нашем случае это первый физический диск. Теперь загрузимся в систему и выполним команду:

lsblk

ее вывод позволяет в удобном виде увидеть структуру текущей дисковой подсистемы.

Как можно увидеть, в нашем случае на двух физических жестких дисках sda и sdb расположены два программных массива raid1: md0 с корневой файловой системой и md1 с разделом подкачки объемом 16,8 ГБ и 3,2 ГБ соответственно.

Следующим шагом нам нужно посмотреть разметку на физических дисках, это можно сделать при помощи утилиты fdisk, но лучше использовать ее аналог с псевдографическим интерфейсом - cfdisk. Запустим ее с указанием интересующего нас диска:

cfdisk /dev/sda

Здесь мы видим, что диск имеет таблицу разделов MBR (Label: dos в шапке) и содержит первичный раздел sda1 объемом 16,8 ГБ типа fd Linux RAID, а также логический раздел sda2, в котором находится еще один раздел типа fd Linux RAID размером 3,2 ГБ - sda5.

Запомним эти данные, так как аналогичную по структуре разметку нам нужно будет воспроизвести на новом жестком диске. Для этого нам нужно заменить один из старых дисков массива на новый, так как загрузились мы с первого физического диска, т.е. sda, то заменить нам следует sdb. Поэтому пометим его как сбойный для каждого из расположенных на нем массивов:

mdadm -f /dev/md0 /dev/sdb1
mdadm -f /dev/md1 /dev/sdb5

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

fdisk -l

Как видим в системе появился новый неразмеченный диск sdb объемом 30 ГБ. Теперь следует разметить его:

cfdisk /dev/sdb

Первым шагом указываем тип таблицы разделов, так как у нас уже используется MBR, то выбираем dos.

Теперь нам нужно создать аналогичную по структуре sda разметку, но с новыми разделами разделов. Единственное условие - они не должны быть меньше уже имеющихся. В нашем случае мы создадим первичный раздел объемом 26 ГБ и укажем для него тип Linux raid autodetect (fd) используя для этого кнопку Type утилиты.

Затем запишем изменения кнопкой Write. На оставшемся месте создадим расширенный раздел (extended) и внутри его еще один раздел Linux raid autodetect (fd). В итоге у вас должна получиться разметка аналогичная по структуре sda, но с новыми размерами разделов.

Теперь добавим вновь созданные разделы в массивы:

mdadm --add /dev/md0 /dev/sdb1
mdadm --add /dev/md1 /dev/sdb5

После чего убедимся, что начался процесс ресинхронизации:

cat /proc/mdstat

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

Вроде бы все хорошо, но не забываем про загрузчик, на новом диске его нет. Поэтому выполним:

dpkg-reconfigure grub-pc

Принимаем значения по умолчанию пока не появится окно с выбором дисков, указываем установку загрузчика на все физические диски, выбирать RAID-массив не надо.

Перезагружаем систему, выбрав в BIOS в качестве загрузочного устройства новый жесткий диск. Если все было сделано правильно, то вы загрузитесь уже с нового жесткого диска. Теперь нужно пометить sda как сбойный и исключить его из массива:

mdadm -f /dev/md0 /dev/sda1
mdadm -f /dev/md1 /dev/sda5

Выключаем сервер, физически заменяем диск на новый, загружаемся. Проверяем дисковую конфигурацию:

Как видим, теперь у нас в системе появился новый неразмеченный диск sda, но так как нам уже не нужно создавать разделы с отличным от sdb размером, то просто скопируем разметку с одного диска на второй, для этого используем еще одну утилиту sfdisk:

sfdisk -d /dev/sdb | sfdisk /dev/sda

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

Снова добавим разделы в массив:

mdadm --add /dev/md0 /dev/sda1
mdadm --add /dev/md1 /dev/sda5

Дождемся окончания ресинхронизации:

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

lsblk

и внимательно изучим вывод:

Несмотря на то, что мы увеличили размер sda1/sdb1 и sda5/sdb5 размеры массивов md0 и md1 остались неизменными. Но если мы вспомним, что программный RAID в Linux строится поверх разделов, то все станет на свои места. Это аналогично тому, что если бы мы заменили жесткий диск в системе на более емкий, но перенесли раздел без изменения размера.

Что делать? Расширить объем массива, для этого выполните команды:

mdadm --grow /dev/md0 --size=max
mdadm --grow /dev/md1 --size=max

Что у нас получилось?

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

df -h

Из ее вывода видно, что размер файловой системы не изменился и нам по-прежнему доступно около 17 ГБ. Но здесь нет никакой ошибки, если мы вспомним, что программный RAID является для системы аналогом диска, который содержит раздел с файловой системы, то поймем, что несмотря на то, что мы увеличили размер диска, нам следует также увеличить размер раздела с данными. Для этого выполним:

resize2fs /dev/md0

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

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

Админу на заметку - 23. Перед первым входом в систему необходимо сменить пароль. Как это сделать через RDP?

пн, 04/22/2019 - 20:23

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

Итак, в один не очень прекрасный вечер потребовалось нам поработать на одном удаленном сервере, который находился в одном из подразделений клиента, физически расположенным более чем в 500 км. Сервер новый, привычно подключаемся и что это?

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

Ну хорошо, подключимся простым пользователем, с этим проблемы нет, и запустим оснастку управления компьютером с повышением прав. Однако и тут нас постигло фиаско...

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

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

А если попробовать так? Нажимаем Ctrl + Alt + End (аналог Ctrl + Alt + Del для удаленного сеанса) в сеансе обычного пользователя (куда доступ у нас есть).

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

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

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

ОС Эльбрус 3.0 доступна для скачивания или что это было?

пн, 04/22/2019 - 18:10

Не столь давно на сайте компании МЦСТ появились в свободном доступе дистрибутивы отечественной ОС Эльбрус. На данный момент для скачивания доступна версия 3.0, более новый выпуск 4.0 по обещаниям будет доступен в мае. Данное событие не осталось незамеченным СМИ и практически сразу прошла волна сообщений от достаточно сдержанных, до типично "желтых", анонсировавшие чуть-ли не выход "убийцы Windows 10". Но мы привыкли руководствоваться собственным мнением и поэтому выделили некоторое время на личное изучение отечественной ОС.

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

Истина, как всегда, лежит где-то посередине. Что касается критически важных для безопасности страны сфер, то там использование непроверенного ПО в принципе недопустимо. Для этого существуют такие вещи как сертификация ФСТЭК или разработанная для Минооборны МСВС / Заря. Но это все специализированные решения, которые не относятся к теме отечественной ОС. Для чего вообще нужно отечественное ПО? Может быть мы придумываем велосипед?

Давайте оглянемся по сторонам и посмотрим, что делается в окружающем нас мире. Мы уже неоднократно упоминали в наших статьях Германию и ее попытки перевода муниципальных учреждений на Linux. Да, не все там гладко, но сама идея продолжает жить, и работа в этом направлении продолжается. Аналогичные проекты существуют во Франции, Испании, Великобритании. Или там тоже пилят деньги, а может весь мир против них?

Но нет, все достаточно проще. Сегодня компьютеризация проникла настолько глубоко, что трудно представить себе рабочее место без ПК, а это подразумевает неизбежные затраты на лицензии и создает определенную зависимость от поставщиков программного обеспечения. И если с первым все понятно, эти затраты в конечном итоге ложатся на плечи налогоплательщиков, т.е. нас с вами, то что касается зависимости, то здесь ситуация гораздо более тонкая. Скажем у нас есть определенное внутреннее ПО, которое требует для своей работы некоторых технологий, но поставщик ОС в новых версиях отказывается от их поддержки. Возникает интересная дилемма: либо тратить новые деньги на переработку существующего софта (про апгрейд ОС тоже не забываем), либо сидеть на снятой с поддержки ОС со всеми вытекающими отсюда рисками.

Именно отсюда и проистекает интерес многих стран к созданию собственного ПО на базе открытых технологий, в частности Linuх. Это позволяет собрать именно тот набор ПО, который нужен и поддерживать его в актуальном состоянии, не оглядываясь на сторонних производителей. Также это позволяет включить в состав системы некоторые специфические вещи, скажем отечественную криптографию.

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

ОС Эльбрус 3.0

Вернемся к герою нашего обзора, ОС Эльбрус 3.0, мы использовали версию PDK «Эльбрус» для x86, которая основана на Debian 8, что не может не радовать. Во-первых - не самый старый дистрибутив (но помним, что это не последняя версия Эльбруса), во-вторых - преемственность опыта, если вы умеете работать с любым базирующимся на Debian дистрибутиве, то работа с Эльбрус не должна вызвать затруднений.

Для установки мы использовали виртуальную машину VMWare Workstation c шаблоном Debian 8. Нас встречает текстовый инсталлятор, напоминающий очень старый инсталлятор Debian, по современным меркам работать с ним не очень удобно, но что есть - то есть.

Выбираем установку по умолчанию, настраиваем часовой пояс и попадаем к набору опций установки:

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

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

В наличии некие инструменты для разработки - meta-sp, неопознанный набор пакетов - meta-main-arm (судя по названию - что-то для ARM) и набор пакетов графической оболочки. Хотя на наш взгляд логичнее было бы увязать ее с предыдущим пунктом, так как вряд ли кто-то будет осознанно ставить графику и отключать ее автоматический запуск.

Этот пункт вообще можно было бы убрать куда-нибудь в дополнительные настройки, подавляющее большинство выберет стандартное ядро, а те, кому это действительно надо обладают нужной квалификацией для тонкой настройки дистрибутива (во всяком случае должны обладать).

Переходим к разметке дисков и неожиданно получаем ошибку:

При этом работа инсталлятора завершается, и чтобы почитать лог придется лезть в консоль. Очень скоро выяснилось, что Эльбрус не видит виртуальные SCSI-диски и таким образом реагирует на отсутствие доступных дисков. Проблема была решена сменой типа диска на SATA. Но здесь нас поджидал следующий сюрприз:

При том, что размер виртуального диска мы выбрали исходя из требований - 40 ГБ.

Целевой ВК должен соответствовать следующим требованиям:

  • процессор с архитектурой x86, х86-64;
  • объем оперативной памяти - не менее 1 Гбайт;
  • объем внешней памяти - не менее 40 Гбайт;
  • VGA-совместимый видеоинтерфейс;
  • наличие устройства DVD-ROM

Если попытаться продолжить установку - то она завершится ошибкой, поэтому мы увеличили размер диска до 60 ГБ и начали все заново. Схема разбивки диска на разделы также вызывает вопросы:

В частности выделения по 10 ГБ под /var и /tmp, в настольном применении это фактически неиспользуемое пространство, а в серверном 10 ГБ может и не хватить... Опять таки, если исходить из того, что разметку по умолчанию выбирают либо начинающие, либо для простых инсталляций (скажем рабочий ПК), то более правильным было бы применить принятый в других системах подход - все файлы в одном разделе. Кому нужна нестандартная разметка и кто знает зачем она ему нужна вполне способен разметить диск самостоятельно.

После разметки начнется процесс установки во время которого можно успеть сварить и выпить кофе, субъективно установка длится немного дольше, чем установка Debian, но и пакетов здесь ставится больше.

В завершение нас попросят настроить сеть, по умолчанию предлагается установить статический адрес, что для 2019 года как минимум странно...

Переключаем на автоматическое получение адреса и продолжаем, нам останется установить пароль для root и создать нового пользователя, на этом процесс установки будет закончен.

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

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

После чего мы ненадолго впали в ступор. А где панель? Или это новое слово в построении пользовательских интерфейсов? Как оказалось - панель есть, но она почему-то не видна. Почему - тоже выяснилось довольно скоро...

А теперь переключаем разрешение экрана с широкоформатного на классические 4:3 и панель появилась... Переключаем назад - исчезает. Точнее не исчезает, а остается в невидимой области экрана.

Почему так - вопрос интересный, тем более что в текущих реалиях найти в продаже монитор с соотношением 4:3 очень непросто. Чтобы вернуть панель на законное место пришлось немного пошаманить: переключаем режим панели с горизонтальной на вертикальную или боковую, меняем разрешение и переключаем обратно. Теперь все как нужно.

Что касается софта, то предустановлен стандартный набор открытого ПО, версии в большинстве своем не самые новые, но и не самые старые, примерно соответствуют Debian 8. В общем - работать можно.

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

А вот дальше оказалось все не так радужно. Звука нет, хотя виртуальную звуковую карту VMWare понимает практически любой Linux, графических инструментов для настройки принтера мы не нашли, а то, что нашли - не работает. Ну и репозиториев нет, совсем...

В принципе этого уже достаточно, чтобы поставить крест на всей этой затее. Зачем нужна система, если вы не можете в нее ничего установить и даже не можете нормально обновить. Скажем пакет rdesktop оказался версии 1.6.0 (от 2015 года), а это значит, что максимум с чем вы сможете соединиться - это Server 2008R2 (либо снижать параметры безопасности у современных систем). Хотя в том же Debian 8 в репозиториях доступна свежая версия пакета.

Ну ладно, это все-таки Linux, давайте попробуем что нибудь установить, зависимости, конечно, придется докачать руками... Но не тут-то было, оказывается, что архитектура x86_64 у Эльбруса совсем не тоже самое, что общепринятая amd64.

Почему и зачем так сделано - сказать трудно, возможно этому есть какие-то серьезные обоснования, но в данном случае это только усугубляет ситуацию. Конечно, можно включить архитектуру amd64, и она включится, но где брать пакеты? Выкачать руками половину Debian? Может тогда лучше просто его поставить?

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

Кстати, мы забыли про второй диск. На нем располагается, в терминологии Эльбрус, общее программное обеспечение (ОПО), для его установки требуется смонтировать диск в консоли и произвести установку пакетов. Никакого выбора не предлагается, можно поставить либо все, либо нужное (если вы знаете какой пакет вам нужен и если он там есть). Чтобы установить все следует ввести команды:

mount /dev/sr0 /mnt/cdrom
apt-get update
apt-get -fy --force-yes install all-packages

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

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

Выводы

После знакомства с ОС Эльбрус 3.0 нас преследует только один вопрос: а что это вообще было? С какой целью данная система была выложена в открытый доступ? Кому она предназначена? Разработчикам? Энтузиастам? Широким кругам?

По сути, в текущем виде Эльбрус ничем особо не отличается от какой-нибудь Haiku, только поставить и посмотреть. Реальная работа в нем невозможна, сугубо по причине отсутствия репозиториев и отличной от i386/amd64 архитектуры.

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

Зачем тогда было выкладывать Эльбрус в открытый доступ? Вопрос остается открытым, пока это похоже на формальное действо, поступила команда выложить - выложили, отчитались. Реального смысла в том, что сделано - немного. Если же преследовалась цель повысить интерес к Эльбрусу, создать вокруг него сообщество, привлечь разработчиков - то эффект получился ровно противоположным. Ну и появился очередной повод позлословить на тему российской "разработки".

Админу на заметку - 24. Как настроить несколько одновременных OpenVPN подключений в Windows

пт, 04/05/2019 - 23:06

OpenVPN можно без преувеличения назвать "народной" технологией для организации виртуальных частных сетей, но мы не будем сейчас перечислять все достоинства данного решения, а поговорим о иных вещах. Очень часто возникает необходимость иметь одновременные соединения сразу с несколькими OpenVPN серверами и нужно это далеко не только админам и прочим техническим специалистам. Но, как оказалось, даже в этой среде не все знают как это сделать, не говоря уже о представителях иных, "мирных", профессий. Поэтому наша сегодняшняя заметка посвящена этому, на первый взгляд простому, вопросу.

А в чем, собственно, проблема? А в том, что на платформе Windows при установке OpenVPN по умолчанию мы можем иметь только одно активное соединение в один момент времени, при попытке выполнить второе подключение мы получим ошибку:

Но в этом случае даже не нужно ничего искать, причина неудачного соединения написана красным по белому: все TAP-адаптеры в этой системе уже используются. Действительно, при установке OpenVPN в системе создается только один TAP-адаптер. Что делать? Добавить нужное количество адаптеров, по числу необходимых одновременных соединений.

Для этого перейдем в C:\Program Files\TAP-Windows\bin, где обнаружим пакетный файл addtap.bat, для добавления в систему еще одного TAP-адаптера следует запустить его с правами Администратора.

Если вам нужно добавить более одного TAP-адаптера - запустите данный файл нужное количество раз. В данной директории также содержится файл deltapall.bat, который позволяет удалить из системы все установленные TAP-адаптеры.

В нашем случае мы добавили два адаптера, что позволило без проблем иметь три одновременных подключения к разным OpenVPN серверам:

Как видим - ничего сложного нет, поэтому надеемся, что данный материал окажется вам полезен и позволит использовать OpenVPN с полной отдачей.

Настройка сканеров Datalogic QuickScan QD24XX для работы с маркированной табачной продукцией

чт, 04/04/2019 - 00:42

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

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

В нашем случае для работы с табаком были закуплены сканеры Datalogic QuickScan QD2400, хорошо показавшие себя при внедрении ЕГАИС и имеющие еще одно немаловажное достоинство: полную "совместимость" как по кабелю, так и по конструкции корпуса с предыдущей линейной моделью QuickScan Lite QW2100. Это позволило быстро заменить сканеры на кассовых узлах, не меняя уже проложенные кабели и продолжить использовать уже имеющиеся и закрепленные подставки.

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

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

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

Дальше проще, хорошо, когда знаешь, что искать и решение было найдено достаточно быстро. По умолчанию сканеры серии Datalogic QuickScan QD24XX / QBT24XX / QM24XX не работают с инверсными кодами, эта возможность включается отдельной настройкой. Для этого следует последовательно считать следующие коды (можно даже с экрана):

После этого сканер будет уверенно считывать как нормальные, так и инверсные коды. Ниже мы приводим PDF с инструкцией, которую можно распечатать и передать непосредственно в магазины (либо использовать для считывания с экрана).

Скачать

Мы надеемся, что данный материал окажется вам полезен и позволит сэкономить время при настройке сканеров серии Datalogic QuickScan QD24XX / QBT24XX / QM24XX для работы с маркированной табачной продукцией.

Proxmox Mail Gateway - настраиваем пограничный почтовый шлюз

вс, 03/24/2019 - 23:18

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

Чтобы понять место шлюза в вашей почтовой системе рассмотрим простую схему. Без шлюза весь поток входящей почты попадает прямо на основной сервер, который затем в меру своих сил будет пытаться ее фильтровать. Обычно это получается плохо, и большая часть нежелательной почты попадет в ящики получателей, вызывая, самое меньшее, их недовольство. Но с почтой могут быть связаны и более серьезные угрозы, такие как фишинг и вредоносное ПО, и не всегда эти угрозы удается блокировать на самом последнем этапе - чаще всего слабым звеном оказывается сам пользователь.

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

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

Тем более, что отправку с собственного сервера администратор вполне может контролировать, а если спам вдруг начнет отправлять вредоносное ПО, то оно вряд ли будет это делать через шлюз.

В качестве пограничного почтового шлюза мы будем использовать Proxmox Mail Gateway, бесплатное решение с открытым исходным кодом. Несмотря на то, что к продукту предлагается платная подписка, даже в бесплатной версии Proxmox Mail Gateway представляет собой достаточно эффективный и удобный инструмент для зашиты вашей почтовой системы. Продукт базируется на базе Debian, либо может быть установлен на эту систему как сервис. Но мы рекомендуем разворачивать его на выделенном сервере (можно виртуальном) из официального образа, который доступен на сайте разработчика.

Установка системы производится в графическом режиме и не должна вызвать сложностей, если у вас есть опыт установки Linux. Первым шагом нам предлагают настроить конфигурацию дисков, в качестве целей вам будут доступны одиночные диски, для того чтобы получить больше возможностей нажмите Options и появившееся окно даст вам настроить требуемую конфигурацию, например, создать RAID-массив.

В нашем случае было выбрано простое зеркало (RAID 1), настроек - необходимый минимум, запутаться решительно негде.

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

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

Сразу напомним, внутри обычный Debian, поэтому можем делать все, что сочтем нужным, например, доустановить для удобства администрирования Midnight Commander и любые иные утилиты. Но прежде всего следует отключить корпоративный репозиторий Proxmox, который доступен только по подписке:

rm /etc/apt/sources.list.d/pmg-enterprise.list

А затем создадим собственный лист:

touch /etc/apt/sources.list.d/pmg-no-subscription.list

И внесем в него следующее содержимое:

deb http://download.proxmox.com/debian/pmg stretch pmg-no-subscription

Теперь можно перейти в веб-интерфейс, в котором и будет происходить вся работа с почтовым шлюзом. Наберем в браузере указанный адрес, обязательно с указанием защищенного протокола HTTPS, для аутентификации используем пользователя root и указанный при установке пароль. Первоначально админка способна сбить с толку обилием разнообразных пунктов и опций, но сейчас нас интересует окончательная настройка шлюза.

Для этого перейдем в раздел Configuration, на верхнем уровне располагаются настройки сети и времени, некоторые дополнительные опции, такие как почта администратора, настройки статистики и ежедневной рассылки отчетов, а также резервное копирование и восстановление настроек. На данный момент ничего интересного для нас здесь нет, поэтому переходим уровнем ниже Configuration - Mail Proxy. Первый пункт Relaying содержит очень важную настройку пересылки почты, в пункте Default Relay следует указать ваш основной почтовый сервер.

В следующем пункте Relay Domain следует указать все обслуживаемые вашим почтовым сервером домены, в противном случае почта будет отклонена как как нежелательная.

На закладке Options обратите внимание на пункт Message Size - это предельный размер письма, который будет пропущен шлюзом, письма большего размера будут отброшены. Остальные опции мы пока трогать не рекомендуем, настройки Proxmox Mail Gateway достаточно эффективны и крутить настройки вручную следует уже с учетом фактического результата работы продукта.

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

А мы пока перейдем в раздел Spam Detector, в этом качестве используется SpamAssassin, из настроек следует также обратить внимание на размер письма и время нахождения спама в карантине, на закладке Update можно вручную обновить набор правил, хотя эта задача выполняется автоматически, по расписанию.

В разделе Virus Detector находятся настройки антивируса ClamAV, здесь также можно запустить его обновление вручную. Однако в этом процессе вы можете получить похожую "ошибку":

WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.100.0 Recommended version: 0.101.1

Но повода для беспокойства здесь нет, система обновляет пакеты ClamAV из репозиториев Debian, где последняя версия на момент написания статьи была 0.100.0, а с серверов ClamAV антивирус получил данные о наличии более новой версии 0.101.1. Однако на безопасность это влияет слабо, гораздо более важно своевременное обновление баз, а с этим у нас все в порядке.

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

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

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

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

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

Теперь покинем этот раздел и перейдем на самый верх, в Mail Filter, который содержит настройки фильтрации почты. На верхнем уровне расположены правила, указан их приоритет и направление действия, если выделить любое из них, то справа можно увидеть логику его действия.

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

Для построения правил используются несколько типов объектов:

  • Action Objects - действия, которые могут быть применены к письму. Могут быть окончательными или нет. К окончательным относятся три действия: Accept, Block и Quarantine, остальные действия не прерывают прохождение письма по цепочке правил.
  • Who Objects - субъекты, т.е. отправители или получатели почты, это могут быть почтовые адреса, домены, IP-адреса и подсети, пользователи и группы пользователей. Допустимо использование регулярных выражений. По умолчанию создано два объекта: глобальные белый и черный списки.
  • What Objects - свойства письма, это могут быть факты срабатывания спам и антивирусного фильтра, совпадение заголовков с заданным шаблоном, тип вложения, тип содержимого архива.
  • When Objects - временной промежуток, скажем рабочее время офиса.

Чтобы не быть голословными, составим собственное правило. В качестве вводной примем следующие условия: есть некоторые контрагенты, и их весьма много, которые посылают нам в рабочее время документы в формате PDF или XSL/XSLX с пустым телом письма и возможно даже без темы, документы могут быть в архиве.

Прежде всего перейдем в раздел What Objects и создадим новый объект, назовем его PDF & Excel, в который добавим четыре типа Content Type Filter, в которых укажем документы PDF, ХLS, XLSX и ODS (так как документ Excel давно стал понятием собирательным и нам вполне могут прислать таблицу в формате Open/LibreOffice). Затем добавим четыре типа Archive Filter с тем же самым содержимым, если документ придет запакованным в архив.

Следующим условием задачи у нас стоит время отправки подобной документации, условно примем его с 8:00 до 20:00, перейдем в раздел When Objects и создадим временной промежуток Work Time.

Теперь составим собственное правило, укажем его имя, приоритет и поставим флаг активности. Мы решили разместить его ниже проверок на черные/белые списки и вредоносное/опасное содержимое, но перед проверкой на спам.

Выберем созданное правило и в правой части экрана добавим What - PDF & Excel, Action - Accept. Данное действие является окончательным и дальше по цепочке такое письмо не пойдет.

И снова перейдем в раздел Administration, теперь нас будет интересовать управление карантином, для начала перейдем в Spam Quarantine. Здесь можно просмотреть письма, попавшие в карантин для каждого почтового ящика. Выбираем период времени и почтовый ящик, и получаем полный список попавших в карантин сообщений.

Для каждого сообщения доступен ряд действий, во первых добавление в персональный черный/белый список, но это действие не изменяет состояние письма, оно остается в карантине, при необходимости мы можем доставить его получателю (Deliver) или удалить (Delete), если не предпринять никаких действий, то такое письмо будет удалено по истечению срока хранения (по умолчанию 7 дней). Аналогичным образом работает и антивирусный карантин.

Здесь же доступно управление персональными черными/белыми списками пользователей, однако следует четко понимать, что использование персональных списков не должно подменять использования списков глобальных. Если прошедшее через фильтры письмо явный спам - то его следует добавить в глобальный список. Персональные списки следует использовать в тех случаях, когда требуется обойти глобальные правила. Скажем у вас глобально запрещены рассылки от различных интернет-магазинов, но отдел закупок наоборот хочет их получать - не вопрос, на помощь придут персональные списки.

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

Раздела Statistics мы подробно касаться не будем, там и так все понятно, статистика в различных ее видах.

В заключение хочется сказать, что Proxmox Mail Gateway показал себя как гибкое и эффективное средство борьбы со спамом, поэтому мы можем смело рекомендовать его к внедрению и надеемся, что данная статья окажется вам полезной.

Подключаем ККТ АТОЛ к 1С:Предприятие 8.3 в Debian / Ubuntu

вс, 03/10/2019 - 00:16

Продолжая серию статей по настройке онлайн-ККТ, мы не могли обойти стороной альтернативные ОС, тем более что АТОЛ поддерживает работу своих ККТ в среде Linux. Про установку 1С:Предприятие 8.3 в Debian / Ubuntu мы уже рассказывали ранее, теперь пришло время подключить к нашей 1С кассу. Скажем сразу - никаких сложностей при этом у нас не возникло, разработчики АТОЛ хорошо сделали свою работу, а следуя нашей инструкцией с данной задачей справится даже начинающий (тем не менее мы предполагаем, что читатель обладает базовыми навыками работы в среде Linux).

Данная статья является логическим продолжением нашего материала Подключаем ККТ АТОЛ к 1С:Предприятие 8.3, поэтому мы не будем повторяться и остановимся только на вопросах подключения и настройки ККТ в среде Linux. Если вы только начинаете работать с ККТ, то настоятельно советуем прочитать вам первую часть статьи, так как там затрагиваются общие вопросы по настройке кассы и работе с утилитой Тест драйвера ККТ.

Данная инструкция была проверена нами на Debian 9.7 и Xubuntu 18.04, но будет справедлива для любого дистрибутива на базе Debian или Ubuntu. Сама ККТ при этом подключается к ПК посредством интерфейса USB, как выбрать интерфейс подключения кассы мы рассказывали в первой части статьи.

Прежде всего скачаем из Центра загрузок АТОЛ свежие драйвера версии 10.х, они располагаются в разделе Контрольно-кассовая техника, архив универсальный и содержит драйвера для всех поддерживаемых платформ. Из всего архива нас интересует папка installer, в которой содержится папка deb, в ней находятся пакеты для архитектур i386, amd64 и arm. Следует иметь ввиду, что разрядность драйвера ККТ должна соответствовать разрядности платформы 1С. В Linux разрядность платформы как правило соответствует разрядности системы, однако если это не так, например, на 64-разрядную ОС установлена 32-разрядная платформа, то драйвер тоже следует установить 32-разрядный.

Из всего набора пакетов нас интересуют только три:

  • libfptr10 - драйвер ККТ
  • libfptr10-gui - графическая библиотека драйвера ККТ
  • fptr10-test-util - утилита Тест драйвера ККТ

Устанавливать их тоже нужно в указанном порядке, так как они имеют в зависимостях друг друга. Для этого перейдите в папку с пакетами и выполните с правами суперпользователя следующие команды (обратите внимание, мы устанавливаем 64-разрядные пакеты версии 10.4.5, в вашем случае имена пакетов могут отличаться):

dpkg -i libfptr10_10.4.5.0_amd64.deb
dpkg -i libfptr10-gui_10.4.5.0_amd64.deb

Графическая часть драйверов АТОЛ выполнена на базе Qt4 поэтому вы скорее всего при установке последнего пакета получите следующую ошибку:

Ничего страшного, с такими проблемами успешно справляется пакетный менеджер, для этого выполним:

apt install -f

Данная команда установит все недостающие зависимости и настроит пакет. После чего нам останется установить последний пакет с Тестом драйвера:

dpkg -i fptr10-test-util_10.4.5.0_amd64.deb

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

В последних релизах 1С драйвера для АТОЛ 10.х уже включены в состав конфигурации, если это не так, то драйвера следует загрузить отдельно, используя архив в папке 1С поставки драйверов.

Следует обратить внимание, что в Linux ККТ АТОЛ определяются не как два VCOM, а как одно USB-устройство, поэтому следует учесть этот момент при настройке:

На этом подключение ККТ можно считать законченным, дальнейшая работа с кассой ничем не отличается от Windows систем. Субъективные впечатления от работы ККТ АТОЛ в среде Linux у нас остались также положительными, разработчики поработали хорошо, никаких сбоев и нареканий по работе касс нами не выявлено.

Настройка EoU

После того, как касса настроена и работает, самое время перейти к настройке службы EoU, для этого скачаем одноименный пакет из Центра загрузок, он располагается в разделе Программное обеспечение - ДТО. Архив содержит набор различных версий утилиты, выбираем последнюю и переходим в директорию с утилитой для нужной нам архитектуры (i386 или amd64), разрядность следует выбирать согласно разрядности системы, вне зависимости от разрядности драйверов ККТ и платформы 1С.

Если мы перейдем в каталог с утилитой, то увидим там файл настроек settings.xml, бинарные файлы и библиотеки. В файле настроек должна присутствовать секция:

<hotplug>auto</hotplug>

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

Теперь нам надо разместить файлы в нужных местах файловой системы и настроить работу утилиты в качестве сервиса. Откроем в текущей директории терминал и поднимем права до суперпользователя. Начнем с настроек, создадим директорию /etc/ATOL/EoU и скопируем туда файл настроек:

mkdir -p /etc/ATOL/EoU
cp settings.xml /etc/ATOL/EoU/

Никаких дополнительных действий по настройке производить не нужно.

Саму утилиту мы разместим в opt (хотя вы можете выбрать иное расположение):

mkdir /opt/EoU
cp * /opt/EoU/

Теперь добавим нужным файлам права на исполнение:

chmod +x /opt/EoU/EthOverUsb*

Зарегистрируем утилиту как сервис:

/opt/EoU/EthOverUsb.sh -i

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

Прежде всего создадим сам файл юнита:

touch /etc/systemd/system/eou.service

Откроем его на редактирование и внесем следующий текст:

[Unit]
Description=ATOL EthernetOverUsb Service
After=display-manager.service
[Service]
Type=forking
User=root
ExecStart=/opt/EoU/EthOverUsb.sh
ExecStop=/opt/EoU/EthOverUsb.sh -t
[Install]
WantedBy=multi-user.target

Сохраним его и добавим в автозагрузку:

systemctl enable eou

Теперь мы можем управлять службой используя привычные команды:

service eou start|stop|restart|status

Можем перезагрузить систему и убедиться, что служба запускается автоматически. Лог работы службы располагается в /var/log/EoU, откроем его и убедимся, что утилита обнаружила кассу и обмен с ОФД проходит нормально:

При использовании автоматического определения кассы получают идентификаторы по имени порта, в нашем случае USB-3-1, если к узлу подключено несколько касс, утилита автоматически будет работать со всеми.

Как видим, ничего сложного в подключении и настройке ККТ АТОЛ в среде Linuх нет, пришлось только немного повозиться с утилитой EoU, но общий уровень проработанности и стабильности ПО от АТОЛ делает это всего лишь незначительным затруднением, тем более что в данном случае вполне справедливо будет высказывание "настроил и забыл".

Подключаем ККТ АТОЛ к 1С:Предприятие 8.3

сб, 03/09/2019 - 21:36

Как показывает практика, несмотря на то что онлайн-кассы применяются уже довольно давно, многие до сих пор не имеют четкого представления об их настройке и подключению к 1С, сталкиваясь в процессе со многими трудностями. Различные инструкции в сети тоже очень часто написаны на основании субъективного опыта и многие действия там напоминают более шаманские танцы с бубном, чем технически грамотные решения. Поэтому мы решили устранить этот пробел и описать подключение наиболее часто используемых онлайн ККТ к 1С:Предприятие.

Небольшое "лирическое" отступление. Контрольно-кассовая техника - это сложный программно-аппаратный комплекс, настройка и эксплуатация которого имеет свои особенности, связанные как с типом техники, так и с требованиями налоговых органов, поэтому для работы с ними необходимо иметь специализированные знания и опыт. Поэтому мы настоятельно не рекомендуем самостоятельно заниматься прошивкой и регистрацией ККТ.

Последствия ошибочных действий могут быть самые разные: от покупки нового ФН (фискального накопителя) до получения претензий и штрафов от налоговой инспекции. Если у вас нет подобного опыта - обратитесь в любое ЦТО, услуги прошивки ККТ и регистрации стоят недорого, тем более в сравнении с возможными последствиями неверных действий.

Итак, будем считать, что у вас в руках прошитая на актуальную версию и зарегистрированная ККТ АТОЛ, а также имеется действующий договор с ОФД. Вне зависимости от модели кассы и конфигурации 1С все дальнейшие действия будут одинаковыми, с возможными незначительными отличиями. Все кассовое ПО унифицировано, а работа современных конфигураций с торговым оборудованием построена на базе Библиотеки подключаемого оборудования (БПО), что также обеспечивает единый механизм настройки.

Прежде всего рассмотрим, какие интерфейсы связи предоставляют нам различные модели касс АТОЛ, если мы возьмем одну из младших моделей АТОЛ 11Ф, то сзади ее мы увидим:

Слева направо: Последовательный порт RS-232, USB, разъем питания и разъем для подключения денежного ящика. Если взять более дорогую модель АТОЛ FPrint-22ПТК, то набор разъемов может быть несколько шире:

Слева направо: питание, денежный ящик, RS-232, USB, Ethernet. Некоторые модели также могут иметь Wi-Fi модуль.

Для нормальной работы кассы нам надо обеспечить устройство двумя каналами связи: с ПК для взаимодействия с товароучетным ПО и с ОФД для передачи чеков. К ПК касса может быть подключена через RS-232, USB или сеть. Технически ККТ АТОЛ можно использовать как сетевые, однако такой режим не поддерживается со стороны 1С:Предприятие (хотя возможен при доработке ПО).

В ОФД чеки могут передаваться через сетевое подключение (Wi-Fi или Ethernet), либо через специальный транспортный протокол EoU (Ethernet over USB) при USB подключении.

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

Для младших моделей это практически единственный вариант подключения ввиду отсутствия сетевых интерфейсов, хотя существует еще Ethernet over RS для работы через COM-порт, но он более сложен в настройке и ограничен скоростью порта в 57600 бод, что не всегда приемлемо.

Ниже мы будем рассматривать вариант с подключением кассы по USB и использования EoU в качестве транспорта.

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

Следующим шагом нужно скачать и установить драйвера и ПО для работы с ККТ, для этого идем в Центр загрузки АТОЛ и в разделе Контрольно-кассовая техника скачиваем драйвер ККТ версии 10.

Из всего скачанного архива нам потребуется только одна папка installer, которая содержит установочные пакеты для Windows и Linux (DEB и RPM), обратите внимание, что разрядность пакета драйверов должна совпадать с разрядностью платформы 1С. А так как 64-разрядная платформа для Windows имеет ряд проблем с поддержкой торгового оборудования, то следует использовать 32-разрядную платформу и драйвера.

При установке выбираем Драйвер ККТ, EoU (отмечены по умолчанию) и интеграционную компоненту 1С. Однако, если вы забыли ее установить - ничего страшного, ее всегда можно получить из архива, где она находится в папке 1С.

Подключим кассу к ПК (если вы не сделали этого раньше), включим ее и перейдем в диспетчер устройств. Там мы увидим два виртуальных COM-порта со стандартными драйверами.

Драйвера требуется обновить на версию от АТОЛ, которые расположены в C:\Program Files (x86)\ATOL\Drivers10\KKT\USB_Drivers

После их установки список портов кассы должен принять следующий вид:

Теперь запустим приложение Тест драйвера ККТ и перейдем в Свойства, затем укажем канал связи COM/VCOM и выберем первый из портов, в нашем случае COM7, который предназначен для связи с ПК, второй порт - COM8 служит для связи с ОФД.

После чего нажмите Проверка связи и вы должны увидеть в сообщении наименование модели ККТ, ее серийный номер и статус фискализации.

Теперь самое время перейти в Параметры ККТ, где перед нами откроется следующее окно, в котором перейдем в пункт 15 ОФД, здесь следует проверить адрес и порт ОФД, а также правильно указать канал обмена, в нашем случае это USB (EoU).

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

И пункт 5 Печать, где можно выбрать шаблон чека, в нашем примере используется АТОЛ FPrint-22ПТК у которого доступны два шаблона: 1 - крупный и 2 - компактный. Так как онлайн кассы выводят на печать достаточно большое количество реквизитов, то следует использовать компактные шаблоны, это ускорит время печати чека и позволит существенно экономить кассовую ленту.

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

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

Следующий раздел, куда вам придется время от времени заглядывать, это Отчеты, в основном для того, чтобы выполнить закрытие смены в тех случаях, когда 1С закрыла смену в программе, но не смогла это сделать на ККТ (закончилась бумага или иной сбой). В этом случае просто выполняем печать Отчета о закрытии смены (он же Z-отчет, он же отчет с гашением) в Тесте драйвера.

Раздел ФН позволяет получить разного рода информацию о фискальном накопителе, практическую пользу представляет Статус информационного обмена, который позволяет проконтролировать количество неотправленных документов, при нормальной работе ККТ их быть не должно, либо должны быть объективные обстоятельства, мешающие отправке, например, перебои с доступом в интернет.

И, наконец, раздел Сервисные. Здесь следует установить в ККТ точное время, потому что при расхождении часов ККТ и ПК более чем на пять минут пробитие чеков будет невозможна. Также в данном разделе присутствует возможность программно перезагрузить ККТ, что удобно, если вы внесли изменения в настройки кассы удаленно.

На этом закончим настройки самой кассы и перейдем к 1С. В нашем примере используется конфигурация Розница 2.2, но с некоторыми поправками все нижесказанное будет применимо к любой современной конфигурации.

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

А затем загрузить компоненту, которая находится по пути C:\Program Files (x86)\ATOL\Drivers10\KKT\1Cv83, если же вы забыли ее установить вместе с ПО, то следует взять ее из архива с драйвером в папке 1С.

Затем возвращаемся в основное окно и переходим в раздел ККТ с передачей данных, где создаем новый экземпляр оборудования с драйвером версии 10.х.

В настройках устройства указываем первый виртуальный COM-порт, в нашем случае COM7 и проверяем связь нажатием кнопки Тест устройства. Учтите, что COM-порт не предусматривает одновременного доступа из нескольких программ и если вы забыли закрыть Тест драйвера или снять в нем флаг Включено, то 1С не сможет подключиться к кассе и сообщит вам, что Порт занят.

Дальнейшая настройка будет зависеть от используемой вами конфигурации и выходит за рамки данной статьи. Но в любом случае не забудьте указать адрес в настройках торговой точки и физическое лицо пользователю, который будет работать с кассой. В противном случае при попытке пробить чек вы получите ошибку с сообщением что один из реквизитов не заполнен (Адрес или Кассир).

Будем считать, что конфигурация у вас настроена, поэтому переходим к настройке службы EoU, которая отвечает за передачу чеков в ОФД. Данная служба является полностью консольной и не имеет графического интерфейса, настройка производится с помощью конфигурационного файла. По умолчанию он расположен в C:\ProgramData\ATOL\EoU, перейдем в указанную папку и откроем settings.xml. Он уже содержит некоторую информацию, но нас интересует только первая секция device, в теге id указываем название кассы, лучше давать осмысленные названия, особенно если у вас к узлу подключено несколько касс, это позволит быстро находить нужные строки в логе. В теге port указываем номер второго COM-порта, в нашем случае 8. Остальное содержимое файла можно удалить, если касс несколько - создаем несколько секций device.

Перезапускаем службу стандартным образом.

И открываем файл лога в C:\ProgramData\ATOL\EoU\logs, если все сделано нормально, то вы увидите процесс обмена рабочего процесса EoU (worker), который в логе обозначен присвоенным вами id, ККТ представлен как COM, а Ofd - это сервер ОФД.

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

Как видим, настройка ККТ АТОЛ не сложна, но требует ряда специфических операций и настроек, однако если внимательно следовать нашему руководству, то проблем у вас возникнуть не должно.

Исправление ошибки "Нарушена целостность структуры конфигурации"

сб, 03/02/2019 - 19:00

Ошибки информационной базы 1С:Предприятия - вещь крайне неприятная, особенно при отсутствии резервных копий. А если такая неприятность все-таки приключилась, то приходится порой принимать нестандартные и идущие в противоречие с общепринятыми практиками решения. Но это не должны быть шаманские камлания с бубном, а логически обоснованные и точно выверенные действия, которые позволят выйти победителем из, казалось бы, безнадежной ситуации. Сегодня мы расскажем об одном таком случае из нашей практики.

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

Не так давно к нам обратился один клиент с жалобой на то, что он не может обновить конфигурацию Розница 2.2, действительно, при попытке открыть конфигурацию появлялось сообщение Нарушена целостность структуры конфигурации.

При этом в повседневной жизни данная ошибка никак себя не проявляла, и утилита chdbfl также не нашла в базе каких-либо ошибок. Тем не менее база оказалась серьезно повреждена и любые попытки спасти ситуацию малой кровью: выгрузить данные в узел РИБ или посредством выгрузки-загрузки через XML приводили к ошибкам.

"А как-же резервные копии?" - спросит иной читатель. Резервные копии содержали точно такую же ошибку, так как она не препятствует выгрузке в DT файл и, тем более, архивированию непосредственно файла базы. Можно сказать, что клиент столкнулся с распространенной ошибкой начинающих администраторов, когда резервные копии создаются, но не проверяются.

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

На Инфостарте была найдена статья, которая на первый взгляд обещала привести к успеху, но все стало только хуже, раньше хотя бы конфигуратор открывался:

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

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

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

Не для кого ни секрет, что многие данные в информационной базе не меняются в течении длительного времени и поэтому нет необходимости каждый раз их запрашивать из БД, а можно поместить в локальный кеш и брать оттуда. Кеш делится на пользовательский, где хранятся данные, с которыми работает пользователь и кеш конфигурации, где сохраняются программные модули и данные о конфигурации. Первый располагается в перемещаемой части профиля пользователя %USERPROFILE%\AppData\Roaming\1C, а второй в его локальной части %USERPROFILE%\AppData\Local\1C.

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

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

В нашем случае проявлению указанной ошибки могла поспособствовать именно очистка кеша конфигурации. Если до повреждения ИБ конфигурация была открыта (а она была, т.к. базу обновляли), то при загрузке конфигуратора должны были быть подгружены кешрованные данные, что дало бы возможность либо обновить конфигурацию, либо загрузить ее из файла. После очистки кеша такая возможность пропала.

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

Поэтому мы пойдем другим путем, возвращаемся к сохраненной копии аварийной базы, запускаем ее в режиме конфигуратора, выходим. Тем самым мы создали нужную нам часть кеша, в которой не хватает информации об открытой конфигурации, попробуем дополнить ее из рабочей базы. Для этого возьмем файл 1Cv8.1CD из исправной базы точно такого же релиза и временно заменим им файл неисправной базы (исходный файл при этом следует сохранить).

Запускаем исправную базу в режиме конфигуратора и открываем конфигурацию, таким образом мы дополним уже существующий кеш нужными файлами. Закрываем конфигуратор, заменяем файл базы на исходный (неисправный) и снова запускаем конфигуратор. Как видим наши действия увенчались успехом, мы получили доступ к конфигурации поврежденной базы.

Теперь дело техники, снимаем поврежденную конфигурацию с поддержки и загружаем из файла конфигурацию того же релиза, которую можно выгрузить из заведомо исправной базы или взять из комплекта поставки. Сохраняем, обновляем конфигурацию базы данных.

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