Первый стабильный релиз системы распознавания текстов Cuneiform 1.0

Вышла первая стабильная версия системы распознавания текста Cuneiform для платформы Linux. В новой версии проведена большая работа по исправлению ошибок и чистке исходных текстов, что дало разработчикам основание полагать о стабилизации кодовой базы проекта. Код Cuneiform для Linux распространяется под упрощенной лицензией BSD и основан на коде, открытом компанией Cognitive Technologies в 2007 году.

OCR CuneiForm может распознавать любые полиграфические, машинописные гарнитуры всех начертаний и шрифты, получаемые с принтеров за исключением декоративных и рукописных. В систему встроены специальные алгоритмы для распознавания текста с матричного принтера, плохих ксерокопий факсов и машинописи. Поддерживается более чем 20 языков. Отдельно стоит отметить отличную поддержку распознавания текста на русском и украинском языках. Результат распознавания может быть сохранен в форматах HTML, hOCR, RTF или PDF с сохранением особенностей начертания оригинала (выделение жирным, курсивом и т.д.).

Источник: www.opennet.ru

Watchdog для контроля состояния линка

Для контроля состояния линка будем пинговать шлюз провайдера. Утилита ping, идущая вместе с FreeBSD и Linux, нам не подходит, т.к. не выдает никаких сообщений при отсутствии ответа проверяемого хоста. То есть нам требуется поведение присущее ping из windows, выводящей в аналогичном случае «timeout». После недолгих поисков утилита oping оказалась идеальным кандидатом.
Собственно шаблон скрипта с подробными комментариями:

#!/bin/sh
# $1 - проверяемый IP-адрес
# $2 - режим работы скрипта

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# Выходим если не задан проверяемый IP
if [ -z $1 ]; then exit 1; fi

# Проверка режима работы
if [ -z $2 ]
then
 # Отслеживание падения линка

 # Создаем временный файл для хранения статуса линка
 SAVE=$(mktemp)
 # Ловим сигнал завершения и удаляем файл статуса
 trap 'rm -f $SAVE; exit 0;' INT TERM QUIT
 # Пингуем заданный IP-адрес с интервалом в 5 секунд
 # и с помощью xargs вызываем самого себя, передавая
 # результат пинга и имя файла состояния как параметры
 # командной строки.
 oping -4 -i 5 $1 | \
 sed \
  -e '1d' -e '/^--- /d' \
  -e '/packets transmitted/d' \
  -e '/^$/d' -u | \
 xargs -n 1 --delimiter='\n' -I'{}' $0 none check "{}" $SAVE \
 >> /var/log/vpn-watchdog.log
 # Удаляем файл статуса
 rm -f $SAVE
elif [ $2 = check -a ! -z $4 ]
then
 # Watchdog
 # $3 - результат пинга
 # $4 - имя файла состояния

 # Получение состояния линка
 STATUS=$(echo $3 | grep -oE '(ms|timeout)$')
 # Сравнение
 if [ ! -z "$STATUS" ]
 then
  # Определение состояния линка и исключение
  # ложного срабатывания
  if [ "$STATUS" = timeout -a "$(cat $4)" != $STATUS ]
  then
   # Реакция на событие
   echo -n "$(date +'%Y-%m-%d %H-%M-%S') TIMEOUT - Restarting... "
   # Далее идет несколько строк команд
   # ...
   echo " done!"
  fi
  # Сохраняем текущее состояние для последующей проверки
  echo -n $STATUS > $4 
 fi
fi

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

Аналог reply-to из PF в IPFW

Нашел интересную статью с описанием работы межсетевого экрана IPFW. В частности, упомянута реализация действия, аналогичного reply-to из PF:
«
Тот факт, что на самом деле "перепрыгивание" выполняется на параметры действия, позволяет использовать это для интересных вещей. В частности, с использованием появившегося во FreeBSD 6.2 параметра tag на каждый пакет можно навешивать внутриядерный тег, что в применении со skipto позволяет сделать, к примеру, запоминание, с какого шлюза пришел входящий пакет на машине с каналами к двум разным провайдерам, и ответные пакеты отправлять в тот канал, откуда они пришли (допустим, у вашей машины только один IP-адрес, и сделать fwd на базе внешнего адреса не получится), т.е. реализовать аналог reply-to из PF:

ipfw add 100 skipto 300 tag 1 in recv $ext_if1 keep-state
ipfw add 200 skipto 300 tag 2 in recv $ext_if2 keep-state
ipfw add 300 allow { recv $ext_if1 or recv $ext_if2 }  # входящие снаружи
ipfw add 400 allow in recv $int_if  # разрешить ответы на внутреннем проходе
ipfw add 500 fwd $gw1 tagged 1      # остались ответы на внешнем интерфейсе,
ipfw add 600 fwd $gw2 tagged 2      # зарулим их куда надо

»

Трансляция PPTP (GRE) на шлюзе с PF

Как известно, межсетевой экран PF, портированный в FreeBSD из OpenBSD, не может корректно транслировать (NAT) GRE-протокол и, к примеру, из локальной сети невозможно создать несколько одновременных соединений к внешнему серверу VPN PPTP.
Одним из способов решения проблемы является трансляция PPTP-соединений родным IPFW с «ядерным» NAT. При этом вовсе необязательно компилировать ядро. Все описанные действия проверены в FreeBSD версии 7.2. Но должно работать и в других версиях, где есть поддержка «ядерного» NAT для IPFW.

В «/etc/rc.conf» добавляем

#Включаем IPFW
firewall_enable="YES"
# Подгружаем модуль ядра ipfw_nat
firewall_nat_enable="YES"
# Указываем путь к скрипту загрузки правил
firewall_script="/etc/ipfw.script"

Создаем файл «/etc/ipfw.script»

#!/bin/sh

/sbin/ipfw -q /dev/stdin <<RULES
flush
#em0 - внешний интерфейс шлюза
nat 10 config if em0
#Правила для трансляции PPTP-соединения
add 10 nat 10 gre from any to any
add 11 nat 10 tcp from any to any dst-port pptp
add 12 nat 10 tcp from any pptp to any
# Разрешаем весь трафик
add allow all from any to any

RULES

Делаем скрипт исполняемым

# chmod +x /etc/ipfw.script

Добавляем в правила PF

# Запрещаем PF транслировать PPTP-соединения
no nat on $external_if proto gre all
no nat on $external_if proto tcp from any to any port = pptp
no nat on $external_if proto tcp from any port = pptp to any

... skip ...

# Пропускаем PPTP-соединения
pass quick on $external_if inet proto tcp from any to any port 1723
pass quick on $external_if inet proto tcp from any port 1723 to any
pass quick on $external_if inet proto gre from any to any

После всех сделанных изменений перезагружаемся.

Запрет запуска второй копии скрипта

Пример кода с пояснениями

#!/bin/sh

pid_file=/tmp/script-name.pid

#########################
# Создаем файл с правом только на чтение
# и вписываем туда идентификатор процесса (pid)
umask 333
(echo $$ > "$pid_file") 2>/dev/null

#########################
# Если процесс уже запущен, то попытка записи pid
# в файл будет завершена с ошибкой
if [ $? -ne 0 ]
then
        umask 22

        echo "Already started :("
        exit 1
fi

umask 22
#########################
# Что-то долго делаем...
#########################

#########################
# Удаляем файл с pid
rm -f "$pid_file"

xargs: многопоточная обработка

Благодаря посту Владимира Бредникова узнал, что xargs благодаря двум ключам помогает организовать многопоточную обработку файлов:

-n X

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

-P X

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

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

$ find ~/Photos -iname '*.jpg' -and -size +1M -print0 | \
  xargs -0 -n 1 -P 2 -I'{}' convert '{}' -resize '800x600>' -quality 100 '{}'

P.S. Надо почаще заглядывать в man :)

Простая конфигурация Netflow для сбора данных о трафике в FreeBSD

Чтобы конфигурация netflow загружалась во время запуска системы добавляем в «/etc/rc.local» следующие строки

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

/usr/sbin/ngctl -f - << EOF

mkpeer if0: tee lower left
name if0:lower tee0
connect if0: if0:lower upper right
mkpeer tee0: one2many left2right many0
name tee0:left2right one2many0
connect tee0:  one2many0: right2left many1
mkpeer one2many0: netflow one iface0
name one2many0:one netflow
mkpeer netflow: ksocket export inet/dgram/udp
msg netflow: setifindex { iface=0 index=0 }
msg netflow:export connect inet/127.0.0.1:7771

EOF

«if0» меняем на свой интерфейс. Если надо собирать данные с нескольких сетевых интерфейсов, множим блок «/usr/sbin/ngctl -f - << EOF ... EOF» и в каждом дополнительном блоке вместо «if0» вписываем нужный сетевой интерфейс. Так же меняем порядковые номера нодов и значение параметра «iface».
Чтобы загрузились необходимые модули добавляем в файл «/boot/loader.conf»

netgraph_load="YES"
ng_netflow_load="YES"
ng_socket_load="YES"
ng_tee_load="YES"
ng_iface_load="YES"
ng_one2many_load="YES"
ng_ksocket_load="YES"
ng_ether_load="YES"

Следующим шагом ставим коллектор netflow-трафика, прослушивающий порт «7771» по адресу «127.0.0.1».

Samba + pam_mkhomedir

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

Сперва убедитесь что smbd собран с поддержкой PAM

$ smbd -b | grep WITH_PAM

WITH_PAM

Если PAM не поддерживается, соберите Samba из исходников с ключом «--with-pam».
В файл «etc/smb.conf» (секция «global») добавляем

obey pam restrictions = Yes

Создаем шару для домашних папок пользователей

[homes]
       valid users = DOMAIN\%S
       read only = no
       browseable = no
       create mode = 0600
       directory mode = 0700

По умолчанию Samba считает, что домашние папки пользователей находятся в «/home/DOMAIN/user». Если вы хотите разместить их в другом месте, задайте явно параметр «template homedir» в секции «global» и рестартуйте winbindd.
Нужно создать директорию «/home/DOMAIN», так как pam_mkhomedir не умеет создавать вложенные директории

$ sudo mkdir /home/DOMAIN

Добавляем в файл «pam.d/samba»

session    required    pam_mkhomedir.so umask=0077

Под занавес ребутаем smbd.

vsftpd и pam_mkhomedir: «OOPS: Cannot change directory»

Столкнулся с тем, что модуль PAM pam_mkhomedir отказался работать с vsftpd. После захода на FTP не создаются домашние каталоги пользователей и соединение прерывается сообщением сервера об ошибке 500 «OOPS: Cannot change directory». А поиск в интернете ничего вразумительного не дал.
Как оказалось все решается одной строкой в «vsftpd.conf»:

session_support="YES"

Проблема возникает из-за того, что vsftpd по умолчанию не трогает модули сервиса session в PAM.

Настройка PPPoE (ADSL) в FreeBSD

Редактируем файл «/etc/ppp/ppp.conf»:

default:
  set log Phase tun command 
  set ifaddr 10.0.0.1/0 10.0.0.2/0

  disable ipv6cp
  set speed sync
  set mru 1492 
  set mtu 1492
  set ctsrts off

  # monitor line quality 
  enable lqr

adsl:
  # Ниже вместо if0 ставим свой интерфейс (ethernet),
  # по которому будем соединяться с провайдером.
  set device PPPoE:if0 
  # Данные авторизации
  set authname YOUR_NAME
  set authkey YOUR_PASSWORD
  set dial
  set login
  add default HISADDR

Проверяем написанное в интерактивном режиме

$ sudo ppp adsl

ppp on machine> set log +debug
ppp ON machine> dial
ppp ON machine>
Ppp ON machine>
PPp ON machine>
PPP ON machine>

При установке соединения с провайдером пользователь будет оповещаться о ходе подключения последовательным изменением регистра трёх букв «p» в консоли «ppp» со строчного на прописной.
Первая прописная буква оповещает о пройденном этапе проверки линии (LCP). Вторая буква — об успешной авторизации. Третья — вашей машине был присвоен IP адрес. Это означает что ваша машина успешно соединилась с сервером провайдера и теперь находится в сети.
Чтобы запустить ppp при загрузке системы необходимо добавить следующие строки в файл «/etc/rc.conf»:

ppp_enable="YES"
# Постоянное соединение. Восстанавливается после обрыва.
ppp_mode="dedicated"
# Если машина - шлюз в локальной сети.
ppp_nat="YES"
ppp_profile="adsl"

Если при попытке установки соединения выдается сообщение «Network is unreachable» закомментируйте приведенную ниже строку в «/etc/ppp/ppp.conf»

set dial

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

Узнать SOA обратной зоны

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

host -t soa `whois aa.bb.cc.dd | \
     grep -Ei "(inetnum|netrange):" | \
     tail -n 1 | sed -E 's/^.+:[ ]*//' | \
     xargs ipcount | grep -oE '[0-9]+(\.[0-9]+)*/' | \
     sed -E 's/\///' | head -n 1 | \
     awk -F . '{ print $4 "." $3 "." $2 "." $1 }' | \
     sed -E 's/^\.//;s/$/.in-addr.arpa/'`

где aa.bb.cc.dd - любой ip-адрес интересующего провайдера.

«Потерявшийся» dmesg.boot :)

Я этот файл в FreeBSD давно уже «потерял» и периодически удивлялся его отсутствию, когда заглядывал в «/var/log». А сегодня «нашел» в директории «/var/run».

Генерирование паролей. Акт второй.

#!/bin/sh
dd if=/dev/urandom count=6 bs=1 2>/dev/null | uuencode -m - | sed -n 2p

Удаленное управление сервером имён BIND9

Управление сервером имён BIND9 производится с помощью команды rndc. С его помощью можно удаленно обновить (или принудительно перезагрузить) зоны, сбросить кеш сервера или заморозить обновление динамических зон.

Сперва настраиваем BIND9

• Сгенерируем ключ «/etc/namedb/rndc.key»

  # rndc-confgen -u bind -a -b 256

• Создадим конфигурационный файл «/etc/namedb/rndc.conf»

  include "/etc/namedb/rndc.key";
  
  options {
      default-key "rndc-key";
      default-server 127.0.0.1;
      default-port 953;
  };

• Отредактируем файл «/etc/namedb/named.conf» и добавим

  include "/etc/namedb/rndc.key";
  controls {
      inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
      inet 192.168.0.xxx port 953 allow { 192.168.0.yyy; } keys { "rndc-key"; };
  };

  где «192.168.0.xxx» – ip-адрес сервера в сети, а «192.168.0.yyy» – ip-адрес компьютера администратора.
• Перезагружаем сервер имён

  # /etc/rc.d/named restart

• Проверяем

  # rndc reload
  server reload successful

Теперь настроим на стороне администратора

• Копируем с сервера файлы для rndc

  $ sudo scp -p admin@192.168.0.xxx:/etc/namedb/rndc.'*' /etc/namedb/

• Отредактируем файл «/etc/namedb/rndc.conf»

  include "/etc/namedb/rndc.key";
  
  options {
      default-key "rndc-key";
  #   default-server 127.0.0.1;
      default-server 192.168.0.xxx;
      default-port 953;
  };

• Проверяем

  # rndc reload
  server reload successful

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

• На стороне администратора сохраняем ключи с именами вроде «/etc/namedb/server-name.key» и редактируем

  key "rndc-server-name-key" {
       algorithm hmac-md5;
       secret "super-secret-password-hash=";
  };

• В файл «/etc/namedb/rndc.conf» добавим строки для каждого сервера

  include "/etc/namedb/server-name.key";
  server "server-name" {
      key "rndc-server-name-key";
  };

  «server-name» может быть именем сервера или его ip-адресом.
• Проверяем

  # rndc -s server-name reload
  server reload successful

  Если опустить параметр «-s» то будем «рулить» сервером, заданным по умолчанию в секции «options»

Отключение предстартового отсчета в FreeBSD

В файл «/boot/loader.conf» добавляем строку

autoboot_delay="0"

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

# sysinstall

В меню выбираем «Configure» → «Fdisk». Далее нажимаем «q» для выхода из программы разметки диска. В появившейся форме выбираем пункт «Standard — Install a standard MBR (no boot manager)» и выходим из программы.

Три опасные уязвимости во FreeBSD

Во FreeBSD обнаружены три новые уязвимости:

• "amd64 swapgs local privilege escalation " - локальный злоумышленник может выполнить код в системе с привилегиями ядра (root), изменив состояние стека пользовательского приложения и инициировав GPF (General Protection Fault) в момент передачи управления приложению, после обработки ядром прерывания, trap или системного вызова. Уязвимости подвержена только amd64 сборка всех поддерживаемых версий FreeBSD. Проблема устранена в 7.0-RELEASE-p4 и 6.3-RELEASE-p4.
• "nmount(2) local arbitrary code execution" - возможность выполнения кода локального злоумышленника в контексте ядра, в случае когда непривилегированным пользователям предоставлена возможность монтирования файловых систем. Уязвимость вызвана ошибкой в системном вызове nmount, передающем пользовательские данные ядру без надлежащей проверки границ. Проблеме подвержена только ветка FreeBSD 7, исправление внесено в 7.0-RELEASE-p4. В качестве временного решения можно запретить операции монтирования пользователям: "sysctl vfs.usermount=0".
• "Remote kernel panics on IPv6 connections " - удаленный злоумышленник может вызвать крах ядра (kernel panic), отправив по сети специальным образом модифицированный IPv6 (ICMPv6) пакет. Обязательным условием проявления уязвимости является необходимость наличия в системе IPv6 TCP сокетов, принимающих внешние соединения. Уязвимости подвержены все поддерживаемых версий FreeBSD, проблема устранена в 7.0-RELEASE-p4 и 6.3-RELEASE-p4.
  

Источник: www.opennet.ru

Exim & ldaps://

• Редактируем файл конфигурации Exim «etc/exim/configure»
  Строку

  ldap_default_servers = ldap.server.ru

  меняем на

  ldap_default_servers = ldap.server.ru:636

  Редактируем все запросы к LDAP.
  Пример правки:
  
  • старый

    domainlist local_domains = ${lookup ldap {LDAP_AUTH \
       ldap:///ou=Domains,dc=ldap-server,dc=intranet?dc?sub?\
       (&(objectClass=dNSDomain)(dc=$domain))}\
       {$value}}

  • новый

    domainlist local_domains = ${lookup ldap {LDAP_AUTH \
       ldaps:///ou=Domains,dc=ldap-server,dc=intranet?dc?sub?\
       (&(objectClass=dNSDomain)(dc=$domain))}\
       {$value}}

• В файл «etc/openldap/ldap.conf», чтобы разрешить самоподписанные сертификаты, добавляем строку

  TLS_REQCERT     allow

• После внесения изменений перезапускаем Exim

  # /usr/local/etc/rc.d/exim restart

Как увеличить размер раздела UFS

Небольшое отступление. В DomU на Ubuntu запущена FreeBSD с некими сервисами и которым стало не стало хватать свободного места, а ее файловая система размещена в логическом томе LVM «Xen_freebsd» из группы томов «Ubuntu».

• Увеличим размер логического тома «Xen_freebsd»

  # lvresize -L +32G /dev/Ubuntu/Xen_freebsd
  Extending logical volume Xen_freebsd to 48,00 GB
  Logical volume Xen_freebsd successfully resized

• Заходим по VNC на виртуальную машину и перезагружаем в однопользовательский режим.
• Следующим шагом растягиваем слой (slice) на весь диск

  # fdisk -I /dev/ad0

• Редактируем таблицу разделов и растягиваем [последний] раздел с данными на свободное место

  # disklabel -e /dev/ad0

  Вместо размера раздела «c» и раздела с данными (в моем случае это «h») ставим звездочку «*». Вместо звездочки будут подставлены нужные значения.
  

  # /dev/ad0s1:
  8 partitions:
  #        size   offset    fstype   [fsize bsize bps/cpg]
  a:   524288        0    4.2BSD     2048 16384 32776
  b:  2097152   524288      swap        
  c:        *        0    unused        0     0         # "raw" part, don't edit
  d:   524288  2621440    4.2BSD     2048 16384 32776
  e:  1048576  3145728    4.2BSD     2048 16384     8
  f:  1048576  4194304    4.2BSD     2048 16384     8
  g:  2097152  5242880    4.2BSD     2048 16384 28552
  h:        *  7340032    4.2BSD     2048 16384 28552

  Сохраняем таблицу и выходим из программы.
• Увеличиваем размер файловой системы

  # growfs /dev/ad0s1h

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

  # fsck -y /dev/ad0s1h

• Выходим из однопользовательского режима

  # exit

Быстрое создание файлов очень большого объема

Пример команды, создающей файлы очень больших размеров меньше чем за одну секунду

$ dd if=/dev/zero of=filename.img  bs=1 seek=SIZE count=0
0+0 records in
0+0 records out
0 bytes transferred in 0.xxxx secs (0 bytes/sec)

где SIZE - объем создаваемого файла, например «16G» (подробности в «man dd»).

Завершена работа над FreeBSD портом системы распознавания Cuneiform

Данный проект основан на исходниках, созданных и позднее открытых компанией Cognitive technologies. Порт основан на cuneiform-linux версии 0.3.1 и содержит дополнительные исправления из основного репозитория. Работоспособность порта была проверена на FreeBSD 6 и 7, архитектуры i386 и amd64.

Источник: www.opennet.ru