вторник, 25 ноября 2008 г.

Проблема при доустановке 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. Справедливости ради при должном упорстве описание решения можно найти.

четверг, 6 ноября 2008 г.

Программно-аппаратные особенности терминалов 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 часа после разрядки основного аккамулятора.

четверг, 16 октября 2008 г.

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

пятница, 10 октября 2008 г.

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

Так уж получилось, что мне пришлось заниматься разработкой для взрывозащищенного терминала «Bartec MC9090ex». Он создан на базе промышленного терминала «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
Переназначение кодов клавиш

понедельник, 29 сентября 2008 г.

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 возможно просто организовать отправку электронной почты через почтовый сервер организации.

вторник, 19 августа 2008 г.

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 худо-бедно поддается автоматизации системного администрирования.

вторник, 22 июля 2008 г.

IP прокси средствами фаервола Linux

Здесь я покажу пример проксирования IP пакетов средствами межсетевого экрана операционной системы Linux.

Как известно, фаервол в Linux один — netfilter. И так как он давно встроен в ядро linux, то не понадобится устанавливать никаких дополнительных программ. Используемый дистрибутив Linux также не имеет значения.

Сначала несколько слов о том, зачем все это нужно. Например у нас есть две сети: «Сеть A» и «Сеть B» соединенные linux-маршрутизатором. Компьютеру клиента из «Сети A» необходимо получить доступ к серверу в «Сети B». Причем обе сети имеют сложную организацию, не являются простыми ethernet сегментами. У нас имеется контроль над компьютерами клиента, сервером и маршрутизатором. Над остальными частями сетей контроль отсутствует.

Проксирование ip трафика осуществляется с помощью следующих команд, выполняемых на linux-маршрутизаторе:

iptables -t nat -I PREROUTING         \
    -s 172.18.247.24 -d 172.18.55.17  \
    -j DNAT --to-destination 192.168.19.3

iptables -t nat -I POSTROUTING        \
    -s 172.18.247.24 -d 192.168.19.3  \
    -j SNAT --to-source 192.168.19.218

Первая команда создает правило фаервола, заставлюящее менять адрес назначения (destination) пакетов на адрес сервера в «Сети B». Второй вызов iptables меняет адрес источника пакетов (source) на адрес маршрутизатора в «Сети B».

С компьютера клиента нужно будет обращаться на ip адрес маршрутизатора. Например использовать URL http://172.18.55.17 или выполнить команду:

ping 172.18.55.17

Фактически же на запросы будет отвечать не маршрутизатор, а сервер. Причем со стороны сервера будет казаться что запросы поступают от ip адреса маршрутизатора в «Сети B», т.е. от 192.168.19.218. Таким образом в каждой из сетей будут бегать пакеты только между разрешенными хостами в данной сети и все будут жить долго и счастливо.