Обновление OpenVPN до версии 2.1

Зачем это понадобилось? Раньше на маршрутизаторе работал в режиме сервера старенький openvpn-2.0.7 используя протокол udp. Работал он хорошо, но была у него проблемка. Маршрутизатор подключен к нескольким провайдерам и соответственно у него имеется несколько сетевых интерфейсов. Так вот, пока у openvpn-сервера отсутствовали подключения openvpn-клиентов, то первый клиент мог подключится через любой сетевой интерфейс. Но чуть появлялось первое клиентское подключение, то все последующие соединения могли быть установлены только через тот же самый интерфейс, т.е. через того же самого провайдера.

Формулируя другими словами, openvpn сервер версии 2.0 не может принимать клиентские udp подключения через разные сетевые интерфейсы.

Предполагаемые варианты решения:

1. Вместо udp использовать протокол tcp. Но во-первых, существует точка зрения что пропускать протокол tcp поверх протокола tcp это плохо. Во-вторых, хотелось бы избежать изменений в конфигурационных файлах клиентов, потому что их много и некоторые находятся в других городах.
2. Использовать bridging. По непроверенным данным, если несколько сетевых интерфейсов объединить в один мост, данной проблемы не наблюдается. Зато появляются другие, навроде свободного прохождения широковещательных пакетов между клиентами.
3. Обновить openvpn на маршрутизаторе до версии 2.1. В описании новых возможностей прямо говорится о решении данной проблемы: "multihome feature to enable UDP-based multihoming of the server on multiple interfaces". Единственный недостаток, на текущий момент OpenVPN 2.1 имеет статус бета-версии 2.1rc15.

Еще раз подчеркну, что выше перечислены только предполагаемые варианты решения. Фактически был опробован и оставлен в работе только вариант №3.

Подробно не буду останавливаться на процессе компиляции openvpn, т.к. пакетная система для каждого дистрибутива linux своя. Универсальный же способ из configure, make и make install, которым грешат многие статьи, гарантированно превращает вашу файловую систему в помойку. Для используемой у меня Slackware я уже описывал процесс пересборки tgz пакетов, как раз на примере openvpn. Всё что необходимо сделать — это выкачать свежий архив исходников и поменять версию openvpn в slackbuild-скрипте.

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

# compatibility with OpenVPN 2.0
script-security 3 system

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

Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:2: topology (2.0.9)

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

Несмотря на статус бета-версии никаких проблем в работе нового openvpn не наблюдается. Наоборот, новая для OpenVPN 2.1, возможность udp multihome заработала просто прекрасно. Теперь клиенты могут использовать для соединения того провайдера, который им удобнее, дешевле и т.д.

P.S. При сборке пакета для Slackware 9.1 штатный gcc-3.2.3 ниасилил сборку нового openvpn со следующим сообщением об ошибке:

ssl.c:3402:1: directives may not be used inside a macro argument
ssl.c:3401:92: unterminated argument list invoking macro "msg"
ssl.c: In function `key_method_2_read':
ssl.c:3403: invalid type argument of `->'
ssl.c:3408: syntax error before ')' token
make[2]: *** [ssl.o] Error 1

Тут ситуация не совсем понятна. Толи это убогая старая версия препроцессора С, толи разработчики OpenVPN используют приёмы программирования на грани разрешенного. Во всяком случае версия gcc-4.2.4 от новой Slackware 12.2 собрал этот пакет без проблем. Т.к. компилятор языка C написан на языке C, то сначала пришлось скомпилировать пакет с компилятором, обновить пакет gcc, а потом уж компилировать openvpn :)

Проблема при доустановке X-ов и KDE в Slackware

Симптомы. Дистрибутив Slackware 12.1. Сначала устанавливается только консольная часть системы. Позже, при доустановке X-ов и KDE, иксы отказываются запускаться с сообщением в /var/log/Xorg.0.log:

Fatal server error:
could not open default font 'fixed'

После долгих исканий помог следующий рецепт:

cd /
/var/log/setup/setup.04.mkfontdir
/var/log/setup/setup.05.fontconfig

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

При установке системы сразу с X-ами такого не наблюдается, т.к. запуск этих скиптов являются частью установки системы. Жаль, но это явная недорабтка в моём любимом дистрибутиве Linux. Зафиксировал описание отдельным постом, т.к. поиски решения в интернет затруднены. Результаты гугления уводят по ложному направлению проблем с неким X Font Server. Справедливости ради при должном упорстве описание решения можно найти.

Программно-аппаратные особенности терминалов Motorola MC9090

Я уже писал про программы для терминалов Motorola MC9090. Продолжаю свои заметки про этот промышленный терминал. Основная особенность — всего много.

4 вида памяти

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

Директория /Application — сверхпостоянная память, которая переживает даже сброс терминала к заводским настройкам. Примерный объем 20 Мб. Здесь можно хранить, например, дистрибутивы программ или какие-либо настройки реестра, которые могут понадобится после процедуры Clean Boot (см. ниже).

Директория /SD Card — дополнительная внешняя заменяемая флеш-карта.

Прочие директории — постоянная память, как в обычных КПК.

4 вида перезагрузки

Warm Boot — простая перезагрузка терминала.

Cold Boot — по документации это перезагрузка терминала с очисткой каких-то внутренних таймеров, т.е. вроде бы почти не отличается от Warm Boot. На практике же иногда терминал приходит в такое состояние, что перестает адекватно себя вести и Warm Boot просто не выполняется. Cold Boot же не подводил ещё не разу, однако его необходимо проводить только в безопасной зоне, т.к. необходимо извлекать основной аккумулятор.

Clean Boot — сброс операционной системы терминала к заводским настройкам. Выполняется с помощью специального программного обеспечения. Директория /Application сохраняет своё содержимое. Аналогично переустановке операционной системы.

Clean Boot с очисткой директории /Application — полный сброс состояния терминала к заводским настройкам. Никакие изменения сделанные пользователем не сохраняются. Аналогично форматированию всех винтов и переустановке операционной системы.

2 аккамулятора

В дополнение к основному аккумумятору терминал комплектуется дополнительной резерной батареей. Этим объясняется тот забавный факт, что иногда терминал показывает сообщения при извлеченном основном аккумяторе. В документации утверждается что резевная батарея может поддерживать терминал ещё как минимум 72 часа после разрядки основного аккамулятора.

Windows scripting: ведение журнала работы

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

Известно, что в unix-системах для журналирования используется протокол syslog (описан в rfc 3164). Однако, как обычно это делается в компании microsoft, в windows сделали похожее, но своё решение — службу «Event Log». Ну да и бог с ними, хорошо что вообще что-то сделали.

Рассмотрим, как отправить сообщение в журнал событий из vbscript. Для этого необходимо использовать метод LogEvent объекта WScript.Shell. Полный синтаксис можете посмотреть по приведенной ссылке сами, а мы рассмотрим пример вызова:

SET shell = CreateObject("WScript.Shell")
shell.LogEvent 4, "Hello world"

Все очень просто. Теперь давайте сохраним эти строчки в файле C:\scripts\event_log.vbs и запустим скрипт, например с помощью двойного клика по нему в проводнике. Далее, для посмотра сообщений используется неудобная программа «Event Viewer»:

1. Для запуска выполним «Start > Run...» и введем команду «eventvwr.msc»:

   

2. В левой части открывшегося окна выберем ветку «Event Viewer (Local) > Application»:

   

3. В правой части окна появится список событий. Созданное нами событие будет иметь тип «Information» и источник «WSH» и скорее всего будет первым в списке. Выполним на нём двойной клик и увидим диалоговое окно «Event Properties» с полной информацией о событии:

   

Теперь о грустном. В жертву простоты вызова из vbscript были принесены почти все возможности службы журналирования, даже те, жертвовать которыми не надо было. Самый главный недостаток — невозможно указать источник сообщения, у всех скриптов он всегда будет одинаковым и абстракным значением «WSH». Такое ощущение, что разработчики Windows Script Host даже представить себе не могли, что может потребоваться запускать более одного скрипта на компьютере.

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

SET shell = CreateObject("WScript.Shell")
shell.LogEvent 4,  WScript.ScriptFullName & " script start"

Вот событие полученное в результате отработки скрипта:

Замечание. Судя по содержимому документа «How To Use the Event Logging Utility (Logevent.exe) to Create and Log Custom Events in Event Viewer in Windows 2000» якобы, в наборе утилит «Windows 2000 Resource Kit» должна быть утилита logevent.exe позволяющая более гибко создавать записи в журнале событий из командной строки (аналог linux-утилиты logger). Но во-первых, никакого «Windows 2000 Resource Kit» на сайте http://www.microsoft.com/downloads/ обнаружить не удалось. Во-вторых, в присутствующем там «Windows Server 2003 Resource Kit» есть куча всякого говна, но этой утилиты уже нет. Можете конечно поискать (и даже найти) эти утилиты в интернете, но у меня что-то нет доверия полученным не из официальных источников программам.

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

 

Update

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

Set shell = CreateObject("WScript.Shell")
eventCreate "information", "Hello world"

' eventType - одно из success, error, warning или information
Sub eventCreate(eventType, message)
  logName = "application"
  source  = WScript.ScriptName
  eventID = 999

  Set re = New RegExp
  re.Pattern = """"
  re.Global = true
  message = re.Replace(message, "\""")

  command = "eventcreate "       & _
            "/l  "   & logName   & " " & _
            "/so "   & source    & " " & _
            "/id "   & eventID   & " " & _
            "/t  "   & eventType & " " & _
            "/d  """ & message   & """"

  resultBad = shell.Run(command, 0, true)

  if resultBad Then
    error = source & " :" & VbCrLf & _
            "error execute command" & VbCrLf & _
            command & VbCrLf & _
            "return code " & resultBad
    shell.LogEvent 1, error
  End If
End Sub

Программы от Motorola для терминалов MC9090

Так уж получилось, что мне пришлось заниматься разработкой для взрывозащищенного терминала «Bartec MC9090^ex». Он создан на базе промышленного терминала «Motorola MC9090» с операционной системой «Windows Mobile 5».

При разработке и внедрении использовалось дополнительное программное обеспечение, свободно предоставляемое компанией Motorola. Особенность данного программного обеспечения в том, что оно запускается только на устройствах компании Motorola. Соответсвенно запустить его на других windows mobile КПК или даже на эмуляторе КПК не удастся. Зато бесплатно. Несмотря на то, что я делал подборку для MC9090, многие программы будут работать на других устройствах Motorola.

Используемое программное обеспечение

909XCLEANERS

Выполнение процедуры Clean Boot (сброс к заводским настройкам), как с возможностью очистки директории \Application так и без оной.

AppCenter

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

AppLauncher

Удобное меню для запуска приложений. Можно делать подменю. Можно сменить картинку-логотип сверху. Настройка полностью через реестр windows.

Remote Capture

Создание разностных архивов (реестр и файловая система) после установки и настройки каких-либо программ на терминале. Может использоваться для резервного копирования или для тиражирования изменений на несколько устройств.

StartUp Control

Гибкое управление процессом автозагрузки после Cold Boot (перезагрузка) и Clean Boot (переустановка без очистки директории \Application). Скрипты автозагрузки имеют возможность устанавливать дистрибутивы программ, манипулировать файловой системой, реестром, задавать строгую последовательность запуска программ и паузы между запусками.

Symbol Mobility Developer Kit

Набор библиотек для языков и платформ: C, JAVA, .NET. Позволяют в программах использовать аппаратные особенности терминалов Motorola, например работать со встроенным сканером штрих-кодов.

Неиспользуемое программное обеспечение

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

iDockIt

Запуск каких-либо программ на терминале после его соединения с настольным компьютером через usb, serial и пр. Может сам устанавливать соединение по сети и запускать программы.

Symbol Configuration Manager

Настройка терминала с настольного компьютера. Возможность сохранять резервные копии настроек.

CtlpanelWM

Добавляет в панель управления windows апплеты для настройки аппаратных особенностей терминалов Motorola.

DataWedge

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

PocketBrowser

Непонятная серая хрень.

Keypad Mapping Table Kit

Переназначение кодов клавиш

Nullmailer — пересылка локальной почты на почтовый шлюз

Часто в организации имеется почтовый шлюз на базе одного этих почтовых серверов (MTA):
courier
exim
postfix
qmail
sendmail

Предположим что у нас имеется ещё один linux-сервер, с которого мы хотим отправлять почту. Конечно, можно использовать любую из вышеперечисленных программ, соответствующим образом настроенную для пересылки почты основному шлюзу. Но так лучше не делать, т.к. это большие, тяжелые и универсальные почтовые сервера, занимают много места в оперативной памяти, работают медлено и их труднее настроить. Для решения этой задачи существует класс программ, называемых relay-only MTA. Отличительные особенности этих MTA:

1. Не умеют получать почту по SMTP. Исходящая почта формируется только локально через интерфейс командной строки утилиты sendmail.
2. Доставка почты осуществляется заранее заданному удаленному SMTP серверу.
3. Как правило, не умеют больше ничего. Вообще ничего из того, что вы можете вспомнить из функций больших MTA. За счет этого работают максимально быстро.

Представители этого класса программ:
esmtp
masqmail
nullmailer
nbsmtp
ssmtp

Я использую nullmailer, т.к.:

1. Nullmailer очень прост в настройке. Фактически вся конфигурация, это несколько текстовых файлов в каждый из которых нужно поместить одну строчку.
2. Nullmailer не настолько примитивен, чтобы после получения почты, сразу в этом же процессе программы пытаться доставить почту удаленному SMTP серверу. Вместо этого он помещает письмо в локальную очередь доставки, что даёт нам сразу два преимущества. Первое, доставка почты идет быстрее, т.к. управление возвращается вызвавшей отправку почты программе. Дальнейшая обработка почты идет из отдельного процесса-демона nullmailer. Второе, при проблемах в сети или на почтовом шлюзе почта никогда не будет потеряна и будет доставлена сразу после устанения неполадок.

Покажем, как работать с nullmailer, на примере операционной системы Ubuntu. Допустим, мы хотим отправлять почту с машины webserv.localnet через почтовый шлюз mail.localnet. Соответсвенно все действия выполняются на машине webserv.

Установка:

xeim@webserv:~$ sudo aptitude install nullmailer

 

Минимальная настройка:

В файл /etc/nullmailer/remotes помещаем адрес почтового шлюза — «mail.localnet smtp».

В файл /etc/nullmailer/adminaddr помещаем адрес системного администратора — «admin@mycompany.ru» для получения локальной почты, например для root@localhost или user@webserv.localnet.

 

Запуск:

xeim@webserv:~$ sudo /etc/init.d/nullmailer start

 

Пример отправки почты:

xeim@webserv:~$ sendmail -f somebody@mycompany.ru
To: anybody@mail.ru
Subject: test

test

 

Журнал работы в /var/log/mail.log:

Sep 29 15:36:58 webserv nullmailer[14760]: Trigger pulled.
Sep 29 15:36:58 webserv nullmailer[14760]: Rescanning queue.
Sep 29 15:36:58 webserv nullmailer[14760]: Starting delivery, 1 message(s) in queue.
Sep 29 15:36:58 webserv nullmailer[14760]: Starting delivery: protocol: smtp host: mail.localnet file: 1222663016.14762
Sep 29 15:37:04 webserv nullmailer[14760]: smtp: Succeeded: 250 ok 1222663024 qp 2803
Sep 29 15:37:04 webserv nullmailer[14760]: Sent file.
Sep 29 15:37:04 webserv nullmailer[14760]: Delivery complete, 0 message(s) remain.

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

Таким образом, с использованием nullmailer возможно просто организовать отправку электронной почты через почтовый сервер организации.

Windows scripting: отправка электронной почты

К сожалению, в реальной жизни системному администратору приходится работать не только с unix-подобными системами. Иногда нужно решать задачи системного администрирования на плохо приспособленных и слабодокументированных операционных системах семейства windows. О таких хорошо зарекомендовавших себя инструментах как bash, perl или даже простой grep говорить не приходится. Что же мы имеем в наличии? Фактически имеется технология Windows Script Host с возможностью писать скрипты на языках JScript и VBScript. Мда, ну и выбор... и чтобы усугубить глубину собственного падения далее будем использовать язык VBScript.

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

Теория. Составной частью оперционных систем windows 2000/xp/2003 является динамическая библиотека сdosys.dll. Эта библиотека выдрана из почтового сервера MS Exchange и её функциональность сильно урезана. Тем не менее, с ее помощью можно сформировать сообщение электронной почты и отправить его внешнему почтовому серверу (MTA). Называется это счастье «CDO for Windows 2000», по ссылке доступна подробная документация из MSDN.

Решение. Исходный код скрипта email_notify.vbs:

Set email = CreateObject("CDO.Message")

With email.Configuration.Fields
    .Item("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2
    .Item("http://schemas.microsoft.com/cdo/configuration/smtpserver") _
        = "mail.localnet"
    .Update
End With

email.From = "robot@mycompany.ru"
email.To = "admins@mycompany.ru"

Set wshNetwork = WScript.CreateObject("WScript.Network")
email.Subject = wshNetwork.ComputerName & " включен"
email.Textbody = ""
email.TextBodyPart.charset = "koi8-r"

email.Send

Надеюсь, вам не составит труда пробится через синтаксис VBScript. Сам скрипт короткий и достаточно прозрачный для понимания. В основном используются методы объекта CDO.Message, они документированы по приведенной выше ссылке. Конечно, по сравнению с linux реализацией той же функциональности:

echo "" | mailx -s "`hostname` is up" admins@mycompany.ru

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

На этом собственно задача отправки электронных писем из windows скриптов решена. По двойному клику на файле email_notify.vbs скрипт выполнится. Однако, нам еще осталось рассмотреть тонкий момент запуска скрипта при загрузке операционной системы. Ярлык на такой скрипт нельзя помещать в меню «Startup» («Автозагрузка»). Ведь такие ярлыки обрабатываются не при загрузке операционной системы, а при начале сеанса конкретного пользователя. По той же причине не подходят и прочие места автозапуска, которые в большом количестве могут быть обнаружены на просторах реестра windows. Некорректно такой скрипт запускать и как системную службу. Вот правильное решение:

1. Выполняем команду «Start > Run...» и вводим магическую команду «gpedit.msc»:

   

2. В открывшемся окне с заголовком «Group Policy Object Editor» выбираем ветку «Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown)»:

   

3. Дважды кликаем на элемент «Startup» в правой части окна и появляется диалоговое окно «Startup Properties»:

   

4. Нажимаем кнопку «Add...». Во вновь отрывшемся диалоговом окне «Add a Script» задаем полный путь к нашему скрипту email_notify.vbs. Официально рекомендованный путь для размещения загрузочных скриптов — «C:\WINDOWS\system32\GroupPolicy\Machine\Scripts\Startup».

   

5. Нажимаем кнопку «OK», чтобы закрыть диалоговое окно «Add a Script». В списке скриптов диалогового окна «Startup Properties» появляется новый скрипт автозапуска.

   

6. Нажимаем кнопку «OK», чтобы закрыть диалоговое окно «Startup Properties». Закрываем программу «Group Policy Object Editor». Все, можно проверять запуск скрипта при загрузке.

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