BiPrint под Windows 8.1 x64

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

Проблема возникает при попытке установке BiPrint на новые операционные системы. В частности, на Windows 8.1 x64. Кто пытался поставить BiPrint, знает, что последний требует файл ep200.gpd из драйверов старого Epson-принтера. Этот файл легко найти и скачать, однако, он не подписан Microsoft и нормальным образом не добавляется в систему.

Тем не менее, существует вполне рабочее альтернативное решение. Если коротко, то решается проблема следующим образом:

  1. Качаются подписанные Майкрософтом драйвера для принтера Epson PLQ-20 для ОС Windows 7 x64 и этот принтер добавляется в систему на какой-нибудь LPT-порт.
  2. Качается бипринт-клиент для Windows 7 и терминального сервера. Софтина устанавливается и в настройках указывается использование скачанных выше драйверов.
  3. В BiPrint выбирается любой из реальных принтеров и если вышеописанные шаги выполнены правильно, все работает.

Восстановление BIOS пароля из консоли

Оказывается, существует консольная Linux утилита для восстановления забытых паролей биос. И даже есть в дебиановских репозитариях. Будем иметь ввиду.

Тестирование каналов связи в Linux

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

iperf

Другая наиболее важная характеристика сети — скорость канала. Замерить скорость на прием и на передачу можно с помощью утилиты iperf. Для замера требуется запустить утилиту на одном из хостов в режиме сервера, а на другом — в режиме клиента. Запустим её в режиме сервера:

iperf -s

Если требуется проверять скорость до хоста постоянно, то iperf может быть запущен и в режиме демона с опцией -D.

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

iperf -c example.com -r -P 6

Аналогично можно запустить тестирование на одновременную передачу и приём:

iperf -c example.com -r -P 6

По умолчанию один тест длится 10 секунд. Время теста может быть изменено ключем -t, что бывает полезно для повышения репрезентативности результата. По умолчанию утилита тестирует канал по TCP-соединению. Тип соединения на UDP может быть изменен соответствующим ключом (-u), при запуске клиентской и серверной частей. iperf имеет много других полезных параметров (которые я редко использую) — они все естественным образом приведены в мануале.

mtr

Утилита mtr является аналогом другой широко известной утилиты сетевой диагности traceroute. Наиболее простой способ её применить — запустить с параметром другого хоста:

mtr example.com

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

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

mtr example.com -1000

Отключение toolbar в SyntaxHighlighter

Для вордпресса есть удобный плагин подсветки исходного кода SyntaxHighlighter MT. По умолчанию он отображает так называемый toolbar: маленький зеленый квадратик-ссылка с вопросом в крайнем верхнем углу текста. В документации на сайте разработчика описывается, как его можно отключить. Однако, канонического конфигурационного файла (как и конфигурации в самом WordPress) в плагине не наблюдается. Приходится идти обходным путём, а именно отключать toolbar в самом исходном коде. Сделать это можно, например, в файле brushTypes.js, определяющим типы подсветки для разных языков добавлением

SyntaxHighlighter.defaults['toolbar'] = false;

перед строчкой

SyntaxHighlighter.all();

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

Работа с пользовательскими crontab

Существует несколько способов управления пользовательскими кронтабами.

Редактирование с помощью crontab

Наиболее простой из них — редактирование файла с помощью crontab:

crontab -u USER -e 

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

crontab -e 

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

Копирование crontab вручную

Другой способ, обычно применяемый при переносе конфигураций серверов — копирование пользовательских кронтабов, находящихся в директории /var/spool/cron. При синтаксически корректных исходных конфигах способ работает безотказно. Единственное, что необходимо для его работы: «тронуть» (touch) конфиги после выкладки или перезапустить крон. Иначе, они не будут выполняться.

Импрорт в crontab из другого конфига

Метод реализуется командой

crontab -u USER /tmp/old-crontab

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

Способы переноса сиcтем контроля версий

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

Удаленный шелл с использованием nc

Фундаментальным и очень полезным качеством всех линуксов-юниксов является их модульность и возможность сборки из «кирпичиков» нужных инструментов. Это прекрасно иллюстрируется следующим примером из мануала утилиты netcat. Эта утилита передачи и приема произвольных данных по протоколам tcp/udp позволяет сделать элементарный и полностью рабочий шелл для работы с удалённым хостом. И это только используя эту утилиту и стандартные средства Linux вроде pipe и перенаправления данных.

На удалённой машине создаем трубу

$ rm -f /tmp/f; mkfifo /tmp/f

берем из неё данные, исполняем и результат толкаем в netcat, а его ответ обратно в трубу:

$ cat /tmp/f | /bin/sh -i 2>&1 | nc -l 127.0.0.1 1234 > /tmp/f

В результате получаем упрощённую нешифрованную версию ssh.

Пишем логи с помощью logger

Системное администрирование серверов в большой степени основано на регулярно исполняемых скриптах. Естественно, результат исполнения скриптов нужно проверять и иногда — логировать. Наиболее простой способ это сделать — использовать перенаправления ввода-вывода 2>&1 совместно с &>>. Однако, есть альтернативный (и в чём-то более удобный) способ это сделать, напрямую в syslog, с помощью команды logger. Тогда логирование сводится к командам вроде

some_script.sh 2>&1 | logger -i

Отдельная «поддиректория» для блога в WordPress

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

Для того, чтобы настроить WP, чтобы он добавлял префикс /blog в начале пермалинков делаем следующее:

  • В админке Settings -> Reading есть возможность настроить статические страницы по умолчанию (front pages) для основного сайта и для блога. Для сайта в случае использования WP как CMS она обычно настроена. Если не настроена, то создаём такую или выбираем из существующих. Для блога — создаем новую пустую и ставим к ней пермалинк /blog.
  • Выбираем созданные front pages соотвественно для основного сайта и для блога.
  • В Settings -> Permalinks меняем формат пермалинков для постов на /blog/%postname%. Предлагаемые по умолчанию настройки RewriteRules в .htaccess подходят и для нашего случая, их не трогаем.
  • Там же меняем базовый URL для категорий и тегов, например на blog/category и blog/tags.
  • Меняем внутренние линки на посты на новые, а также добавляем 301 редиректы со старых постов на новые.

После этого всё работает.

В интернетах находятся и другие how-to по данному вопросу. То, что выше — короткая выжимка из этого.

ssh/scp под Windows

Несколько решена проблема с доступом ssh/scp из под Windows. Cофтина позволяет монтировать ssh как логический том (sshfs). С её помощью может получиться неплохое решение для удалённых бэкапов из Windows под любые никсы. Жаль, что пока нет решения под Windows 8 и серверную 2012.

Удаление очень больших директорий в Linux

Современные файловые системы вроде ext3/ext4, xfs позволяют создавать в директориях очень большое количество файлов. В ряде случаев (обычно по ошибке или недосмотру) это реализуется на практике и тогда некоторые операции с такой директорией становятся очень медленными. Это касается прежде всего операций, требующих сортировку списка содержимого директории. Такая сортировка, например, происходит при вызове листинга ls, который по умолчанию сортируется, что естественным образом приводит к очень медленному исполнению команды. Также, большая директория очень медленно удаляется rm, поскольку последний формирует листинг.

Чтобы ускорить (а иногда и просто осуществить) удаление большой директории нужно отключить сортировку. Команда rm при удалении берет полностью список файлов, поэтому удалять очень большую директорию «в лоб» с помощью «rm -rf» очень неоптимальный вариант. Большую директорию удобнее удалять частями: листингом без сортировки некоторого количества файлов и их удалением. Сортировка в ls отключается параметром -U, что приводит к такой команде частичного удаления

ls -UA -1 . | head -n 1000 | xargs rm -f

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

while [ true ]; do ls -UA -1 . | head -n 100 | xargs rm -f 2>/dev/null; sleep 1; done

Альтернативный способ — изменить ionice процесса удаления.

Быстрый способ посмотреть релиз Linux

Наипростейший способ посмотреть информацию о ядре Linux и некоторую информацию о системе это команда uname:

$ uname -a
  Linux sonne 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 GNU/Linux

Более подробную информацию о системе можно насобирать в /etc. При этом краткая информация о релизе содержится в файле, который в разных дистрибутивах Linux называется по разному: lsb-release, redhat-release, os-release, centos-release, system-release. Поскольку файл везде оканчивается на -release, то можно не помнить всё это и получать информацию одной командой

cat /etc/*-release

Запуск крона чаще раза в минуту

Наибольшая частота, с которой cron запускается — 1 минута. При администровании серверов бывают ситуации, когда требуется более частый вызов, но конфиг crontab не позволяет этого сделать. Задача решается окольным способом, с помощью вызова нескольких инструкций и использования sleep. Например:

* * * * * /usr/bin/python /usr/local/bin/doit.py
* * * * * sleep 30; /usr/bin/python /usr/local/bin/doit.py

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

* * * * * /usr/bin/python /usr/local/bin/doit.py; sleep 30; /usr/bin/python /usr/local/bin/doit.py

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

Win7 RDP multiuser

Не работает удаленный рабочий стол на несколько пользователей после обновлений ноября 2014?
Сносим обновления KB2984972, KB3003743. После этого терминал снова отлично работает.

Зеркалирование TCP порта с помощью iptables

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

$IPTABLES -A FORWARD -p tcp --dport 2025 -j ACCEPT
$IPTABLES -t nat -A PREROUTING -p tcp -d $WAN_IPADDR --dport 2025 -j REDIRECT --to-ports 25

Или альтернативный вариант указать интерфейс:

$IPTABLES -A FORWARD -p tcp --dport 2025 -j ACCEPT
$IPTABLES -t nat -A PREROUTING -p tcp -i $WAN_DEV --dport 2025 -j REDIRECT --to-ports 25

После этого подключаться можно по обоим портам.

Собственные демоны в Linux с supervisor

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

/etc/init.d/somedaemon {start|stop|restart|reload}

или более новомодно

service somedaemon {start|stop|restart|reload}

Чтобы не писать «велосипеды», можно воспользоваться supervisor. По сути он предоставляет инфраструктуру для управления демонами с логикой сходной с init.d-скриптами. Утилита отлично находится и ставится из репозитариев, конфиги к ней очень простые.

Разный вывод di и df в Linux

Интересные дела…

user@server:~$ di
Filesystem         Mount               Size     Used    Avail %Used  fs Type
/dev/md0           /                   1.9G     0.4G     1.4G   26%  ext4   
udev               /dev                5.9G     0.0G     5.9G    0%  tmpfs  
tmpfs              /dev/shm            5.9G     0.0G     5.9G    0%  tmpfs  
tmpfs              /lib/init/rw        5.9G     0.0G     5.9G    0%  tmpfs  
/dev/shm           /run/shm            5.9G     0.0G     5.9G    0%  none   
/dev/md1           /usr                9.4G     0.8G     8.1G   14%  ext4   
/dev/md3           /var                1.8T     0.1T     1.6T   11%  ext4   

user@server:~$ df 
Filesystem      1K-blocks      Used  Available Use% Mounted on
/dev/md0          1966404    416816    1449700  23% /
tmpfs             6163396         0    6163396   0% /lib/init/rw
udev              6157924       228    6157696   1% /dev
tmpfs             6163396         4    6163392   1% /dev/shm
/dev/md1          9842136    833200    8508972   9% /usr
/dev/md3       1899242804 108050616 1694716184   6% /var

phpmyadmin за SSL-фронтендом nginx

Администрировать БД MySQL часто бывает удобно с помощью phpmyadmin. Естественно, пользоваться им необходимо безопасно, т.е. через https.

Простой вариант решения заключается в указании явного URL для пхпмайадмина в его конфиге:

$cfg['PmaAbsoluteUri'] = 'https://admin.example.com/pma';

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

Альтернативный вариант — передавать порт, по которому идет соединение на nginx front-end от пользователя. Для этого в стандартных настройках прокси для энжикса меняем

proxy_set_header Host $host;

на

proxy_set_header Host $host:$server_port;

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

Восстановление RAID 10 массива

Поломался однажды RAID10 массив. Как обычно, все произошло внезапно: однажды перезапустили сервер, и получили «(что-то там) … not found». С поврежденным (degraded) массивом сервер стартовать отказался. Массив работал на полусофтовом-полухардварном псевдоконтроллере материнской платы Intel. Физически все жесткие диски оказались здоровыми, хотя для нижеописанного это не критично.

Далее следует описание восстановления информации с массива из серии «с помощью швейцарского перочинного ножа», т.е. без применения изощрённых средств восстановления. Если конкретно, понадобится компьютер с любым *nix и интерпретатором python3. Можно, конечно, воспользоваться программами вроде R-Studio, однако, по-моему это слишком простая задача для них.

Итак, делаем следующее. Открываем в бинарном редакторе все 3 диска и выбираем из них пару striped дисков, т.е. на которых чередующимися блоками составляют весь массив (как RAID 0). Делаем образы обоих жестких дисков в файлы с помощью замечательной утилиты dd по типу

dd if=/dev/sdX of=/tmp/vY.hdd bs=32M

В итоге получаем два больших файла v0.hdd, v1.hdd. С самими HDD далее не работаем.

Снова открываем с помощью бинарного редактора какой-нибудь из образов и определяем размер stripe-элемента (chunk size). Сделать это не сложно даже «невооружённым взглядом»: ищется несколько этих кусков с чёткими границами. Легче всего это сделать на файле с вразумительным содержимом, или даже на любом — если свободное место (почти) заполнено нулями. В нашем случае размер stripe оказался 64K. При этом на одном из образов в начальном секторе сразу обнаружился MBR, а во втором нечто совсем не похожее на MBR. Так стал понятен порядок stripe от разных дисков.

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

#!/usr/bin/python3
"""RAID0 recovery utility."""

dev0 = '/tmp/v1.hdd'
dev1 = '/tmp/v0.hdd'

DEV_OUT = '/tmp/out.hdd'

# stripe 64k
STRIPE = 64 * 1024
	
MAX_COUNT = 500 * 2**29 // STRIPE MAX COUNT

if __name__ == '__main__':
	f0 = open(dev0, 'rb')
	f1 = open(dev1, 'rb')

	f_out = open(DEV_OUT, 'wb')

	offset = 0
	while offset < MAX_COUNT:
		d0 = f0.read(STRIPE)
		d1 = f1.read(STRIPE)

		if d0 and d1:
			f_out.write(d0)
			f_out.write(d1)

			offset += 1
		else:
			print("One of input files are finished. Read: {0} blocks.".format(offset))
			break

	f0.close()
	f1.close()
	f_out.close()

Запускаем скрипт, оставляем его на ~10 минут и на выходе получаем полный образ диска. Разделы из него успешно монтируются самостоятельно или могут быть (всем образом) записаны на физический HDD. Так, совсем несложно и без дорогого софта, можно восстановить запоротый RAID10-массив.

LXC контейнеры в Debian jessie

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

Почти всю полезную информацию можно найти в дебиановском источнике. Ниже — наиболее короткий howto, как быстро настроить lxc-виртуализацию под Debian Linux.

Настройка хост-машины

Начинаем как обычно с установки необходимого софта

apt-get install lxc bridge-utils libvirt-bin debootstrap

Контейнеры будем создавать в стандартной директории /var/lib/lxc. Для удобства сделаем симлинк в корне файловой системы на эту директорию:

ln -s /var/lib/lxc

Настроим сеть. Для этого доустанавливается пакет bridge-utils, типовой конфиг сети (/etc/network/interfaces) будет следующим

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
	address 123.123.123.3
	netmask 255.255.255.248
	gateway 123.123.123.1
	bridge_ports eth0
	bridge_fd 0
	bridge_maxwait 0
	bridge_stp off
	dns-nameservers 8.8.8.8 8.8.4.4

Проверяем, всё ли в порядке с установкой

lxc-checkconfig

и если все нормально, то ставим туда первый контейнер

lxc-create -n myvm -t debian

В результате получаем виртуальную машину и root-пароль к ней. Контейнер будет из stable-дистрибутива (Wheezy), однако его можно дообновить до testing или изначально ставить testing.

Настройка виртуальной машины

Конфиг виртуальной машины находится в /lxc/myvm/config. Доводим его до вменяемого состояния, например такого

lxc.network.type = veth
lxc.rootfs = /var/lib/lxc/myvm/rootfs

# Common configuration
lxc.include = /usr/share/lxc/config/debian.common.conf

# Container specific configuration
lxc.mount = /var/lib/lxc/myvm/fstab
lxc.utsname = myvm
lxc.arch = amd64


lxc.network.flags = up
lxc.network.link = br0

lxc.network.hwaddr = 00:25:90:01:5e:22

lxc.start.auto = 1

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

Перед запуском виртуалки также меняем сетевые настройки в /etc/network/interfaces.

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

apt-get install apt-utils iputils-ping cron rsyslog iptables

Иногда будем получать ругань вроде

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_CTYPE = "ru_RU.UTF-8",
        LC_COLLATE = "ru_RU.UTF-8",
        LC_MESSAGES = "C",
        LC_NUMERIC = "POSIX",
        LANG = (unset)
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Поэтому сразу конфигурируем локаль

dpkg-reconfigure locales

Стандартного почтового агента (MTA) в системе тоже нет, поэтому ставим его и настраиваем:

apt-get install exim4
dpkg-reconfigure exim4-config

Полезные команды для управления

Запустить и погасить виртуальную машину используются

lxc-start -n myvm -d
lxc-stop -n myvm

Параметр -d в случае старта означает запуск в режиме демона. Если его не указать, то getty захватит текущую консоль (что бывает полезно, если не удаётся подключиться по SSH).

Получить краткую информацию о статусе машины можно с помощью

lxc-info -n myvm

Заключение

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

PS

Статья устарела. Более качественный способ приведён в дебиановском мануале. И, что важно, постоянно обновляется.

Минимум в настройке почтовых серверов и рассылок

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

  • Убедитесь, что ваш почтовый сервер не open relay, т.е. не рассылает сообщения от неавторизованных пользователей. Проверьте сконфигурированный почтовый сервер на open relay в нескольких легко находимых в поисковиках сервисах.
  • В соответствии с RFC настройте обратный DNS (rDNS) для IP-адреса сервера и убедитесь, что возвращаемое доменное корректно разрешается и его A-запись — IP-адрес сервера. Иными словами доменное имя должно разрешаться в IP-адрес сервера, а IP-адрес — обратно разрешаться в то же доменное имя (FQDN). Именно это доменное имя должно возвращаться сервером в HELO/EHLO.
  • Настройте цифровую подпись DKIM. Её использование защитит вас от несанкционированной рассылки почты от вашего домена с серверов третьих лиц. По этой причине популярные почтовые сервисы используют её наличие при вычислении «спамовости» письма. После настройки DKIM, подпись следует проверить: в заголовках отосланных писем на серверах, проверяющих подпись, должна присутствовать запись dkim=pass.
  • Используйте антиспам и антивирусное ПО. В том числе и на исходящую почту. Если используете postfix, то на его сайте опубликован список поддерживаемого софта.
  • Настройте SPF. Целесообразность использования этой технологии иногда ставится под вопрос, поскольку она имеет недостаток: форвард с непрописанных серверов приведет к fail-результату по SPF. DKIM в этом смысле существенно более совершенная технология и в целом делает ненужным SPF. Тем не менее, в существующих реалиях её лучше использовать. Проверка, как и в случае с DKIM проста: в исходнике принятых с сервера писем должен быть результат spf=pass. SPF также имеет смысл включать на «непочтовых» доменах в виде "v=spf1 -all" для предотвращения отправки спама от этого домена.
  • Проверьте, что IP-адрес сервера не находится в черных списках, например этим тестом.

В случае почтовых рассылок обязательно необходимо проверить валидность заголовков письма. Например, если сообщение формируется как MIME multipart, убедитесь в правильном использовании Content-type для различных частей письма.