Tech articles

Leave a comment Posted on Tech articles

Создание самоподписанного сертификата?

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

openssl req \
    -x509 -nodes -days 365 \
    -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

После вызова команды надо будет ответить на несколько вопросов: Country Name, State, City и так далее. На вопрос “Common Name” нужно отвечать именем сервера, по которому будут обращаться люди.

Можно автоматизировать ввод ответов с помощью опции -subj.

openssl req \
  -x509 -nodes -days 365 \
  -subj '/C=US/ST=Oregon/L=Portland/CN=www.madboa.com' \
  -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

Leave a comment Posted on Tech articles

Подключение разделов TrueCrypt с помощью сервера Asterisk

Предисловие

Частью моей работы является ежедневное монтирование контейнеров TrueCrypt на удаленном сервере (1С с «серыми» базами… ну, вы понимаете).

Утренний порядок действий меня напрягал: включить ноутбук, подключиться к серверу, ввести 70-тизначный пароль в TrueCrypt, отключиться от сервера, выключить ноутбук, собраться и ехать на работу.

Мысль об использовании Asterisk пришла сразу. Необходимо было это реализовать.

Решение

Конфигурация оборудования такая:

  1. сервер Asterisk — Ubuntu Server 10.04, Asterisk v1.6.
  2. терминальный сервер — Windows Server 2003 R2, TrueCrypt v6.1a, два жестких диска с разделами TrueCrypt.

Логическая цепочка размышлений была такая:

  1. TrueCrypt позволяет управлять собой из командной строки.
  2. Asterisk позволяет запускать любые скрипты, достаточно прописать их в extensions.conf.
  3. Есть виндовая утилита psexec.exe, позволяющую запускать процессы на удаленном виндовом компьютере из командной строки.
  4. Asterisk стоит на Ubunte, значит необходим аналог psexec для линукса — найден winexe.

Дальше привожу сами скрипты.

extentions.conf:

... exten => 777777,1,Playback(beep) exten => 777777,n,Read(auth,,3,5) exten => 777777,n,GotoIf($["${auth}" = "123"]?m:u) exten => 777777,n(m),System(/etc/asterisk/scripts/mount.sh) exten => 777777,n,Goto(end) exten => 777777,n(u),GotoIf($["${auth}" = "321"]?ok:end) exten => 777777,n(ok),System(/etc/asterisk/scripts/umount.sh) exten => 777777,n(end),Playback(vm-goodbye) exten => 777777,n,Hangup ...

Пояснение:

звоним на внутренний номер 777777, вводим пароль 123, выполняется скрипт mount.sh (монтирование разделов) либо вводим пароль 321 и выполняется скрипт umount.sh (размонтирование разделов, так называемая «КРАСНАЯ КНОПКА»)

mount.sh:

#!/bin/sh /etc/asterisk/scripts/winexe -U DOMAIN\LOCALROOT%PASS //IPADDRESS 'c:\Progra~1\TrueCrypt\TrueCrypt.exe /v \Device\Harddisk1\Partition1 /lE /a /p "CJIo}i{HbIU'napoJIb" /q /s' /etc/asterisk/scripts/winexe -U DOMAIN\LOCALROOT%PASS //IPADDRESS 'c:\Progra~1\TrueCrypt\TrueCrypt.exe /v \Device\Harddisk2\Partition1 /lF /a /p "CJIo}i{HbIU'napoJIb" /q /s'

/etc/asterisk/scripts/winexe — путь к утилите winexe, которая находится в папке со скриптами.
DOMAIN — имя вашего домена,
LOCALROOT — локальный админ на терминальном сервере,
PASS — пароль локального админа,
IPADDRESS — IP-адрес терминального сервера,
дальше путь к TrueCrypt.exe на терминально сервере с параметрами
\Device\Harddisk1\Partition1 — жесткий диск 1 (для того, чтобы определить путь к разделу, запустите TrueCrypt и щелкните Выбрать устройство / Select Device),
/lE — закрепляемая за диском буква (E:\)
/p «CJIo}i{HbIU’napoJIb» — пароль к разделу TrueCrypt,
\Device\Harddisk2\Partition1 — жесткий диск 2 и дальше по аналогии с первым диском.

umount.sh

#!/bin/sh /etc/asterisk/scripts/winexe -U "DOMAIN\LOCALROOT%PASS" //IPADDRESS 'c:\Progra~1\TrueCrypt\TrueCrypt.exe /d E /q /s /w /f' /etc/asterisk/scripts/winexe -U "DOMAIN\LOCALROOT%PASS" //IPADDRESS 'c:\Progra~1\TrueCrypt\TrueCrypt.exe /d F /q /s /w /f' # Варианты удаления либо перезаписи содержимого файлов со скриптами: # 1. Использование urandom # dd if=/dev/urandom of=/etc/asterisk/scripts/mount.sh bs=512 count=1 # dd if=/dev/urandom of=/etc/asterisk/scripts/umount.sh bs=512 count=1 # 2. Использование shred, который забивает файл случайными числами из /dev/urandom (рекомендуется) shred -f /etc/asterisk/scripts/{mount,umount}.sh # или полное удаление скриптов (не рекомендуется) # rm -f /etc/asterisk/scripts/*mount.sh

Здесь происходит форсированное тихое размонтирование разделов E:\ и F:\ и рандомная запись в содержимое скриптов для скрытия информации.

Все скрипты и winexe находятся в папке scripts (/etc/asterisk/scripts/)

Итог

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

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

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

http://habrahabr.ru/blogs/sysadm/127997/

Leave a comment Posted on Tech articles

Кое-что о соглашениях об именах почтовых ящиков

Заведя для себя «почту для домена» на Яндексе, я решил открыть свободную регистрацию посторонним юзерам почтовых ящиков на своем «модном» домене. Помимо включения функции catch-all, которая направляет всю входящую почту несуществующих ящиков моего домена на мой основной ящик, предо мной встала необходимость зарезервировать за собой все «стандартные» названия ящиков, чтобы не было недоразумений, когда какое-то имя уже забил посторонний, и вся «служебная» почта уходит совсем не вам. В П.Д.Д. можно, конечно, в любой момент экспроприировать любой ящик подконтрольного домена, но ведь осадочек-то остается. Я озадачился: какие же имена почтовых ящиков являются стандартными и системными? Техподдержка Яндекса ответила, что они резервируют для себя только имя postmaster@ на каждом домене, чтобы отслеживать жалобы и проблемы с почтой, и что на данный момент вопрос о наборе резервированных имен у них остается открытым. Далее, результат поиска в интернете оказался немного предсказуем.

(на картинке: знаменитый black mailbox, место паломничества уфологов-любителей)

RFC

Первое и главное, что я стремился найти — это RFC, коим оказался RFC 2142, MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS (имена почтовых ящиков для общих сервисов, ролей и функций), в последней редакции 1997 года. Приведу только интересующую нас информацию. Исходя из документа, следующие почтовые ящики должны существовать и иметь следующее назначение:

Деловые почтовые ящики:

info@ — Отдел маркетинга, тут можно узнать краткую информацию об организации, продукции, сервисах.
marketing@ — Отдел маркетинга и взаимодействия продаж.
sales@ — Отдел продаж, заказ продукции и информация о заказах
support@ Отдел клиентской поддержки, проблемы с продуктом или услугами.
abuse@ — Взаимоотношения с клиентами, ящик должен быть всегда рабочим и валидным, сюда направляются жалобы клиентов, в том числе сообщения об «Inappropriate public behaviour».

Работа с сетью:

noc@ — Сетевые операции, сетевые инфраструктуры.
security@ — Сетевая безопасность, уведомления, оповещения или запросы.

Техническая поддержка отдельных интернетных служб

postmaster@ — SMTP, [RFC821], [RFC822]
hostmaster@ — DNS, [RFC1033-RFC1035]
usenet@ — NNTP, [RFC977]
news@ — NNTP, Synonym for USENET
webmaster@ — HTTP, [RFC 2068]
www@ — HTTP Synonym for WEBMASTER
uucp@ — UUCP, [RFC976]
ftp@ — FTP [RFC959]

Maillist сервис

(рассматривать не будем, просто перечислим основные, там целая плеяда служебным имен и куча RFC, например RFC2369)
list@
list-request@

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

Таким образом, следует сделать алиасы этих имен на свой «основной» email, чтобы никто не смог, например, на вашем домене открыть usenet конференцию, не стал из «отдела продаж» банчить валенками и не подписывался системным администратором всея сети с ящика noc@.

/etc/aliases

Стандартом де-факто для *nix систем является соглашение о почтовых именах, содержащееся в файле/etc/aliases. Который де-юре основывается на RFC и прочих документах, по каждому отдельному сервису.

Парадигма назначения почтовых ящиков для людей в *nix звучит примерно так: каждый юзернейм получает почтовый ящик на рабочей станции с таким же именем, как его логин. После создания юзернейма в системе вы уже можете отправлять и получать почту в свой аккаунт.(тут будет своё «но»: если разрешит root и верно прописаны MX). Если хотите получить модный алиас — обратитесь к администратору, он его пропишет в /etc/aliases или еще где в почтовой системе.
То же самое касается и системных служб. Существует масса резервных имен типа @nobody, clamav@, www-data@, которые соответствуют системным учёткам служб, в реальной жизни не используются никем, кроме этих соответствующих служб и являются почтовыми алиасами системного пользователя root, поэтому мы их в расчет не возьмем, потому что все значимые имена ящиков сетевых служб мы уже узнали из предыдущего пункта. Добавим только

root@

Современный интернет и прочие негласные соглашения об именах ящиков

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

admin@
administrator@ (мьсе, знающие в этом толк, могут добавить локализованные имена админа в Windows, вроде administrador, administrateur)
user@
mail@
blog@
office@
job@ (и иногда resume@ и hr@)-для отправки и приема заявлений на работу и резюме.
spam@ — иногда его ставят как алиас к abuse@ или postmaster@, для жалоб на спам, очевидно.
billing@ — для биллинга. К.О.
account@ — для бухгалтерии и поддержки аккаунтов.
domain@domain.tld — имя ящика повторяет домен, очевидно, для эстетики.
alex@, boss@ — не стесняйтесь забить свои имена, фамилии и ники, чтобы исключить фактор социального инжиниринга, когда, вас, например, зовут Алексей, и ваша жена, прекрасно зная что вы купили vashdomen.ru, получает с ящика alex@vashdomen.ru письмо сомнительного содержания — не ровен час поверит злоумышленнику.

Вы можете что-то добавить в этот лист.

Кроме этого мне почти ничего не известно о соглашениях почтовых имен в системах Windows, существуют ли они в действительности?

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

http://habrahabr.ru/blogs/sysadm/126822/

Leave a comment Posted on Tech articles

Групповое переименовывание фотографий в Linux

С помощью утилиты exiv2, которая позволяет читать данные EXIF из файлов фотографий, я переименовываю фотографии, которые сделал фотоаппаратами Canon EOS 7D, из вида IMG02731.CR2 в вид, более удобный для сортировки и отображения, 20110719_114534_IMG02731.CR2. Теперь в имени файла присутствует год, месяц, число, время и первоначальное имя файла фотографии.

$ exiv2 -r'%Y%m%d_%H%M%S:basename:' rename *

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

Error: Directory (Last IFD item), entry 0x145f has invalid size 3062158522*1; skipping entry.
Warning: Directory (Last IFD item), entry 0x19b7 has unknown Exif (TIFF) type 48470; setting type size 1.
Error: Offset of directory (Last IFD item), entry 0x19b7 is out of bounds: Offset = 0xf35a8f80; truncating the entry
Error: Directory (Last IFD item) with 8532 entries considered invalid; not read.

Не обращаю внимания. Пока не заметил проблем.

Leave a comment Posted on Tech articles

Авторизация SSH по RSA ключу


Для начала создадим алиасы устройств — вместо длинной записи ssh -l user 192.168.0.1 будем использовать, например, ssh router. Красиво и эстетично! Для организации такой красоты достаточно создать конфигурационный файл SSH (если у вас его еще нет).

user$ mkdir ~/.ssh
user$ cd ~/.ssh
user$ nano config

Примерно такого содержания

Host router
    HostName 192.168.0.1
    User user
    Port 22

Немного поясню:

  • Host — наш алиас к устройству, по которому будем вызывать
  • HostName — имя или IP адрес устройства
  • User — имя пользователя для подключения к устройству
  • Port — номер порта SSH, если переопределено

Каждый алиас необходимо прописать соответствующим блоком, например, можно создать алиасы к одному устройству с разными именами пользователей. Теперь можно вызывать ssh router. Параметры для подключения к устройству router считаются из конфигурационного файла, который мы только что создали. Замечательно! Далее настроим, чтоб при подключении удаленное устройство не спрашивало пароль. Для таких целей достаточно создать пару RSA ключей и один из них поместить на удаленное устройство. Перед генерацией ключа проверим необходимые параметры в настройках системы на стороне клиента/etc/ssh/ssh_config.

user$ sudo nano /etc/ssh/ssh_config

Ищем нужный нам параметр, должно быть так

..
IdentityFile ~/.ssh/id_rsa
..

Подготовку сделали, можно генерировать пару RSA ключей

user$ ssh-keygen -t rsa

Отвечаем на несколько вопросов — нажимаем Enter 😉

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user.ssh/id_rsa): <span style="color: red; font-weight: bold;"><-Enter</span>
Enter passphrase (empty for no passphrase): <span style="color: red; font-weight: bold;"><-Enter</span>
Enter same passphrase again: <span style="color: red; font-weight: bold;"><-Enter</span>
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
b6:a0:23:59:54:79:67:44:0f:e8:24:6b:5b:01:be:9b user@desktop
The key's randomart image is:
+--[ RSA 2048]----+
|  o++=*o         |
| . .oo.oo        |
|  + o  o.        |
| . =             |
|  o +   S        |
|   = + o         |
|  E o .          |
|   . .           |
|                 |
+-----------------+

Пара RSA ключей готова, теперь публичный ключ необходимо передать на удаленное устройство. Но перед этой операцией проверим настройки на удаленном устройстве /etc/ssh/ssh_config.

Ищем нужный нам параметр, должно быть так

..
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
..

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

  • PermitRootLogin no — разрешается ли пользователю root логиниться по SSH. Лучше запретить, при необходимости права себе можно повысить, например, sudo.
  • PermitEmptyPasswords no — разрешить использовать пустые пароли. Даже не знаю для чего такую опцию оставили, если только для лабораторных отладок.
  • AllowUsers — указывает список пользователей, под которыми можно входить по SSH. Очень полезная опция! Если таковой нет в вашем конфиге — создайте ее. Формат AllowUsers user1 user2. В качестве логинов можно указывать user1@example.com (или user1@192.168.0.22), позволит логиниться пользователю user1 только с адреса example.com и 192.168.0.22
  • Port — указывает прослушиваемый демоном SSHD порт. По-умолчанию  — 22, для повышения безопасности лучше сменить его на что-то выходящее за пределы 1024 или еще лучше, за пределы 10000. К примеру поставить 55555, легко запоминается, а вот nmap’ом не просканишь.

Все готово. Передаем ключ на удаленное устройство.

user$ ssh-copy-id router

После успешного прохождения аутентификации ключ будет передан на удаленное устройство

Now try logging into the machine, with "ssh 'router'", and check in:
  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Пробуем подключится

user$ ssh router

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

Leave a comment Posted on Tech articles

Маршрутизатор на Debian

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

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

  • операционная система — Debian
  • набор железа — подойдет любой старенький компьютер PIII и выше с двумя сетевыми картами;
  • данные на имеющуюся сеть (провайдер, поставьте свои данные) eth0:

IP адрес: 192.168.10.5
шлюз: 192.168.10.254
DNS: 192.168.10.1

  • данные на внутреннюю локальную сеть (куда будем раздавать интернет) eth1:

IP адрес: 10.0.60.254 (наш новый шлюз)

С параметрами определились, можно начинать устанавливать. Систему ставим минимальную, из задач на сервере нам понадобится только OpenSSH, остальное нет необходимости ставить. Первым делом настроим сетевые интерфейсы, чтоб не сидеть за косолью, а подключиться с рабочей машины и все делать удаленно. Настройки сетевых интерфейсов находятся в файле /etc/network/interfaces, приводим примерно в такой вид, напоминаю, данные необходимо подставить свои.

user$ sudo nano /etc/network/interfaces
# Сетевая петля                 
auto lo
iface lo inet loopback
# Основной интерфейс от провайдера
auto eth0 eth1
iface eth0 inet static
        address 192.168.10.5
        netmask 255.255.255.0
        network 192.168.10.0
        broadcast 192.168.10.255
        gateway 192.168.10.254
        dns-nameservers 192.168.10.1
        dns-search localdomain.lan
# Дополнительный интерфейс локальная сеть
iface eth1 inet static
        address 10.0.60.254
        netmask 255.255.255.0

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

user$ sudo /etc/init.d/networking restart

Немного отредактируем некоторые файлы, чтоб потом все заработало без лишних «танцов с бубнами»

user$ sudo nano /etc/resolv.conf
search localdomain.lan
nameserver 192.168.10.1

С этого файла кэширующий сервер DNS будет брать настройки. Осталось совсем немного, настроить NAT и DNS. Это только слышать страшно, а делать просто. Для этого установим волшебный пакет — dnsmasq. Dnsmasq является простым в настройке кеширующим DNS и DHCP(опционально) сервером. Разработан специально для применения в небольших, в том числе и домашних сетях, использующих NAT и соединяющихся с Интернет посредством модема, ADSL и прочих вариантов.

user$ sudo aptitude install dnsmasq

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

user$ sudo touch /usr/local/bin/set_firewall
user$ sudo nano /usr/local/bin/set_firewall
#!/bin/sh
#
# Константы
# Интерфейс смотрящий в интернет
INET_IFACE="eth0"
#
# Сброс всех правил
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
#
# Включаем режим прозрачности
iptables -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE
#
# Включаем режим пересылки пакетов
echo "1" > /proc/sys/net/ipv4/ip_forward
user$ sudo chmod +x /usr/local/bin/set_firewall
user$ sudo /usr/local/bin/set_firewall

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

user$ sudo touch /etc/network/if-up.d/firewall
user$ sudo nano /etc/network/if-up.d/firewall
#!/bin/sh
/usr/local/bin/set_firewall
user$ sudo chmod +x /etc/network/if-up.d/firewall

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

Leave a comment Posted on Tech articles

Генератор записей файла sources.list

Для тех, кто только что установил систему, возникает вопрос … почему так мало программ в комплекте. Отсутствуют кодеки для декодирования видео и аудио, нет красивых и удобных проигрывателей, о которых рассказывал товарищ. Дело в том, что по умолчанию Debian подключает только раздел «main» в sources.list. После загрузки системы в «/etc/apt/sources.list» необходимо вручную добавить необходимые разделы репозиторий Debian — «non-free» и «contrib», но в этом посте я покажу вам более простой способ создания файла sources.list.

Для этого создан генератор, который генерирует содержимое для файла /etc/apt/sources.list, примечательно, что генерируется не только необходимые записи, но и строки для получения GPG-ключей (подписи для репозитория). Пользоваться генератором очень просто:

  • Выбираем страну для которой будем генерировать sources.list;
  • Выбираем кодовое имя дистрибутива;
  • Отмечаем разделы базового дистрибутива (main, contrib, non-free), «Sources Repository» отмечайте тоже (может понадобится при сборке пакетов вручную).
  • Далее отмечаем, что хотим получать пакеты системы безопасности и приоритетные обновления;
  • В самом большом разделе «3rd Parties Repos» отметьте необходимые репозитории. Каждый имеет небольшое описание, ссылку на домашнюю страницу и подробное описание. Если этот раздел не открылся, обновите страницу и повторите выше указанные действия;

Нажимаем кнопку «Generate List» и остается только скопировать сгенерированный sources.list в ваш (/etc/apt/sources.list). Этот генератор также поддерживает Ubuntu. Безглючных обновлений 🙂 на сборках отличных от «stable».

Leave a comment Posted on Tech articles

Ускорение запуска программ в Debian

Утилита preload ставилась и проверялась на Debian 5 Lenny, на других версиях Linux, наверняка, присутствует. Чем же она примечательна? Только тем, что позволяет производить в полуавтоматическом режиме анализ часто запускаемые программы и осуществлять кэширование части их кода в памяти. В среднем ускорение составляет около 45-50%. Для её установки не потребуется много времени, тем более она ставиться и настраивается сразу. Итак, устанавливаем:

[user]$su
[root]#apt-get install preload

Собственно, вся установка. После установки утилита запустится и начнёт уже работать. Как и у многих программ у неё есть свой конфигурационный файл /etc/preload.conf при желании можно изменить режим работы утилиты. Более детальное описание и детали конфигурации можно получить на сайте разработчика Techthrob.